No contact and Critical CAN bus error

The IQAN master modules have two different error messages that both points towards CAN bus problems.

• Error No contact
• Critical CAN bus error

Both types will generate dialog messages on the master displays, and both types will be saved in the system log.

No contact

Below is an example of a No contact message with an IQAN-XA2:

This error message gives the name of the module, in this case “Chassis module”, shows that it is a “No contact” error, and details about the missing module.

In this example XA2[0]@MD4-7[0]:B means the module type is “XA2”, its expected address is “[0]”, the master module it should be connected to is the “MD4-7” with address, “[0]”, and that it should be on CAN bus “B” on that master.

No contact is triggered by a timeout defined for each module. IQAN expansion modules and other IQAN masters in the system have automatic timeouts, but on J1939 and generic modules the timeout property on the module must be set by the application designer.

Possible explanations for a No contact with a module include:

• Module power supply switched off
• Wrong IdTag for expansion module
• CAN bus open circuit
• CAN controller on the module is in bus-off state, due to any of the faults listed under "CAN bus error”

After the problem that caused a No contact has been resolved, the IQAN master module will resume communication with the module. Some functions, for example reactivation of expansion module outputs may require additional actions after a No contact.

CAN bus error

This is an example of the message dialog for CAN bus error:

The message show the header “Critical”, the name of the bus, in this case “Expansion” , the text “Error”, and the affected bus, “CAN bus-B” here.

This critical CAN bus error means that the master module CAN controller for that particular bus has gone into bus-off state.

Depending on module type and firmware version, it might be necessary to switch the IQAN module off and back on again to recover. (see this post about CAN bus recovery).

The action to go into bus off is part of the CAN standard, and a function built into every CAN controller.

CAN does tolerate some faults the bus, but the CAN controllers increase their error counters for every incorrect CAN frame, and when the error count is too high, the CAN controllers are designed to switch of. The way this method is designed makes the node that sends the most messages most prone to switching off.

The effect of a Critical CAN bus error is that the master module loose contact with all modules on that bus. When measuring with IQANrun or the menu system, one can see that all the modules on that bus will be in No contact status.

Possible faults that could all give the symptom Critical CAN bus error are:

• Shorting of CAN-H to CAN-L, or shorting of CAN-H or CAN-L to ground or battery.
• Incorrect termination of the bus. Either no termination or too many.
• Too long drop lines. This potential problem is easy to avoid with IQAN expansion modules like XA2 or XC21 that has double pins.
• Too large voltage potential differences between CAN nodes. This could be an intermittent problem if there is bad grounding between the modules and large loads switching on and off.
• For J1939 and generic buses, setting the wrong CAN bus speed, e.g. mixing of 250 kbps and 500 kbps on the same bus.
• For J1939 and generic buses, two nodes trying to send messages with the same CAN identifier.

A challenge when troubleshooting is that most of the faults that cause the symptom Critical CAN bus error could also show up as No contact errors.

For example, problems with termination, drop lines or voltage potential differences are likely to also show up as No contact with modules.