Your comments

I think the troubleshooting in this case is of quite general nature and could be interesting for other users, is it ok with you if I move this topic from helpdesk to the open part of the forum?

I always prefer using ethernet to update my MD4 modules. The firmware of the MD4 is about 20 MB, so updating it via 250 kbit/s CAN will take time. When shipped from our production, the MD4:s are loaded with all the firmware, but almost always an earlier version than the latest available.


But both methods should work though. Starting with the attempt at downloading via ethernet, how were you connected to the MD4? E.g. laptop disconnected from the docking station and the office network, with a cable directly to the C3 connector? Or the MD4 C3 connector plugged into the office network?

What you could have is that the ethernet port on you PC has been blocked for certain types of traffic. This would be something to suspect if IQANdesign/IQANrun does not find the MD4 at all.


If the CAN download fails, that is more likely to be due to the CAN wiring. What CAN dongle are you using, and how is it wired? E.g. 120 ohm termination on the CAN dongle, and just the MD4 as the only module on the bus. Or a more complex CAN network with multiple IQAN and non-IQAN modules on the diagnostics bus?



Good point, we missed this symbol. It will be added to the image library.

IQAN will only send out a poll request (using PGN 59904) for the PGN:s where you have defined a poll trigger on your JFIN.

PGN 65253 Engine hours is an example of a PGN that is defined as on-request in J1939, but where I have seen that some engines sends it out also without a request. That may explain why you don't always need to use the poll trigger on your JFIN.


Yes, a 2 second timeout combined with a 500 ms poll trigger is not effective, but that is mainly due to the way that the JFIN handles the timeout. The hint states "If you want to use timeout together with poll trigger, make sure the timeout is shorter than the poll interval, otherwise timeout will not be detected."

The timeout will count from the time you send out the poll request, until the JFIN receives the response.
Sending out a new poll request before the timeout has expired will reset this timer, and you will never detect a timeout on this channel.

I have never implemented anything with NMEA2000 myself, but IQANdesign supports setting the Data Page bit, effectively giving you a 17 bit PGN. I believe the main reasons to introduce this was to be able to build up NMEA2000 messages in IQANdesign



Since unplugging the C1 connector and plugging it back in resolved the issue, it is probable that there was something in the connector that altered the restance that the MD4 measured on the IdTag. Perhaps if they have applied some grease in the connector.
The message "Wrong IdTag" is given both if you have an IdTag with the wrong number (e.g. a 2 instead of a 1), but also when there is an invalid resistance that does not match the range for any of the IdTags.

For the MD4, power cycling the module (cutting the supply to the +BAT pin) has the exact same effect as unplugging the connector and plugging it back in. It will reboot, and at startup it will read the IdTag.
No, the delay must be on the activation of the XC10 DOUT:s, so if there is a delay in enabling the XC10, then the DOUT activation comes at least one cycle after the module enable.
The output delays (IDC) does not get processed by the XC10, the XC10 only sees the DOUT:s as its commands.

Yes, if you do not have any delay in activating the XC10 via the Enable property, then you can activate the DOUT as soon as the IQAN master starts, and the XC10 will activates its outputs without the need for a flank.

That is strange.
The module only reads its IdTag during start-up, so if this is happening during operation, that seems to indicate that something, e.g. a glitch in the power supply, is causing the MD4 to restart.

Are you sure the report about it occurring during machine operation and not during machine start is correct?

The most probable wiring fault for the IdTag would be an open circuit, but for that fault you would get a different error message, that would instead say "Safe mode! Application not loaded".

One guess, that is really just a guess, is that perhaps there could be an issue with a really low supply voltage. This is not something I have ever seen, but since the IdTag is using a 5V reference to measure the IdTag resistance, a supply <5V could perphaps in theory cause an incorrect measurement. But I have never seen this happening, it is just a thought.
Currently this is not possible, for performance reasons the MD4 video control is writing directly on the display regardless of other layers.