05 — EtherCAT

Processing on the fly — sub-microsecond determinism over standard Ethernet.

Estimated 35 minutes.

What is EtherCAT?

EtherCAT (Ethernet for Control Automation Technology) is the open industrial Ethernet developed by Beckhoff and managed by the EtherCAT Technology Group. It is the dominant choice anywhere you need fast, deterministic, synchronised motion — packaging, semiconductor, robotics, CNC.

Standard Ethernet, radically used.

EtherCAT runs on ordinary Cat5e cable and ordinary RJ45. The frames are ordinary IEEE 802.3 Ethernet frames with EtherType 0x88A4. The "magic" is entirely in how slaves process the frame — not in the cable, not in custom switches.

No switches. A logical ring.

EtherCAT is wired as a daisy chain or line. There are no switches — every slave has two ports and forwards the frame out the other side. The last slave loops the frame back, so the wire forms a logical ring. One master, many slaves, one cable run.

The killer trick: processing on the fly.

In Modbus or EtherNet/IP, each device receives a frame, copies it into a buffer, processes it, builds a reply, and sends it back. EtherCAT slaves do not do that. They process the frame as it streams through their hardware — reading their bytes and writing their bytes in nanoseconds, without ever stopping the frame.

Watch the frame fly through.

One frame leaves the master, passes through every slave in turn, and returns. Each slave touches its bytes on the way past.

Why this matters.

Because the frame is never stopped, the network can serve hundreds of slaves in a single round-trip — typically 30–100 µs for an entire I/O update. Bandwidth utilisation is over 90% (vs ~5–10% for typical industrial Ethernet). That is what makes sub-millisecond control of dozens of axes practical.

How many frames per cycle?

A motion controller updates 64 servo drives at a 1 ms cycle. How many Ethernet frames does the EtherCAT master typically send per cycle to do that?

• 64 — one per drive.
• 128 — one request and one response per drive.
• 1 — one frame visits all 64 drives and returns.
• Depends on the switch latency.

Distributed Clocks (DC).

For coordinated motion, every axis must act at exactly the same moment. EtherCAT solves this with Distributed Clocks — every slave has a hardware clock, and the master synchronises them all to one reference clock (usually the first DC-capable slave) to within ~1 µs.

How DC sync works.

During startup the master measures the propagation delay to each slave (the frame round-trip times tell it exactly how far each slave is "down the wire"). It then writes a per-slave offset so every clock reads the same time. Drift is corrected continuously during cyclic operation.

Before vs after DC sync.

Toggle to see what synchronising the clocks actually does for the slaves on the line.

Sync, not just send.

The cleverness is not just timing — it is that a slave can be told "act at timestamp T". Because every slave's clock agrees, every slave fires its output at the same physical moment. That is what makes coordinated 5-axis CNC interpolation possible over a single Ethernet wire.

Four ways to address a slave.

EtherCAT has four addressing modes, each with its own pair of commands. You will see all four — auto-increment for startup, configured for one-to-one ops, logical for the cyclic I/O exchange, broadcast for global queries.

Pick the addressing mode that fits.

Four scenarios. Each fits exactly one mode — the wrong pick has a visible cost.

Logical addressing is the fast path.

During cyclic operation the master uses LRW (Logical Read/Write) to push and pull the entire process image as one block. Each slave's FMMU (Fieldbus Memory Management Unit) maps a slice of that block to its internal registers. No per-slave addressing overhead — that's why one frame can serve dozens of slaves.

One frame, many datagrams.

An EtherCAT frame contains one or more "datagrams". Each datagram is a self-contained command (cmd + address + length + data). One frame can mix logical reads, broadcast queries, and configured writes — all in one trip.

Why one frame instead of many.

Slide the slave count, toggle packed vs split. The cycle-time gap is the whole story of EtherCAT.

Working Counter (WKC).

Every datagram has a Working Counter — each slave that successfully processes the datagram increments it. The master knows the expected WKC for each datagram. If the value comes back wrong, it knows exactly which datagram had a problem — and therefore which slave or set of slaves.

Working Counter mismatch.

You run a cyclic LRW datagram that should serve 12 slaves. Expected WKC = 36, but you keep receiving WKC = 33. What is the most likely cause?

• CRC error — replace the cable.
• One slave is in an error state and not processing its slice.
• DC clock drift.
• Master has no licence.

Gotcha #1: Topology is the wire.

Because the frame physically passes through every slave, breaking the line breaks everything downstream. Cable redundancy (ring topology + master-side cable redundancy) is supported, but only if you wire it that way and configure it on both ends.

Gotcha #2: Order matters at startup.

Auto-increment addressing depends on slave position. If you swap two slaves on the wire, the configured addresses still work — but auto-increment commands now hit different physical devices. Engineering tools assign configured addresses early to avoid this.

Gotcha #3: It's still plaintext.

EtherCAT has no native authentication or encryption. It's designed to live on a dedicated machine network — never expose an EtherCAT segment to a corporate LAN.

You now know EtherCAT.

• Standard Ethernet (EtherType 0x88A4) on a daisy-chain logical ring — no switches.
• Processing-on-the-fly: slaves read/write their bytes as the frame streams through, never stopping it.
• One frame can carry many datagrams and serve hundreds of slaves per cycle.
• Distributed Clocks synchronise every slave's hardware clock to ~1 µs — coordinated motion solved.
• Four addressing modes: auto-increment, configured, logical (the cyclic fast path), broadcast.

EtherCAT complete.

• You can explain why EtherCAT is faster than every other industrial Ethernet.
• You understand DC sync and where it matters.
• You can read an EtherCAT frame and recognise its datagrams and WKC.
• You can debug "WKC mismatch" — start with the slave's AL Status.