Your comments

Thank you Kevin! I have looked at the IQANanalyze files, and figured out a way to reproduce this problem. 


What seems to be happening is that the voltage drops very briefly, causing the XC23/22/21 to restart, but the expansion comes back online before there is a No contact. 

When I tried different combinations here on the bench, I am only able to reproduce the problem with cycle times of 50 ms and higher, for shorter cycle times the master module is detecting a No contact and deals with it.

Thank you for the very detailed explanation Kevin; I still cannot understand what it is that is going wrong but the information you provided is very useful. 


The  XC23 firmware version 1.02 on your module is the version that was used up until quite recently (modules built after 2017 week 32 have version 1.04), that I am unsure of whether this could have anything to do with the strange symptoms.


When you were cranking the engine, did you see the MC3 restarting or not? Should be possible to see in the systems log. In a 24 V system I'd expect both the MC3 and XC21 to stay on during cranking, but it is perhaps possible that there could be problems on the CAN bus. 


Can I ask one more thing of you? Is it possible to get a CAN trace with IQANanalyze of the expansion bus when this situation occurs? 



As Jos writes, an IdTag is necessary on the MD4.

It doesn't really seem to match the symptoms you are describing, but it is worth checking to make sure it is not the interlock for reactivation of DOUT:s, this has been quite confusing to some. 

If you loose and then regain contact with an expansion module any outputs that are on will remain in the error status No contact, until the channels controlling the outputs have been false or zero. 


The block diagram would look something like this when you measure on it: 


In this situation, the LED on the master module will keep blinking the 3:1 indicating No contact, but the expansion will have resumed its normal OK blink. 



But from your description, it seems as if the XC23 is the module that keeps showing the 3:1 blink? 

Have you confirmed that the MC3 has recovered and is running? You wrote that you saw some channel values changing in IQANdesign, so I assume you were connected and measured channels on the MC3?



A more general question, what is the firmware version of the XC23?

Any change you make in IQANdesign to the project file will alter the project checksum, even if you for example only move a channel one pixel in the application view. 

One good way of making sure there is no change is to use IQANrun when sending, then you can be sure that you won't alter a project file by mistake. 

Not sure if you meant that you changed Project ID? That is a big change to the project file. This should normally be avoided, if you change Project ID the machine will no longer recognize previous settings. 

In a multi-master system, the Project checksum is used to identify that all master modules in the system belong to the exact same version. To use the optional MD4, you must ensure that it runs the exact same version of your application as the MC42. 


Project checksum is a unique identifier for this exact version of the project file. It is used at system startup, together with project ID, to verify that all master modules in a system originates from the exact same version of the project file.

There is a mistake that is easy to make when using these devices, for the PEAK adapter to work with the IQAN tools you must install both the CAN device drivers and the API "PCAN-Basic"



The CAN adapter brands that work with IQAN are listed here: 

https://forum.iqan.se/knowledge-bases/2/articles/231-usb-to-can-interfaces

Is it OK if I move the question to an open forum topic to give an answer there?