- Software
- IQANdesign
-
Bugs
Digital Out causing No Contact on MC3 - IQAN Design 5.07
Recently had the same issue with 2 different customers who have been running the same system for 5+ years.
The systems have an MD4 and 3 MC3s.
After a partial touchscreen failure the customer replaced the original MD4 (running a program written in IQAN design 3) with a new MD4 and flashed the whole system with an updated program written in Design 5.07.
After flashing, everything worked for a few days and then one of the MC3s had a No Contact error. I had them swap two MC3 modules around and reflash and the MC3s received the program with no issues over the CAN network but the No Contact message remained. I had the customer check the indicator flash codes on the modules and the 2 units that could still talk with the MD4 were flashing 3 reds and an amber (no contact), but the MC3 that couldn't be communicated with was flashing steady amber (status ok).
I then had them unplug the C2, C3, and C4 connectors to the MC3 causing the issue and the No Contact went away. I had them plug in the C2 and C3 connectors and everything was still working fine (besides open load errors from the outputs on C4 connector). When the C4 was plugged in the No Contact returned.
The system uses Digital Out/Returns on C4 pins 13/14, 15/16, & 17/18 to control relays. Once they unplugged the wiring from those 6 pins the problem was resolved. The functions run by those relays are not critical to the operation of the system so customer is leaving unplugged.
As I said, this is the 2nd time this has happened recently. The first time I chocked it up to a wiring fluke but now that it's happened twice and both soon after a screen replacement/firmware update I'm starting to connect the dots and thinking there may be a bug in IQAN design 5 which is causing this issue.
Customer support service by UserEcho
I'm not familiar with the MC3, but we had a system where backfeeding the outputs was causing no contacts. The module would detect the backfeed at power up and disable itself until power was cycled again.
Reverse feed through one of the pins in the C4 connector must be the issue.
The action the MC3 takes when it detects reverse feed is to prevent startup of the application. That is why you do not get contact with it in the muti-master system.
At first I was surprised by the steady yellow blink, I would have expected the blink code for "critical stop". But after checking, I can confirm this is the only blink you see when there is reverse feed to an MC3 running 5.x.
Thanks for the detailed investigation and response.
Speaking to one of our other engineers it has been brought to my attention that the same issue also occurs on XC43 modules.
Based on your response it seems that this behavior is by design (I assume to protect the module). However, due to the behavior of the IQAN diagnostics, it is difficult to identify the source of this issue when it happens in the field. At least on the MC3s it could be narrowed down fairly quickly by only leaving the C1 connector plugged in which contains the essential wiring for system operation (power, ground, CAN, Address Tag). With an XC43s it proves more difficult with the increase in I/O and the more difficult to service connectors.
Is this something to be expected from now on?
From my perspective I see this as at least partially a bug in the firmware. Is there any opportunities to address this moving forward? At the very least could the diagnostics be improved?
Thanks again.
Yes, on previous modules XA2/XS2/MC2, reverse feed went undetected. Since the MC3/MC31, reverse feed is detected and prevent the module from starting the application.
On the MC4x/XC4x, reverse feed at startup will give the blink code R4:2 1:1:1 (see Appendix B)
If you have this error on an MC4x with 6.x or later, IQANrun 6 is also able to show a clear text error message about the reverse feed.
MC3/MC31 used to have a similar blink code starting with 4 red for critical stop due to reverse feed. But with 5.01-5.08, it just enters the critical stop state and prevents the application from starting, but fails to show the error blink.
I think a quick way to isolate the problem would be pulling fuses of all devices connected to the module in question. Once you pull power to the offending device it should be possible to boot normally.