Warning 66030 Prevention

[OptiJohn]

I could use some serious help. I have an issue that I have been unable to solve after over 30 hours of attempts.

I have a 9082 cRIO with 2 EtherCAT expansion chassis filled with NI 9236 strain gauge modules. Both chassis are running FPGA code that allows the modules to be shunted and using user defined variables to transmit the data. All my FPGA code seems to work fine and I am able to read and present strain values to the user.

However, after a random time between 5-25 minutes, I will receive a 66030 warning, all my strain gauge data will come in stale, and the "Online Device State" for the 9144 chassis will be listed as "Device Disconnected". Using the hacky way of setting scan engine to configuration mode and back to active mode does allow the readings to continue but this approach is unacceptable to my client. Doing this causes ALL of my I/O to reset and I lose all my control signals to various devices.

If anyone has ever experienced this before, please help me. I'm pulling out my hair.

[crossrulz]

I have not played around with the EtherCAT chassis much.  But there are a ton of settings in the project properties for the EtherCAT chassis.  Read up on the ones you find in there.  One issue we found was that we needed to greatly increase the percentage of Scan Engine time to be used for transmitting the data.  It sounds like you might have a lot of channels, so you should look into that.  Another possible option would be to decrease your Scan Engine clock rate.

[OptiJohn]

I appreciate the response. I have already doubled the scan engine scan period and network publishing period. I'll try doubling them again.

After reading your post, I am now currently running with the "% time to transfer cyclic data" increased from 20% to 50%. Crossing my fingers.

Some other things I have tried:

1) Removed one of the expansion chassis from my program.

2) Exchanged the CE certified, shielded CAT6A ethernet cables with unshielded Cat5 cables.

3) Disabled distributed clock and I/O synchronization.

4) Disabled watchdog

5) Reduced the UDV write rate in my FPGA code from 900uS to 25ms.

6) Modified software to only write one module's worth of data each loop iteration.

7) Monitored cRIO CPU/Memory usage (both never surpass 5%).

😎 Used the "Clear All Faults" scan engine VI when the warning is detected (has the same effect of setting scan engine to configuration/active).

9) Updated EtherCAT drivers and compactRIO drivers.

[robo_Jeff · Accepted solution]

 Hi OptiJohn,

It's sounds like you're taking some good troubleshooting steps. You could also try moving all of the scan engine I/O on the cRIO down to the FPGA level, if the current steps don't resolve the issue.

[OptiJohn]

Jeff,

You beat me to it. This morning, I deployed a change that moved all the cRIO Scan Engine I/O down to the FPGA. This has solved all my issues. I have still notified NI's application engineers & R&D that I'm happy to continue working with them to find a fix to the original issues, but at this time, my client's issues are resolved and they are satisfied.

Thank you for the response and support!

[robo_Jeff]

OptiJohn,

I'm so glad that worked out, and your customer is now satisfied. Have a great week!