Real-time networks

EtherCAT Latency and Timing

How one Ethernet frame serves 40 joints in about a tenth of a millisecond, how the master knows every joint answered, and how all of them act at the same instant.

Physical layer100BASE-TX: 4b/5b + MLT-3, full duplex, CRC-32 per frame

TrickProcessing on the fly, no store-and-forward

40 joints≈ 109 µs round trip, ≈ 11% of a 1 kHz cycle

SimultaneityDistributed clocks + SYNC0, well under 1 µs

1. Processing on the fly

In ordinary switched Ethernet, every hop receives the whole frame, checks it, then sends it on. Delay per hop is at least one frame time. EtherCAT slaves contain an EtherCAT slave controller (ESC) that sits in the data path. As the frame streams through, the ESC reads the bytes addressed to it (its outputs: torque or position commands), overwrites the bytes reserved for its inputs (encoder position, current, status), and forwards every byte almost as soon as it arrives. The frame never stops.

Same 68 µs frame. A store-and-forward hop cannot start sending until the last byte has arrived, so delay grows by a full frame time per hop. An EtherCAT slave controller reads its bytes and inserts its own as they pass, so each hop adds only the PHY and controller delay.

2. A line that behaves as a ring

Cabled as a line, it behaves as a ring. Full-duplex 100BASE-TX gives each cable a pair in each direction. The last node, with nothing on port 1, loops the frame back, so it passes every node twice and returns to the master with all the inputs filled in.

One frame per cycle carries every joint's data. Each node is touched twice: once outbound, where it processes, and once on the return, where it just forwards. The master sends the frame from one port and receives it back on the same port, with every slice filled in.

3. The round-trip budget

frame: (40 joints × 20 B + 52 B overhead) × 8 / 100 Mb/s = 68.2 µsThe time to clock the frame onto the wire, paid once because nodes overlap their processing.

nodes: 40 × (0.6 µs outbound + 0.4 µs return) = 40 µsPHY plus ESC forwarding delay, roughly half a microsecond per pass with 100BASE-TX PHYs; check the slave controller and PHY datasheets.

cable: 2 × 40 m × 5 ns/m = 0.4 µsPropagation is negligible at robot scale.

round trip ≈ 68 + 40 + 0.4 ≈ 109 µs 1 kHz cycle = 1,000 µs → 11% used

One 1,000 µs control cycle at 1 kHz. The round trip uses about 11% of it. Most of the delay is simply the time to clock 852 bytes onto a 100 Mb/s wire.

Halving the per-joint payload or going to a 4 kHz loop changes the picture quickly: at 4 kHz the window is 250 µs and this frame uses 43% of it. That is why high-rate loops either shrink the frame, split the robot into several segments, or move to 1 Gb/s EtherCAT G.

4. The working counter

Each slave that successfully reads and writes its part of a datagram adds to the working counter as the frame passes. The master compares the returned value with the number it expects. A missing or failed node shows up as a short count in the same cycle, and the Ethernet CRC (FCS) catches corrupted frames, so the master holds the last good values or reacts instead of acting on bad data.

On a robot, cables flex through every joint, so intermittent connectors are a real failure mode. The working counter turns that into a per-cycle check: the master knows within one cycle that a node did not respond, and the application decides what to do (hold position, ramp down, raise a fault). Functional-safety traffic adds its own layer on top (Safety over EtherCAT, FSoE), with sequence numbers and watchdogs per safe message.

5. Why there is no FEC

The control network's job is to deliver fresh data every cycle with fixed, small latency. Its error strategy is detection, not correction: CRC-32 discards a corrupted frame, the working counter flags a missing node, and the next cycle (1 ms later) carries fresh values anyway. Correcting errors with a block code would mean buffering whole codewords before decoding, and if every hop did that the per-node delay would grow from about half a microsecond toward a frame time, recreating exactly the store-and-forward delay EtherCAT exists to avoid. On a short, clean 100 Mb/s link the raw bit error rate is low enough that occasional discarded frames cost less than constant decode latency.

	Camera link (GMSL3)	Joint bus (EtherCAT)
Goal	Move a lot of data over a long, lossy cable	Move a little data with fixed, low latency
Modulation	PAM4 at 6 GBd (halves Nyquist)	MLT-3 at 125 MBd (100BASE-TX)
Error handling	Channel margin plus coding; latency is acceptable	Detect (CRC, working counter) and use the next cycle
Latency	Microseconds against a 33 ms frame: irrelevant	About 100 µs against a 1 ms loop: the main budget
Design rule	Buy reach with coding and DSP	Protect timing; keep the path cut-through

6. Distributed clocks

Getting data to every joint within 109 µs is not enough. If joint 1 samples its encoder 20 µs before joint 40, the controller is combining measurements from different moments, and coordinated motion smears. EtherCAT's distributed-clock (DC) system gives every slave the same notion of time.

Top: each slave's free-running clock starts from a different time and drifts. Bottom: after the master measures the propagation delay to each slave and writes offsets, every slave holds the same system time, and each generates SYNC0 locally at the same programmed instant, so all joints sample and actuate together, typically to well under 1 µs.

Measure delay. At startup the master sends a broadcast that each ESC timestamps on each port, outbound and on return. The differences give the propagation delay from the reference clock (usually the first DC-capable slave) to every node.
Set offsets. The master writes each slave's offset and delay so its local 64-bit system time matches the reference.
Track drift. Every cycle the reference clock's time is distributed in the frame and each slave trims its clock rate, so crystals that differ by tens of ppm stay aligned.
Fire SYNC0. Each slave generates SYNC0 from its own synchronized clock at the same programmed system time. All joints latch sensors and apply new setpoints together, with jitter typically well under 1 µs.

The split is clean: latency decides whether data arrives within the cycle; distributed clocks decide whether every joint acts at the same instant. A 109 µs round trip with 50 ns of jitter between nodes is a far better control system than a 20 µs round trip where each node acts whenever its frame arrives.

Summary

One line

Processing on the fly keeps each hop to about half a microsecond. The line-wired ring passes 40 joints twice for a round trip of about 109 µs, about 11% of a 1 kHz cycle. The working counter and CRC check integrity every cycle instead of correcting errors, because correction would add latency. Distributed clocks and SYNC0 make every joint sample and actuate within well under a microsecond of each other.