How Consecutive Frame Drops Crashed an Entire EtherCAT Network — and How We Fixed It

Posted by on

1. Fault Symptoms

In an EtherCAT network, all slave modules occasionally switch to the INIT_NO_COMM state. In the System Manager or TwinCAT log, the following alarm messages are displayed:


Device 1 (EtherCAT): Frame missed 10 times (frame no. 0)

Device 1 (EtherCAT): Frame return -> force 10 times reinitialization!

2. Root Cause Analysis

This fault occurs when EtherCAT data frames are lost consecutively ten times, forcing the EtherCAT master to enter the INIT state. Consequently, all slave modules also switch to the INIT state.
Possible causes include:

  • EMC (electromagnetic) interference

  • Poor or damaged Ethernet cables

  • Loose or intermittent Ethernet connections

  • Unstable or loose RJ45 connectors

  • Faulty slip ring contact

  • Defective slave module hardware

3. Troubleshooting Procedure

To determine the specific cause of the network communication failure, follow the steps below:

Step 1

In the master device’s Advanced Settings, uncheck the option “LogCRCCounters”, as shown in the image.


Step 2

In the EtherCAT View, add the following registers for diagnostic monitoring:
0x0300–0x030A and 0x0310–0x0312, as shown in the image.



Step 3

Activate the modified TwinCAT configuration and restart the TwinCAT system.
(Refer to the image for the correct configuration sequence.)




Step 4

After restarting TwinCAT, open the Online tab of the EtherCAT master.
The counter values are displayed in a word-oriented format.



Step 5

Let the system run until communication errors are detected.
The more errors captured, the better for analysis.



Note: Closing the project or restarting TwinCAT will reset the counters,
whereas minimizing or switching windows will not clear the data.
Export the recorded values for further analysis.

Step 6

Analyze the exported diagnostic report.
From the example below:



  • Term 2, Port A: 1 frame loss

  • Term 5, Port A: 3 frame losses

  • Term 6, Port B: 1 frame loss

  • Drive 8, Port A: 10 frame losses

This indicates the highest number of lost frames occurred at Drive 8, Port A.

Step 7

Inspect the Ethernet cable and connector at Drive 8, Port A.
When the connector was touched, CRC errors appeared on the corresponding slave.
After disconnecting the cable, physical damage was found.
Replacing the damaged Ethernet cable restored stable communication — no further errors occurred even when the cable was moved or shaken.



Fault cause identified and resolved. (See image with red arrow.)

Step 8

Finally, reactivate the initial configuration to restore the original device setup.
System functions normally after verification.