Questions
0
Answered
LC5 Errors
I have a couple questions about LC5 errors. In the instruction book it lists status safe state (Red) as repeated red blinks. What is safe state (red) as opposed normal (no errors).
For the error codes under the module is offline section, what will bring the module back online for each error?
Customer support service by UserEcho
The fast red blink on the LC5-C0x is indicating the module has detected a critical error and stopped.
There could be multiple reasons behind this, but if you have actually encountered this fast red blink on the LC5, I'd say the most plausible explanation is a too short polling cycle time.
If application cycle time on your MC4 needs to be below 10 ms, consider setting a higher polling cycle time on the expansion bus properties.
For the situations listed under "module is offline"; the most plausible situation is probably that the CAN bus is interrupted, this is indicated with the 3:1 blink on the LC5. If this error goes away, the LC5 will recover automatically (there is no startblock functionality on the DAC channel).
On the LC5, the 3:1 blink may also indicate CAN controller had to stop (see this post on bus off). In the event the LC5 is in bus-off, you'd need to cycle the power to it to recover.
For an IdTag error or the unlikely internal error, you need to restart for the LC5 to try to recover.
Gustav,
Great, thank you.
Gustav,
Can you please decipher this blink code for me?
LC5 BLINK CODES.MOV
Thank you,
Chris
This is the LC5 fast red blink, indicating the self monitoring functions of the LC5 has triggered a stop. The in-between code 2 yellow 15 red indicate the problem is related to sending out CAN messages.
The most plausible explanation is a too short polling cycle time for the available CAN bus bandwith.
Gustav,
Thank you for looking at it. Does this indicate a bus off state with the need to cycle power to recover?
It is not a bus-off, it is a more severe error. But the solution is the same, to recover you need to cycle power.
If it is a too short polling cycle time on a bus that only has LC5, then the error will resurface almost immediately again, until you modify the application.
If there is other traffic on the bus and this contributed to the problem, it may take longer until it resurfaces.
Ok thank you. It is actually happening more frequently on a bus that is shared with a master bus. It will show up as a "No Contact" error in the MD4 log. The other LC5 has its own bus, but the issue comes up less. I assume you are saying that the shared LC5 and Master bus are being overloaded triggering the LC5 to go into this error state?
That sounds strange, with an MD4 controlling the LC5, the shortest polling cycle time is 10 ms (shortest cycle time possible on MD4).
A mixed bus may be flooded with traffic that can trigger this problem, here it is a good idea to keep an eye on the bus utilzation.
But whey you have an MD4 bus with just one LC5, the and 10 ms (or higher) polling cycle and no other traffic would mean ~30% (or lower) bus utilization. That should give plenty of margin to avoid this type of problem.
Unless there is some other problem on the bus.
Ok, thank you.