Problem with Ethercat NI-9145

[Penzium]

Hi all,

I have a strange problem with a system composed by a cRIO 9035 e two EtherCAT NI-9145.

The slots of the two EtherCAT are all occupied. I have 8 NI-9208 on the ETH1 and 3 NI-9476, 2 NI-9425, 2 NI-9234 and 1 NI-9214 on the ETH2.

Sometimes the EtherCAT goes in status disconnected and the LED error on the ETH2 blink red twice and pauses. In this status the real time seems stopped and I cannot read nothing from it.

In the ETH2 I have also FPGA code that reads the DI-DO and commands 9 DO for generate PWM.

I read the manual of the NI-9145 and for the LED error blinking twice I have this description:

There is an application watchdog timeout. The slave did not receive a scheduled EtherCAT telegram

Specifically what does it means this error? Someone have a problem like this?

Thank you very much

[alamanna · Accepted solution]

Hi,

this error occurs when the CPU is too high, preventing the main chassis from sending the scheduled EtherCAT telegram from the NI-9145 device. If the CPU remains high, for longer than the watchdog timeout, then the chassis will disconnect from the NI-9145 device. This causes the error LED to blink twice and then pause.

You will need to reduce the CPU usage of the application to resolve this issue. The reduction of CPU will need to take into account the system requirements and application, and as a result, the action taken will be specific to your code. For generic advice you can see the suggestions and documents below:

• Remove any unnecessary software from the cRIO. This software has processes that run in the background and could be using up a significant amount of your CPU. Please ensure the minimum possible software is installed.
• Move as much code to the FPGA as possible.
• Try to reduce the number of individual network shared variables, even moving them into clusters will help to combat this (RT Target Performance Benchmarks for Network Published Shared Variables).
• Reduce the loop rate.
• Use while loops instead of timed loops where possible.
• CPU Usage Considerations When Using Scan Mode.
• Avoiding SubVI Overhead (Real-Time Module).
• NI LabVIEW for CompactRIO Developer’s Guide - specifically chapter 2 looking at when to use FPGA vs Scan Mode, and chapter 3 looking at how to work with constrained resources.

Hope this helps!

Regards,

Alessia

[Penzium]

Thank you for your answer, it clarified me some points.

I reduced the cycle time of a timed loops and now it seems the CPU is around 50%. The led error blinking in the EtherCAT module has not come back.