Solution
A common cause of this behavior is repeatedly calling Open Slave.vi inside a fast retry loop during EtherCAT error recovery. Open Slave.vi is a heavy-weight initialization function that allocates resources and performs EtherCAT slave discovery. Executing it continuously can create a processor-intensive loop that drives CPU utilization to very high levels.
To prevent excessive CPU usage:
- Open EtherCAT slave references once during application startup.
- Keep EtherCAT slave references open throughout application execution.
- Close EtherCAT slave references only when the application stops.
- Avoid using Open Slave.vi as a continuous polling mechanism to detect slave reconnection.
- Monitor EtherCAT slave availability by using lightweight state-monitoring functions such as:
- GetSlaveStates on the EtherCAT Master reference.
- GetState on the EtherCAT Slave reference.
- Compare previous and current slave states to identify disconnected or unhealthy devices before performing recovery actions.
- Implement recovery logic only when a state transition indicates that intervention is required.
- Introduce a significant delay or backoff mechanism between reconnection attempts if re-executing Open Slave.vi is required. For example, wait approximately 1 minute between attempts to reduce processor load.
Following this architecture helps maintain low CPU utilization while providing robust EtherCAT device recovery behavior.