EtherCAT Slave Stuck Below OP

intermediate · 15 min

A slave that will not reach OP is telling you exactly what is wrong, if you read the AL status code before you touch anything. This procedure splits the fault into four families, then fixes each — using real registers, counters and ports.

ℹ️ A slave stuck in SAFE-OP with an error is not a worse failure than one stuck in INIT — it is a much better one. Reaching SAFE-OP proves the link, the mailbox, the parameter download, the PDO mapping and the FMMUs all worked. That eliminates most of the network and leaves only three possible causes. Treat SAFE-OP + error as the diagnosis narrowing itself for you, and read the AL status code before you change anything.

An EtherCAT slave climbs INIT, PRE-OP and SAFE-OP but refuses OP, and it is the AL Status Code held in register 0x0134 — here 0x001A, a synchronization error — rather than the state itself that names the failing check, while on the rail the working counter comes back exactly one increment short at the output terminal that stayed behind.

Read the code first: which of four things is wrong

A slave (newer specs say SubDevice) is any device on the line — drive, I/O coupler, valve island. Inside each is an ESC, the EtherCAT Slave Controller chip. Refusing a state change, it writes an AL status code: 16 bits saying why.

Get that code before touching anything. In TwinCAT (vendor-specific) it is on the slave's Online tab beside the state buttons; on the wire, ESC register 0x0134:0x0135, with the error flag at bit 4 of AL Status register 0x0130. The master writes the requested state to AL Control at 0x0120:0x0121.

The code puts you in one of four families. Note which state each family leaves the device in — that is half the diagnosis.

• Inputs or outputs not valid — 0x0018, 0x0019, 0x002B. Refused on SAFE-OP to OP, device stays in SAFE-OP with the error flag. Split this family: 0x0019 and 0x002B point at the master, but 0x0018 means the slave application cannot produce valid inputs — a sub-module, sensor or internal fault at that device. Do not go hunting in the master for 0x0018.
• Synchronisation — 0x001A, 0x002C, 0x002D, 0x0030, 0x0032, 0x0033, 0x0034, 0x0035. A distributed-clock problem. Most of these are raised from SAFE-OP or OP and leave the device in SAFE-OP; 0x0035 (and 0x0036 / 0x0037) is raised on PRE-OP to SAFE-OP and leaves it in PRE-OP.
• SyncManager watchdog — 0x001B. Process data stopped arriving in time. Raised from SAFE-OP or OP, resulting state SAFE-OP plus the error flag.
• Mapping and configuration — 0x0024, 0x0025, 0x0026, 0x001E, 0x0028 fire on PRE-OP to SAFE-OP and leave the device in PRE-OP. 0x0017 and 0x001D are not confined to that transition — both can also be raised at SAFE-OP or on SAFE-OP to OP, so a device sitting in SAFE-OP with 0x0017 is normal, not a contradiction.

What each transition actually configures

INIT — no mailbox, no process data. Register access only. Bootstrap is reachable only from here.

INIT to PRE-OP — the master configures SyncManager 0 and 1 for mailbox traffic; the slave checks the mailbox was initialised correctly. A SyncManager (SM) is a buffer inside the ESC. Failures here are addressing, EEPROM or firmware faults, and leave the device in INIT.

PRE-OP — mailbox works, cyclic data does not. CoE (CANopen over EtherCAT) parameter download happens here.

PRE-OP to SAFE-OP — the heavy one, and where nearly all the checking lives. The master configures the process-data SyncManagers (SM2 onward), the FMMU channels (Fieldbus Memory Management Unit — maps slave memory into the master's process image), and the PDO mapping (the cyclic I/O payload), and transfers device parameters over the mailbox. The slave then checks the process-data SyncManager channels and, if required, the Distributed Clocks (DC, the shared time base) settings. Failures here usually mean the master's ESI file does not match the hardware in front of you.

SAFE-OP — process data flows and inputs update cyclically, but the slave holds its outputs in a safe state. The machine reads without acting.

SAFE-OP to OP — no new configuration. The master must already be sending valid output data; the slave then copies outputs through. This is why the SO refusals are about validity (0x0018, 0x0019, 0x002B, 0x002D) rather than about setup.

Why SAFE-OP + error is a good place to be stuck

A slave that reached SAFE-OP already proved the link is up, the mailbox works, CoE parameters downloaded, the PDO mapping was accepted, the FMMUs are configured, the DC settings were accepted, and cyclic frames refresh inputs.

So SAFE-OP + error leaves a short named list: outputs not valid, inputs gone invalid at the device, the shared time base lost or never arriving, the SyncManager watchdog expiring, or a SyncManager re-check failing at SO time (0x0017). Five, not thirty. A slave stuck at INIT narrows nothing.

Working counter errors and what they prove

Every datagram ends with a 16-bit working counter (WKC), incremented by each slave the datagram successfully addresses. The increments are per command type, and this is where people get it wrong:

• a read command: +1
• a write command: +1
• a read/write command (LRW): +1 for the read, +2 for the write, +3 when both succeed

So +3 per device is the combined read-write case only. Do not apply +2 to a plain write datagram.

If the returned WKC is short of what the master expects, the master cannot trust that datagram. What happens to the data next is master-specific and worth knowing before you read a screen: in TwinCAT the slave's WcState goes to 1 and, by default, the inputs freeze at their last valid value — they do not blank. Only with "Clear Invalid Input Data" enabled are they zeroed. Stale but plausible numbers on an HMI are the trap here.

A wrong WKC proves exactly one thing: a device that should have processed this datagram did not. It does not say why. Cross it with the state list — the slave that fell out of OP is usually the one that stopped counting. A stable wrong WKC points at configuration; a flickering one at the physical layer.

For physical faults read the ESC error counters:

• 0x0300:0x0307 — two bytes per port, not one. For port y, the counter pair sits at 0x0300+y·2 : 0x0301+y·2. The even byte (0x0300 / 0x0302 / 0x0304 / 0x0306) is the Invalid Frame Counter — an invalid frame initially detected at that port. The odd byte (0x0301 / 0x0303 / 0x0305 / 0x0307) is the physical-layer RX Error Counter. TwinCAT's "CRC" figure is the even byte; it clears the odd bytes alongside it but does not display them.
• 0x0308:0x030B — Forwarded RX Error Counter, one byte per port.
• 0x0310:0x0313 — Lost Link Counter, one byte per port (counts only while the port is in auto / auto-close mode).

The localisation trick is the asymmetry between those first two. The first ESC to see a corrupt frame discards register operations, counts an initial error on the port it arrived at, and marks the outgoing frame with one extra nibble after the invalid CRC. Every device downstream sees that marking and counts a Forwarded RX Error instead. So the bad segment is the cable feeding the port of the first device in bus order counting an initial error — not merely "a device with a rising counter", since every device after it will also be counting something.

In TwinCAT (vendor-specific) the initial-error counters are the CRC column on the master's Online tab, listed per port A/B/C/D separated by dots, with a Clear CRC button; the Topology view marks an affected port with an unfilled red circle and the tooltip gives the count.

Cable order matters

EtherCAT is processed on the fly in a logical ring, so physical position is functional position. A frame enters the ESC at port 0 (A), passes the processing unit — logically located between port 0 and port 3 — and leaves by port 3 (D) if a link exists there; otherwise port 1 (B), then port 2 (C). With no link, the ESC loops the frame back.

Swap two cables and the slaves change order. If the devices differ, or aliases are set, you get a topology or wrong-device-at-position error. If the devices are identical and no Configured Station Alias is set, you may get no error at all — the master addresses by position and simply commands the wrong physical device. That is the dangerous case, and the reason to set aliases on interchangeable hardware.

Distributed clock problems

The first DC-capable slave becomes the reference clock; the master measures and compensates the propagation delay introduced by each device during initialisation, and any topology change means those delays must be recalculated and rewritten. Sync fails when master cycle time and the slave's SYNC0 cycle disagree, when master jitter is too high, when topology changed and delays are stale, or when a non-DC device sits where the reference clock was expected.

Hot connect groups

A hot connect group is a bus section allowed to appear and disappear while the network runs — a tool changer, a removable trolley. Because it can be absent, the master cannot identify its devices by position. It uses explicit identification: the Configured Station Alias in the slave EEPROM (1–65535), or the Requesting ID / Direct ID methods in ETG.1020. Two identical aliases, or one left at zero, and groups become indistinguishable.

Before you touch anything

Safety gate — read this before step 1, because step 8 is the first action and steps 1–7 exist so you can skip it. Forcing a state change, re-scanning the bus, clearing counters or reseating a cable drops outputs on every downstream device and can stop the machine mid-motion. Steps 1 through 7 are read-only and safe on a running plant. Step 8 is not. Do step 8 only with the machine safe and the area clear.

Step-by-step

1. Look, do not click. Record every slave's state and AL status code, plus the master's WKC error count and the CRC counters, before anything else. Changing state or clearing counters destroys the evidence.
2. Find the first bad device in bus order. One fault knocks over everything downstream; only the topmost device matters.
3. Read its AL status code and place it in one of the four families above. Check which state the code leaves the device in — that alone tells you which transition failed.
4. Walk the error counters along the whole line, in order. You are looking for the first device whose initial error counter (0x0300 / 0x0302 / 0x0304 / 0x0306, TwinCAT's CRC column) is rising while the devices before it are clean. Devices further along counting Forwarded RX Errors (0x0308:0x030B) are downstream fallout, not the fault. The bad segment is the cable feeding that first port. Rising Lost Link counts mean an intermittent connector.
5. For 0x001B, look at the measured gap between output frames, not just the nominal cycle. The SM watchdog is retriggered by each write to the output SyncManager, so jitter, a task overrun, a pre-empted real-time task or a stalled master trip it while the configured cycle still looks fine. In TwinCAT the SM watchdog defaults to 100 ms and lives under Advanced Settings → Behavior.
6. For the sync family, confirm the reference clock is the device the master expects, that SYNC0 cycle matches the task cycle, and that propagation delays were recalculated after any topology change. Separate 0x0035 (refused at PRE-OP to SAFE-OP — the device rejects the requested cycle time outright) from 0x001A / 0x0032 / 0x0034 (it accepted the configuration and then failed to hold lock).
7. For 0x0019 and 0x002B, check the master's task is running and its process image is mapped. For 0x0018, look at the slave instead: a missing sub-module, an unplugged sensor, or an internal fault it must clear before it can offer valid inputs.
8. Fix one thing, then retest — under the safety gate above.

Never do this

Do not re-scan the bus to "refresh" a live machine. This is the expensive mistake people really make: someone scans, the master rebuilds its device list from what it finds, and the working configuration — PDO mapping, aliases, hot connect groups, tuned parameters — is overwritten by whatever is plugged in at that moment. Outputs drop across the bus, and the machine will not come back, because the settings that made it work are gone.

Scanning is a commissioning action, not a diagnostic one. Diagnose with state, AL status code and error counters — all read-only. And never clear CRC counters before writing the values down; that erases the only record of where the fault is.