One common cause for this issue could be CPU chatter preventing distributed clocks (DC) synchronization in the EtherCAT network. Distributed clocks are only able to synchronize if the Main Device-to-network clock difference settles below 5% of the model's sample time.
To determine if this is in fact the issue that you are facing, log the "Status" output of the EtherCAT Init block as shown below. Please refer to the EtherCAT Init block documentation for an overview of available diagnostic signals:https://www.mathworks.com/help/slrealtime/io_ref/ethercatinit.html#bsc70vb-Status
Open Simulation Data Inspector and specifically look at the 'MasterToNetworkClkDiff' and 'NetworkToSlaveClkDiff' components (depending on whether you are using Master Shift or Bus Shift mode). As of MATLAB R2023a these parameters have been renamed to 'MdeviceToNetworkClkDiff' and 'NetworkToSubDeviceClkDiff'.
See if these signals are above the 5% of base sample time threshold as mentioned above. If yes, that explains why the distributed clocks are unable to sync and why the EtherCAT network does not go into operational state.
Below is an example of an EtherCAT network in Master Shift DC mode working at a 500 Hz sample rate (MasterState reaches 8), but no longer working at a 2 kHz rate (MasterState stuck at 2):
- At 500 Hz, the sample time is 2 milliseconds, 5% of that corresponds to a threshold of 1.0e5 nanoseconds. We can see from the plot that the master-to-network clock difference is well below that, so it's able to sync the distributed clocks.
- At 2 kHz, the sample time is 0.5 milliseconds, which corresponds to a threshold of 2.5e4 nanoseconds. In this case, the main device-to-network clock difference consistently exceeds this value, so the distributed clocks are not able to synchronize.
There is no easy way of solving this issue. Please try the steps below, but these are not guaranteed to resolve the issue:
- Toggle the EtherCAT DC algorithm in the TwinCAT configurator from Main Deviceo Shift mode to Bus Shift mode and see if the jitter is small enough in the other mode to allow DC synchronization.
- Try different values for the "DC tuning" parameter in the EtherCAT Init block.
- If available, try a more performant Speedgoat machine (e.g. "Performance" machine instead of "Unit").
- Check the rate that the EtherCAT Init block is in. For Main Shift mode, the EtherCAT Init block should be in the base rate of the model.
- Try removing blocks from your model and see if the network can get into OP state. Remove everything except the EtherCAT Init and maybe a PDO. This will help rule out model complexity as being the issue.
- In MATLAB R2020a and earlier, disable graphics mode.
This article has more tips for achieving fast EtherCAT cycle task times with Speedgoat:
Best practices for Using Speedgoat as an EtherCAT Main Device with Simulink Real-Time - MATLAB Answers
Otherwise, you will need to reduce the model sample time, or further reduce the model's complexity.
