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.
Some possible ways to improve the performance are below:
- Toggle the EtherCAT DC algorithm in the TwinCAT configurator from Main Device 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 simplifying your model and see if the network can get into OP state. Remove everything except the EtherCAT Init block and a PDO block. This will help rule out model complexity as being the issue.
- In MATLAB R2020a and earlier, disable graphics mode.
This MATLAB Answers post has more tips for achieving faster EtherCAT cycle task times with Speedgoat targets:
https://www.mathworks.com/matlabcentral/answers/2085438-best-practices-for-using-speedgoat-as-an-ethercat-main-device-with-simulink-real-time
Finally, you can also reduce the model's fundamental sample time, or further reduce the model's complexity.
