EtherCAT lost frame (WKC) — checklist to find the bad node

On EtherCAT, a Lost Frame or wrong Working Counter (WKC) means the frame looping through the slaves got corrupted, or a slave is not processing correctly. Common symptoms: a slave won't reach OP state, the network is intermittent, errors rise as the machine vibrates/heats. Most are physical (cable/EMC) or DC/topology config.

Common causes

1. Cable & RJ45 — loose crimp, poor cable, bent/hidden break (#1 cause, especially at vibration points).
2. EMC noise — run in the same tray as power/VFD cables, poor shield grounding.
3. DC (Distributed Clock) sync — wrong sync config for servos that require DC.
4. Terminal order / topology — wrong EL terminal position, missing segment coupler (EK11xx), wrong E-bus.
5. Faulty/overheating slave — an ESC (EtherCAT Slave Controller) goes intermittent when hot.

Checklist to find the bad node

1. Read errors by position The master (e.g. TwinCAT) points to which slave has wrong WKC / dropped — start at the node right after the fault point.
2. Count Lost Frame counters See which slave port's counter rises to find the suspect cable segment.
3. Test cable & connector Swap/replace the suspect cable, re-crimp RJ45; gently shake the panel to see if the error jumps.
4. Separate noise Route the EtherCAT cable away from power cables; verify the shield is grounded at one point.
5. Check DC & config For servo axes: verify DC is enabled correctly, sensible cycle time; reload the ENI/config if wrong.
6. Isolate the suspect slave Temporarily remove the suspect node (or replace it) to confirm; if the error clears → that's the node.

When to call an expert

EtherCAT faults that come and go with heat/vibration are hard to catch — needing counter analysis, sometimes an analyzer. DeepDebug has a real Beckhoff lab (CX + EL terminals) to reproduce the scenario and support remotely.