Your comments

Hi Ethan,

For the question of testing the internal terminating resistor, the answer is that there is no practical way of doing this in the field. On the other hand, I cannot recall ever seeing any report of an IQAN module with damages on the components used for internal termination. The components used are rated to handle shorts to battery voltage, so they are not that easy to destroy. So when you have an expansion module fitted with an IdTag with the 'T', or a master module with the application configured to terminate, you can be confident that the termination will be there when the system is powered up.

What could happen; and that I have seen a couple of times over the years is damage to the CAN trancievers. The symptom here would be different from a missing termination, a module with a destroyed CAN transceiver would not be able to participate on the bus at all.

For the second question, your understanding is exactly right. The expansion module will measure the resistance on the IdTag, if it is in the intervals for 'T' tags, it switches on its internal termination.

I am not sure if you sorted this one out already, but one observation is that in the screenshot from IQANanalyze, the PGN 65283 is not present.

I am not sure if this was because the sending of PGN 65283 by Source Address 40 was added at a later stage?

The source address on the assigned module does not show in this screenshot from IQANdesign, but all JFIN:s that are shown here belong to the same module, so they will all have to match the same Source Address.

In general, you will see the status "Not evaluated" on any JFIN/JPIN/GFIN/GPIN that has not been received since startup, and that has no timeout defined.

In addition to PGN number and Source Address, the other properties that determines if the JFIN is matching the CAN frame is Priority and paged protocol.

The priority can be ignored by setting this property to the default "don't care"

The GPIN and GPOUT properties for setting byte order are only available when selecting 2 or 4 byte as length.

To change the endianness when the parameter has a different length, one will have to use bitwise operations.

Thank you. The information that it happens when the CANopen nodes are connected during SW update of the multi-master system is really interesting. I'll send you a mail with some additional questions.

The blink codes starting with 4 red and one yellow belongs to a group of error codes described as

4:1 Internal error/OSE

The flashes that follow provide additional detail.

When the MC3 is in this state showing the 4:1 blink, all functions will remain off until the MC3 is rebooted.

If restarting does not help, also try starting it without the application loaded (removing or shorting the IdTag)

I checked this specific blink sequence, and it appears as an issue is related to CAN-B, but unfortunately without any useful information on what could have caused the crash.

Yes, to see the counter and checksum values, you will have to look at the bus with e.g. IQANanalyze.

For incoming CAN frames, the GFIN/JPIN and all connected parameters will be set to error status if the checksum is incorrect.

IQANsimulate will only simulate correct values.

Hej Ulf,

A suggestion is to check the J1939 module in the system layout that the JFIN is assigned. The JFIN in the MD4 application could be assigned to a module with the wrong source address.

The message dialogues will not be shown on top of a video control. This is a limitation that was added for performance reasons.

What you can do however is to re-position your dialog boxes for the pages that have video controls, so that they do not overlap.

To position the dialog, it helps to switch on the "show system dialog position in page editor" button, see below:

I am just guessing now, but perhaps it could be that the font you are using is missing these size?

Have you tried it with the Default font?

Thanks Michael, I could reproduce it on 4.06 too.