+3

Relation between CAN errors & IQAN Design 6?

Rick 4 years ago in IQANdesign updated by Gustav Widén (System support) 5 months ago 4

The past year (since Februari or so), we've been experiencing a lot more CAN related issues than in previous years. Usually BUS-ERRORs (so the safety module will lock down). It happens sporadic, it has been extremely hard to reproduce, but it happens on quite a lot machines, a few times a week in some cases. Machines with different software, different engines (FPT, Scania), different programs, different wiring. So they must have something in common that makes this happen.


I suspect it's "just" somewhere in the wires/terminators or other external factors that may reduce the bus health in general. But, what strikes me it started to happen on somewhat older machines, after updates. Some MC4x modules went from IQAN 5.03 to IQAN 6.xx, and it seems that CAN problems started there as well.


Could it be that the problem was always there, but that IQANs have a more strict check (less tolerance) since a specific firmware version?


Couldn't find it in the release notes, other than that several new CAN features (high speed, FD) have been added. A bit off topic, but in the same fashion we just updated a very early MC43 with a new program, and suddenly there is a VREF error that didn't occur before the update. Again, I guess the error was always there, but slipped through somehow in the older firmware?

For the info:

* We use 250 kbps

* Faults happen on the primary CAN-bus (about 4 MC IQANS, a display, an Engine)

* Usually the Safety Module will lock down, while the others continue to talk

* Networks are often a mixture of firmware versions (IQAN 5.03, IQAN 6.00.49, and more recent IQAN versions) - depending which modules got updated

I got the same problem confirmed this morning, we could see messages logged with Busmaster sent by other devices and our MC43-FS was'nt able to read any other devices' messages. Not able to transmit eather. Messages are present, but the application still flag timout on input messages. The output messages inscribe "No Contact" (like no one was aknowledging it) but Parker is not even trying to send it !

Is there a way to reset a single CAN interface without having to power reset the controller ? It seems like the MC43-FS was loosing synchronisation with the CAN bus or was completely disabling its CAN transducers!! 

I have this issue as well on a MC41FS module (thats a stand alone controller).  The module goes into CAN lockout mode and the LEDs blink a code that not even the factory can decifer.  So I dont know whats causing it definitely.  I suspect voltage quality/supply issues, and perhaps its also related to the requirement of the FS module to be restarted every 48 hours (its in the manual) which allows the CPU and realted to run power up checks.   This is in itself a CAN reset.  I still dont have an answer or solution.

Dont suppose anyone has any ideas on this?  Would upgrading to IQAN 7 help?

One note I can make, is that our FS module is powered on without reset for months on end.  We were not aware of this at the time.  There is a FS requirement in the manual stating that the modules must be reset at least every 48 hours in order for SW checks to run on power up.  It may be the case that after x weeks of operation the module goes into safety mode for this purpose.  Does anyone have any thoughts on this behaviour?  I am seeing this type of failure every 2-3 months as a pattern.

Thanks

Julian

The original post was about CAN bus errors. There is some more info on that type of error in No contact and Critical CAN bus error / Knowledge base / IQAN

From version 6.05 there is recovery function for that type of CAN bus off error. 

That the MC4 controller stops with a critical stop blink is a very different type of problem. Here the fact that CAN stops is the effect of the application stopping. I believe it is the problem in the post MC41FS Critical Errors / Hardware / IQAN