By the 5Tech engineering team · Published January 2023 · Reviewed for control-scope and functional-safety language. This is an educational engineering guide; all timing and standards figures are cited to the EtherCAT Technology Group, Beckhoff, or the relevant IEC standard, and the examples are labelled as industry patterns, not undisclosed customer results.
If you are a controls engineer or robotics integrator choosing a fieldbus for coordinated motion, the deciding question is rarely raw bandwidth — it is whether every axis can act on the same tick with jitter you can put a number on. EtherCAT (Ethernet for Control Automation Technology) answers that better than almost anything else for high-axis-count motion, because it processes one frame on the fly through every node and shares a common clock across the machine. But two honest caveats decide whether it is right for your machine: it is a wired, single-controller segment bus that does not route across your IT network, and its determinism is not the same thing as functional safety — that comes from a separate, certified layer called FSoE.
The problem: coordination, not throughput
When six motors move together to weld a seam or place a component, the constraint is temporal, not volumetric. Each axis must receive its command and act within a tightly bounded window, cycle after cycle, or the tool path degrades and mechanical wear climbs. Standard office Ethernet over TCP/IP is built for the opposite goal — it maximises average throughput and tolerates variable delivery. Packets arrive when they arrive; retransmission and buffering trade latency for reliability. That is exactly wrong for a control loop, where a late frame is a missed setpoint.
Traditional fieldbuses fix the timing but pay for it in a different currency: the controller (the EtherCAT specification now calls it the MainDevice, historically the master) addresses each device in turn and waits for a reply, so the cycle time grows with every node you add. EtherCAT was designed to break that trade-off.
A fieldbus for motion is judged by its worst cycle, not its average one. Determinism is a promise about the slowest frame.
Processing on the fly: one frame for the whole line
EtherCAT inverts the store-and-forward model. The controller sends a single Ethernet frame that physically passes through every node in the segment. In the ETG's own words, "each EtherCAT SubDevice reads the data addressed to it 'on the fly', and inserts its data in the frame as the frame is moving downstream" (ETG). The last node loops the frame back, and it returns to the controller fully populated with every device's inputs.
The reason this is fast — and, more importantly, consistent — is that the work happens in silicon. Every node contains an EtherCAT Slave Controller (ESC), a dedicated chip that extracts and inserts data as the bits stream past, without waking the device's host microprocessor. The frame "is delayed only by hardware propagation delay times" (ETG). Because processing is fixed-function hardware rather than software, adding nodes barely moves the cycle time and does not inflate jitter — which is the whole point. Only one node per segment, the MainDevice, is allowed to originate a frame; every other node simply forwards it downstream. That single-controller design is central to the determinism, and it is also one of the honest limits we return to below.
How "processing on the fly" works: one frame streams out through the daisy chain, each node's ESC reads its outputs and writes its inputs as the bits pass, and the frame loops back to the controller. Adding nodes adds hardware propagation delay, not a per-device round trip. (Illustrative schematic of the EtherCAT mechanism, not a specific wiring diagram.)
Distributed Clocks: acting on the same instant
Low latency is necessary but not sufficient for coordinated motion. Six axes that each respond quickly but at slightly different moments still produce a rough path. EtherCAT closes that gap with Distributed Clocks (DC). One node is designated the reference clock, and every other node disciplines its local clock to it. During start-up and continuously thereafter, the network measures the propagation delay between nodes and compensates for it, so all clocks agree "to within much less than 1 µs of each other" and the resulting system jitter is "significantly less than 1 µs" (ETG; the mechanism aligns with IEEE 1588 Precision Time Protocol). Beckhoff documents the same distributed-clock behaviour in its TwinCAT / EtherCAT system documentation.
That shared time base is what makes multi-axis interpolation — tracing a smooth curve with a robot arm — reliable, because every drive latches its new target on the same synchronised edge rather than whenever its frame happened to arrive.
Cycle time and jitter: budget the worst case
The headline figures are strong: roughly 100 servo axes in ~100 µs and 256 digital I/O in ~11 µs (ETG). But treat them as what the wire can do, not as a spec for your machine. Your achievable cycle time is set by the whole chain: the MainDevice's real-time performance, the number and type of nodes, the process-data size, and — often the real limiter — how much computation your control task does each cycle. The number that governs motion quality is the jitter of the synchronised output, not the average cycle time, so specify and measure both, and design to the worst case you can tolerate.
One distinction matters more than any single figure: a deterministic cycle is not, by itself, a safe cycle. Hard real-time timing means the standard control loop is predictable; it says nothing about the fault detection, redundancy, and certification that a safety function requires. We separate those two ideas explicitly below.
Coordinated multi-axis motion is the use case EtherCAT was built for: many drives latching new targets on the same synchronised tick so the tool path stays smooth.
Topology, wiring, and the services on top
EtherCAT runs on ordinary 100BASE-TX Ethernet cabling — up to 100 m between nodes, with 100BASE-FX fibre for longer hops — and supports line, tree, star, and daisy-chain layouts without managed switches (ETG). Closing the line into a ring adds cable redundancy: a single broken connection no longer stops the machine. Hot Connect lets sections — a tool changer, a removable fixture — attach and detach while the rest of the line keeps running, with changeover detection the ETG cites at under 15 µs.
EtherCAT is also more than a wire protocol. It carries standardised mailbox services so one cable handles both real-time control and routine maintenance. Define each acronym once and the picture is clear:
- CoE (CANopen over EtherCAT) — CANopen device profiles and parameter access, so existing CANopen device logic maps onto the faster transport.
- SoE (Servo drive profile over EtherCAT) — the SERCOS/drive profile standardised alongside CoE in IEC 61800-7, aimed squarely at motion drives.
- EoE (Ethernet over EtherCAT) — tunnels ordinary Ethernet (for example a device's web interface) across the same network.
- FoE (File over EtherCAT) — a TFTP-like service for firmware updates without a second cable.
Because EtherCAT operates at the data-link layer (EtherType 0x88A4) rather than over IP, these services stay inside the segment; the network is not routed across subnets the way office traffic is. That is a feature for determinism and a limitation for plant-wide integration — again, more below.
Safety is a separate, certified layer — not the base protocol
This is the point most worth getting right. Standard EtherCAT is deterministic, but it is not a functional-safety protocol. Safety-rated signals — emergency stop, safe torque off, light curtains — are carried by a distinct layer, Safety over EtherCAT (FSoE), also known as FailSafe over EtherCAT. FSoE was developed according to IEC 61508, is suitable for applications up to Safety Integrity Level (SIL) 3, is standardised in IEC 61784-3 (as FSCP 12, i.e. IEC 61784-3-12), and is certified by TÜV Süd Rail (EtherCAT Technology Group — Safety over EtherCAT).
The architecture matters: FSoE uses the black-channel principle. The standard EtherCAT communication is treated as a "black channel" that is not considered safety-relevant; the safety guarantees live entirely in the FSoE safety container and its own error-detection mechanisms, which ride inside the normal cyclic process data. So the wire and the ESC are not what makes a function safe — the certified FSoE layer is. In 2021 the ETG confirmed FSoE meets the extended requirements of IEC 61784-3:2021 (Ed. 4.0) without changes.
Standard EtherCAT — the "black channel"
Deterministic, low-jitter control and I/O. Fast and predictable, but not safety-rated on its own. In FSoE terms it is explicitly treated as not safety-relevant.
FSoE — the certified safety layer
Safety containers carrying E-stop, safe torque off, and the like, certified to IEC 61508 SIL 3 and IEC 61784-3. Rides on the same wire; owns the safety guarantee independently of it.
Consolidating safety and motion onto one infrastructure genuinely cuts wiring and simplifies diagnostics. But the certified safety scope belongs to FSoE and the safety devices at each end — never assume the base fieldbus provides it.
An honest comparison — and when EtherCAT is not the answer
EtherCAT is excellent for what it targets, but PROFINET, EtherNet/IP, and the emerging Time-Sensitive Networking (TSN) toolbox each win in different plants. The table below sketches the trade-offs; the non-EtherCAT figures are typical, implementation-dependent values from the referenced comparisons, not fixed specifications, and vendor ecosystems change fast.
| Approach | How it gets determinism | Typical motion cycle | Infrastructure | Where it fits best |
|---|
| EtherCAT | Processing on the fly + Distributed Clocks | ~100 µs / 100 axes; jitter < 1 µs (ETG spec) | No managed switches; single controller per segment | High-axis-count, tightly synchronised motion |
| PROFINET IRT | Time-scheduled transmission (IRT) | Down to the low-hundreds of µs (typical) | Needs IRT-capable hardware-timed switches | Siemens-centric plants; mixed automation + motion |
| EtherNet/IP (CIP Motion) | CIP Sync over standard Ethernet/IP | ~1 ms class (typical) | Standard/managed Ethernet; fully IP-routable | Rockwell-centric plants; easy IT/plant-wide integration |
| TSN (IEEE 802.1) | Layer-2 shaping (e.g. 802.1Qbv time-aware shaper) | Higher than EtherCAT for hard motion (toolbox, not a protocol) | Converged, open, multi-vendor Ethernet backbone | Mixing many protocols on one deterministic backbone |
TSN deserves a clarification often lost in marketing: it is not a competing fieldbus. It is a set of IEEE 802.1 Layer-2 standards that make open Ethernet deterministic enough to carry mixed traffic; it does not define an application/device layer the way EtherCAT does. For hard motion you still need an application protocol on top, and the ETG has published ETG.1700 so EtherCAT segments can be mapped across a TSN backbone rather than replaced by it — the two are complementary, not either/or.
Choose EtherCAT when: (axis count × synchronisation tightness × cycle-rate demand) outweighs (installed-base & vendor alignment + plant-wide IP-routing needs + your team's existing toolchain).
Designing and operating a machine on EtherCAT
Protocol choice is the start, not the finish. A dependable EtherCAT machine also settles several decisions that outlast commissioning:
- Controller architecture: a hardware MainDevice, a real-time OS with an EtherCAT stack, or a soft-master on a PREEMPT_RT Linux kernel — chosen against your real cycle-time and jitter budget, not the datasheet best case.
- Cabling and topology discipline: determinism depends on cable quality and correct node ordering. Document the physical topology so field service can reason about it, and decide up front where ring redundancy is worth the extra cable.
- Device conformance: verify third-party nodes are ETG conformance-tested to avoid subtle timing faults; keep the ESI (EtherCAT Slave Information) files under version control.
- Diagnostics and lifecycle: use the working-counter and error registers to catch marginal connections before they cause downtime; plan firmware roll-out (via FoE) and rollback, and treat FSoE parameters and safety sign-off as change-controlled artefacts, re-validated after any safety-relevant change.
What to remember
- EtherCAT's edge is coordination: one frame processed on the fly, plus Distributed Clocks giving jitter < 1 µs (ETG) so every axis acts on the same tick.
- Budget and measure worst-case jitter and full-cycle time on your machine — the ~100 axes / 100 µs figure is what the wire can do, not a promise for your controller.
- Determinism is not safety. Functional safety comes from FSoE — a separate layer certified to IEC 61508 SIL 3 / IEC 61784-3 over a "black channel" — never from the base protocol.
- It is a wired, single-controller, non-IP-routed segment bus: superb for motion, a poor fit for plant-wide IT integration or slow processes.
- If your plant already runs PROFINET or EtherNet/IP, or a 1 ms cycle is plenty, ecosystem fit may beat EtherCAT's speed.
Where to start
Pin down the numbers before the protocol: how many synchronised axes, the cycle time and the worst-case jitter you can tolerate, whether you need certified safety functions on the same wire, and how the machine has to talk to the rest of the plant. Those four answers usually decide EtherCAT versus the alternatives faster than any benchmark. If you are specifying a new machine or chasing timing problems on an existing one, our robotics and automation team designs and integrates EtherCAT-based motion systems end to end — controller architecture, distributed-clock configuration, FSoE safety scope, and diagnostics. Book a free engineering consultation to talk through your motion-control requirements.
References & further reading
- EtherCAT Technology Group — Technology overview: processing on the fly, cycle-time figures (1000 I/O in 30 µs, 100 axes in 100 µs, 256 digital I/O in 11 µs), Distributed Clocks jitter < 1 µs, 65,535 devices per segment, single MainDevice, topology, cable redundancy, and Hot Connect.
- EtherCAT Technology Group — Safety over EtherCAT (FSoE): black-channel principle, IEC 61508 development, SIL 3 suitability, IEC 61784-3 standardisation, and TÜV certification.
- ETG press release (2021): FSoE meets the extended requirements of IEC 61784-3:2021 Ed. 4.0 without changes.
- Beckhoff Information System — EtherCAT Distributed Clocks: reference-clock selection and propagation-delay compensation.
- EtherCAT accepted as IEC standard: IEC 61158 (Type 12), IEC 61784-2 (CPF 12), and IEC 61800-7 drive profiles.
- EtherCAT Technology Group — EtherCAT and TSN: TSN as an IEEE 802.1 Layer-2 toolbox, and ETG.1700 for mapping EtherCAT across a TSN backbone.
The processing-on-the-fly schematic is an illustrative diagram of the EtherCAT mechanism, not a specific wiring diagram.
Send 5Tech one workflow, inspection task, sensor problem, robotics challenge, or prototype idea. We will review it and suggest a practical next step. Start My Free First Phase — a free first review of one idea. If it is not practical, we will tell you.