Why is my EtherCAT model unable to get to the operational state?

8 views (last 30 days)
I use Simulink Real-Time on a Speedgoat target machine. Running a model with just the EtherCAT blocks to talk to the device consistently gets to the operational state (8). However, when I include additional blocks, I am rarely able to get to the operational state. Most of the time the model is able to get to the pre-operational state (2), and sometimes it is able to get to the safe-operational state (4).

Accepted Answer

MathWorks Support Team
MathWorks Support Team on 9 Aug 2022
Edited: MathWorks Support Team on 9 Aug 2022
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 Master-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. 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). 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 master-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. You could try a few things but these are not guaranteed to make a difference:
  • Toggle the EtherCAT DC algorithm in the configurator (e.g., from Bus Shift to Master Shift mode or vice versa) and see if chatter 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.
  • In R2020a and earlier, disable graphics mode.
Otherwise, you will need to reduce the model sample time or reduce the model's complexity.

More Answers (0)

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!