EtherCAT is the protocol you reach for when 1 ms is too slow. Motion control, multi-axis robotics, high-speed test rigs, anything synchronized down to the microsecond — that is EtherCAT territory.
It looks like Ethernet, runs on the same cables, uses standard RJ45 connectors. But under the hood it does something no other industrial Ethernet protocol does: it reads and writes frames while they are still flying through the wire. That trick is what makes EtherCAT fast. Everything else in the protocol is built around it.
This article walks through how that trick actually works, what the frame looks like, where EtherCAT fits in a real plant, and where it falls down.
Table of Contents
The problem EtherCAT solves
Standard Ethernet was designed for general-purpose data communication, not deterministic control. Modern switched Ethernet eliminates collisions, but delivery timing can still vary because switches buffer and forward traffic based on network load. That variation is fine for email. It is a disaster for a servo drive that needs an update every 100 microseconds.
The first generation of industrial Ethernet protocols — Modbus TCP, EtherNet/IP, PROFINET RT — added determinism on top of standard Ethernet. They achieve 1 ms to 10 ms cycle times. Good enough for most factory I/O. Not good enough for tight motion control.
EtherCAT took a different approach. Instead of working around the buffering and timing variation, it eliminated them. There is one master. The master sends one frame. That frame passes through every slave in sequence, gets modified by each one on the fly, and comes back to the master. In highly optimized systems, EtherCAT cycle times can reach a few tens of microseconds, while most industrial applications operate between 100 µs and 1 ms — with sub-microsecond synchronization across hundreds of nodes.
How “processing on the fly” actually works
This is the core idea. Most people get a hand-wavy explanation. Here is what really happens inside a slave.
- The master builds an EtherCAT frame containing datagrams. Each datagram has a destination — a specific slave, a memory area inside that slave, and the data to read or write.
- The master sends the frame down the wire to slave 1.
- Slave 1 has dedicated EtherCAT Slave Controller (ESC) hardware. As the frame physically streams through this chip, the ESC reads the parts addressed to it, writes any output data into its own registers, and inserts input data back into the frame — all in the same instant the frame is passing. The frame keeps moving.
- The frame reaches slave 2. Same thing. The frame keeps moving.
- At the last slave, the frame is returned to the master through the network return path. It passes through all the slaves again on its way home.
- The master receives the modified frame, now containing every input value from every slave.
The whole round trip takes microseconds. The slaves are not buffering anything. They are not assembling responses. They are bit-shifting data into and out of a frame that is actively streaming through dedicated silicon.
This is why EtherCAT cannot be done in software on a regular Ethernet card. The slave side needs the ESC hardware. The master can run on standard Ethernet hardware because it does not need the on-the-fly trick — it just sends and receives complete frames.
Logical addressing: why one frame serves a hundred devices
Packing several datagrams into one frame helps, but it isn’t where EtherCAT’s efficiency really comes from. A two-channel digital input node contributes two bits of user data. Even a minimal datagram wrapped around it is mostly overhead.
The answer is logical address mapping. Instead of addressing individual nodes, the master sends a datagram covering a region of a 4 GB logical address space. Each slave is configured to know which slice of that space belongs to it. As the frame passes, every slave whose configured range matches inserts or extracts its data at the correct offset. One datagram, many devices served.
Inside each slave, the component doing this is the FMMU — the fieldbus memory management unit — which maps between the logical address space and the slave’s own memory, down to individual bits.
Three things fall out of this, and they’re what make EtherCAT feel different in practice:
The master does no remapping. The frame comes back carrying a completely sorted process image that can be handed straight to the control task. A traditional fieldbus master spends real CPU time rearranging scattered device data into something the application can use. EtherCAT delivers it pre-sorted by construction.
Physical order doesn’t matter. The standard says it plainly: the physical order of nodes is arbitrary and is only relevant during the first initialization phase. Move a device to a different position in the line and the process image is unchanged.
Each task gets its own image. A fast motion loop and a slow temperature loop don’t have to share a cycle time. Each control task can build its own process image and exchange it on its own schedule.
The standard’s own summary is the best short description of what EtherCAT is: a serial backplane for automation systems. Devices spread over hundreds of metres, behaving like cards in a rack.
By contrast, every PROFINET device on the same network is a full IP node reachable through standard switches — compare the trade-offs in our PROFINET vs PROFIBUS guide.
What an EtherCAT frame looks like
EtherCAT uses a standard Ethernet frame, but the payload is carved up its own way. The EtherType is 0x88A4, which is how Wireshark and switches recognize it.
| Field | Size | What it does |
|---|---|---|
| Ethernet header | 14 bytes | Destination MAC, source MAC, EtherType 0x88A4 |
| EtherCAT header | 2 bytes | Length (11 bits), reserved (1 bit), type (4 bits) |
| Datagram 1 | variable | First command in the frame |
| Datagram 2 | variable | Optional second command |
| … | … | More datagrams as needed |
| Datagram N | variable | Last command |
| Ethernet padding + FCS | 4 bytes + padding | Standard Ethernet trailer |
Each datagram inside the frame has its own header that includes a command (read, write, read-write), an address, a length, and an Interrupt Request field. At the end of each datagram is a Working Counter. This is one of the cleverest parts of the protocol.
The Working Counter
The Working Counter is a 16-bit field that every slave touched by that datagram increments. The master knows in advance how many slaves should have responded. If the returned Working Counter does not match the expected value, the master knows something is wrong — a slave is missing, broken, or did not process the command.
You do not need an acknowledgment from each slave. The Working Counter aggregates the responses into one number. This is part of why EtherCAT is fast: no per-device acks.
The variant nobody mentions: EtherCAT over UDP/IP
The standard defines two ways to carry EtherCAT datagrams, and almost every article online mentions only the first.
Directly in the Ethernet frame, with EtherType 0x88A4. Minimum overhead, maximum performance — and confined to a single Ethernet subnet, because routers won’t forward it. The standard notes that for machine control applications this usually isn’t a constraint. Multiple segments can be connected through switches between them, with each segment addressed by the MAC address of its first node.
Inside a UDP datagram over IP, on UDP port 0x88A4. This adds the IP and UDP headers, so slightly more overhead — but the traffic is routable, and any standard UDP/IP implementation works on the master side. The standard’s own example is building automation, where timing demands are lower and IP routing matters more.
So “EtherCAT can’t be routed” describes the common deployment, not the protocol. If a design needs EtherCAT traffic to cross a router and the cycle time budget allows it, the standard already provides for it.
The four addressing modes
Every EtherCAT datagram carries a command that combines an addressing mode with an operation. The pattern is regular once you see it laid out:
| Mode | Read | Write | Read-write |
|---|---|---|---|
| Auto increment — position-based, used at startup before addresses are assigned | APRD | APWR | APRW |
| Configured address — the station address the master assigned | FPRD | FPWR | FPRW |
| Broadcast — every slave on the segment | BRD | BWR | BRW |
| Logical — the 4 GB logical address space | LRD | LWR | LRW |
Two extra commands handle clock distribution: ARMW and FRMW, read-multiple-write variants where one slave’s value is read and written into all the others as the frame continues — the mechanism behind distributed clock synchronization.
The addressing mode also tells you which phase the network is in. Auto-increment commands dominate at startup, when the master is discovering devices by position. Logical commands dominate in cyclic operation, when the process image is being exchanged. Seeing auto-increment traffic in a running system means something is re-initializing.
The EtherCAT Wireshark dissector surfaces every one of these commands directly — exactly the set of opcodes you need when reading a capture alongside our Wireshark protocol dissection series.
Locating a fault: why slaves refuse to fix the checksum
Slaves modify frames in transit, so each one recalculates the Ethernet frame check sequence before passing it on. That raises an obvious question: what happens when a slave receives a frame whose checksum is already bad?
It does not repair it. The standard is explicit — the slave does not repair the FCS and instead flags the master by incrementing its own error counter, so that a fault can be located precisely.
That refusal is the feature. A slave that silently corrected the checksum would hide where the corruption started; every downstream device would see a clean frame and the fault would be invisible. By passing the damage along and counting the event locally, EtherCAT turns error counters into a map. Read them along the line and the bad segment sits between the last clean node and the first complaining one.
Combined with lost-link counters in each slave, this gives you cable fault localization as a built-in protocol feature rather than an afternoon with an oscilloscope.
Topology — and why it does not really matter
EtherCAT supports basically every topology. Line, tree, star, ring, daisy-chain, and combinations. In practice, most installations are line or ring.
Line topology is the simplest. Master → slave 1 → slave 2 → … → slave N. The last slave reflects the frame back. If any slave in the chain dies or a cable breaks, everything downstream goes dark.
Ring topology fixes that. The last slave connects back to the master through a second cable. The master can send frames in either direction. If a break happens anywhere, the master detects it and starts sending frames from both ends. Both halves of the network keep running. This is called cable redundancy and it is one of EtherCAT’s selling points for high-availability machines.
Branches are also possible. A slave with three Ethernet ports can fan out a sub-network. The frame still visits every node — just in a depth-first order.
The standard’s own reasoning for preferring line and tree is economic as much as technical: star topology means more cabling effort and more infrastructure cost, while a line running module to module with branches dropping into individual control cabinets matches how machines are actually built. The standard also flags topology as a significant influence on diagnostics, redundancy options, and hot-plug behaviour — worth remembering when someone proposes a topology change late in a project.
Importantly: standard Ethernet switches are generally not used within an EtherCAT segment, because frame buffering breaks the on-the-fly processing model. EtherCAT uses junctions instead, which look like switches physically but route the frame through each port in sequence rather than concurrently. Specialized EtherCAT infrastructure devices exist for specific use cases, but they all preserve the sequential processing principle.
Distributed Clocks — synchronizing to the nanosecond
EtherCAT can synchronize all slaves to within a few hundred nanoseconds of each other using a feature called Distributed Clocks (DC). This is critical for motion control where multiple axes need to move in lockstep.
Here is the principle. One slave — usually the first DC-capable one in the network — acts as the reference clock. The master then runs a delay measurement sequence: it measures the propagation delay between the reference and every other slave by sending a special frame and timing the response. Each slave’s local clock is adjusted by its measured delay. After this calibration, all slaves think it is the same instant.
The payoff is positional independence. A slave 80 m down the chain and one connected directly to the master apply their outputs at the same moment, because each knows its own offset and corrects for it. Without this, position in the line would translate directly into skew between axes — which is exactly what separates EtherCAT as a motion-control network from EtherCAT as a fast I/O network.
EtherCAT Distributed Clocks typically achieve synchronization accuracy well below 1 µs, comparable to hardware-assisted PTP implementations used in industrial automation. EtherCAT achieves this without any extra hardware or protocol overhead — the synchronization frame is just another EtherCAT datagram.
If you have used PROFINET IRT, this is the equivalent feature.
Inside a slave: FMMU, sync managers, and the SII
Four mechanisms account for most of what a master configures in an EtherCAT slave. Knowing them makes vendor documentation readable.
FMMU — maps logical addresses to the slave’s physical memory, with bit-level granularity. The number of FMMU channels a slave supports is one of its published capabilities. FMMU and the process image concept are also where EtherCAT diverges most sharply from routed-IP protocols such as PROFINET, where every node is addressable individually and there is no shared logical space.
Sync manager — coordinates access to memory that the network side and the application side both touch, in two distinct modes:
- Buffered mode for cyclic process data. Both sides may access at any time, and the newest data wins. Nothing blocks.
- Mailbox mode for acyclic messages. Handshaking ensures a message isn’t overwritten before it has been read.
That distinction is worth internalizing, because it encodes a design judgement. Process data is buffered because a slightly stale value is better than a blocked cycle. Parameter transfers use mailbox mode because a lost message is worse than waiting.
Distributed clock registers — local time, offsets, and propagation delay compensation.
Slave information interface (SII) — the slave’s own description memory. The master reads it during startup to learn what the device is and what it supports.
Each slave also runs watchdogs, which is how a device detects that the master has stopped talking to it and drops to a safe state on its own rather than holding its last outputs indefinitely.
Mailbox protocols — when you need more than I/O
Cyclic I/O exchange is the main job of EtherCAT, but there are times when you need to do something slower and more complex — read a parameter list, upload firmware, send an ASCII command to a sensor. EtherCAT handles this through mailbox protocols, which carry their own payloads inside EtherCAT frames.
The four common ones:
| Mailbox protocol | Full name | What it carries |
|---|---|---|
| CoE | CAN application protocol over EtherCAT | CANopen-style object dictionary access. The most common. Used by almost every servo drive and I/O coupler. |
| EoE | Ethernet over EtherCAT | Tunnels regular Ethernet traffic (HTTP, FTP, etc.) through the EtherCAT network. Useful for accessing a slave’s built-in web server. |
| FoE | File access over EtherCAT | Simple file transfer for firmware updates and configuration. |
| SoE | Servo drive profile over EtherCAT | Sercos-style commands for high-end servo drives. Mapped to the IEC 61800-7 standard. |
| AoE | ADS over EtherCAT | Beckhoff’s proprietary ADS protocol tunneled through EtherCAT. Mostly seen in TwinCAT systems. |
The cyclic I/O and the mailbox traffic coexist on the same wire. The master schedules them so that mailbox messages do not interfere with the cycle time of process data.
The EtherCAT State Machine
Every EtherCAT slave moves through a fixed set of states during startup and normal operation. The master commands transitions; the slave reports its current state. If you have ever debugged an EtherCAT system, you have seen these names. Knowing what each one means saves real time.
| State | What it means | What works in this state |
|---|---|---|
| INIT | Basic startup, no application running | No mailbox, no process data. Only register-level access by the master. |
| PRE-OP | Mailbox communication active | CoE, FoE, EoE messages work. Master configures the slave here. No process data yet. |
| SAFE-OP | Inputs are being exchanged, outputs are forced safe | Master reads inputs. Outputs stay in their safe state. Used during startup verification. |
| OP | Full operation | Cyclic I/O exchange in both directions. The normal running state. |
| BOOT | Optional firmware update mode | FoE file transfer for firmware updates. Other communication disabled. |
The master walks every slave from INIT → PRE-OP → SAFE-OP → OP during startup. If a slave refuses to transition (usually with an AL Status Code error), the master stops there and reports which slave is stuck.
Most “EtherCAT works in the lab but not on the machine” problems come down to a slave stuck in PRE-OP or SAFE-OP. The master diagnostic will tell you the slave number and the AL Status Code. Look up the code in the slave’s ESI file or datasheet — common causes are wrong PDO mapping, mailbox configuration mismatch, or invalid DC settings.
What an EtherCAT setup actually looks like
A typical EtherCAT system has three layers of devices:
Master — A PLC or industrial PC with an EtherCAT master stack. Examples: Beckhoff TwinCAT, Omron NJ/NX, Codesys, ABB AC500, KEBA. The master can be any computer with a normal Ethernet port — no special hardware needed on this side.
Couplers — Devices like the Beckhoff EK1100 that sit between the EtherCAT bus and a row of local I/O terminals. Couplers are slaves themselves and translate EtherCAT into the proprietary backplane bus of their I/O family.
Slaves — Servo drives, I/O modules, vision systems, sensors. Each has an ESC chip handling the on-the-fly processing.
When you commission a system, the master scans the network. Each slave reports its identity, vendor ID, and capabilities through its EEPROM. The master then loads ESI (EtherCAT Slave Information) XML files that describe what each slave can do. Configuration done.
Where EtherCAT wins
- Motion control with many axes. EtherCAT was built for this. Microsecond cycle times, nanosecond synchronization, deterministic by design.
- Compact installations where cabling matters. One cable daisy-chained through all devices versus a star to a central switch.
- High-speed test and measurement. Sample rates above 10 kHz across hundreds of channels work cleanly.
- Machine tool industry. Many CNC and machine tool platforms use EtherCAT for high-performance motion networks.
- Robotics. Most modern collaborative robots run EtherCAT between the controller and the joint drives.
Where EtherCAT does not fit
- Process plants. EtherCAT is line-topology and slave-dependent. A refinery wants redundant paths and fieldbus segments measured in kilometers. PROFINET, FOUNDATION Fieldbus, or HART are better fits.
- Mixed-vendor SCADA integration. EtherCAT does not expose itself well to SCADA layers. You usually put an OPC UA server on the EtherCAT master and let SCADA talk to that. See our guide on connecting any PLC to OPC UA.
- Wireless or long-distance. EtherCAT assumes a wired physical layer. Bridges over wireless or WAN break the determinism.
- Single-loop simple jobs. Putting EtherCAT on a project that just needs to read a flow meter every second is overkill. Modbus TCP would do the job for less money and effort.
Troubleshooting EtherCAT in the field
Most EtherCAT problems are physical or configuration issues, not protocol bugs.
| Symptom | Likely cause | What to check |
|---|---|---|
| Master cannot find any slaves | First slave dead, wrong port on master, broken cable | Swap the master’s TX/RX cable. Try a known-good slave at position 1. |
| Some slaves missing | Cable break or bad slave in the chain | The master tells you the last good slave number. The problem is between that one and the next one. |
| Working Counter mismatches | A slave is hung, EEPROM mismatch, slave reset mid-cycle | Look at the master diagnostics. Check the specific slave’s state (INIT/PRE-OP/SAFE-OP/OP) and any AL Status Code. |
| Slow cycle time, missed cycles | Master CPU overloaded, frame too large, or wrong NIC | Reduce cyclic data. Use a NIC with dedicated EtherCAT support. |
| Random jitter | Switch inside the segment (forbidden), or industrial noise on cable | EtherCAT must run direct cable to cable within a segment. Use shielded cable in noisy environments. |
| Distributed Clocks not syncing | Reference clock slave not DC-capable, or wrong reference selected | Verify the first slave supports DC. Change the reference assignment in the master config. |
| Cannot upload firmware | FoE not supported by slave, or wrong state | Slave must be in BOOT state for FoE. Check the ESI file for FoE support. |
EtherCAT and cybersecurity
EtherCAT has no built-in encryption or authentication. The protocol assumes a closed, trusted network — typically inside a machine cabinet. This is a design choice, not an oversight. Adding crypto would break the on-the-fly principle.
The implication: never put EtherCAT on a network that touches your IT infrastructure or the internet. Treat the EtherCAT segment as an internal bus, separated by the master from everything outside. If you need to expose data to higher layers, run OPC UA from the master upward.
For ICS security posture aligned with IEC 62443, see our IEC 62443 foundational requirements article.
Capturing EtherCAT in Wireshark
EtherCAT frames are visible in Wireshark — they use EtherType 0x88A4 and Wireshark has a dissector for them. Capture filter:
ether proto 0x88A4Display filters that are useful in the field:
ecat— All EtherCAT framesecat.cmd == 0x0A— LRD (Logical Read) datagramsecat.cmd == 0x0B— LWR (Logical Write) datagramsecat.cmd == 0x0C— LRW (Logical Read-Write), the most common cyclic commandecat.wkc == 0— Datagrams no slave processed at all, the clearest sign of a missing or hung device
For anything subtler than a zero, compare the returned Working Counter against the count your master expects for that datagram — the expected value is configuration-specific, so there is no universal filter for it.
One caveat: capturing EtherCAT requires a passive tap or a mirrored port on a junction. Plugging a regular Ethernet sniffer in the middle of an EtherCAT chain breaks the chain.
Should you use EtherCAT in a new design?
Honest answer: it depends on what you are building.
If the project is a self-contained machine with motion or fast I/O, and your PLC vendor’s EtherCAT support is solid (Beckhoff, Omron, Codesys-based systems), EtherCAT is an excellent choice. The performance is real, the install base is large enough that you can find parts and engineers, and the cabling savings are noticeable.
If the project is a process plant, a multi-vendor SCADA integration, or anything where IT/OT convergence matters, PROFINET or EtherNet/IP is usually a better fit. EtherCAT can be made to work, but you fight it more.
If the project is small or has loose timing requirements, do not pay the EtherCAT tax. Modbus TCP or even Modbus RTU will be cheaper and easier.
Frequently asked questions
What does EtherCAT stand for?
EtherCAT stands for Ethernet for Control Automation Technology. It was developed by Beckhoff Automation in 2003 and is now managed by the EtherCAT Technology Group (ETG). It is standardized under IEC 61158.
What is the maximum speed of EtherCAT?
EtherCAT runs at standard Ethernet speeds — 100 Mbit/s on most systems, with Gigabit EtherCAT available on newer hardware. The headline number people quote is cycle time: a few tens of microseconds in highly optimized configurations. In practice, 100 µs to 1 ms is typical for real machines.
Is EtherCAT open or proprietary?
EtherCAT is an open standard. The specification is freely available from the EtherCAT Technology Group. Any vendor can build EtherCAT devices. However, slave devices require an EtherCAT Slave Controller (ESC) chip, which is licensed from a small group of semiconductor vendors (Beckhoff, Hilscher, Microchip, Renesas, and others).
How many slaves can an EtherCAT network support?
The addressing architecture supports up to 65,535 devices, although practical networks are usually limited by cycle time requirements and physical design constraints. Around 1,000 slaves on one segment is common in large installations.
Does EtherCAT need special cables?
No. Standard Cat5e or better Ethernet cable works. The protocol uses the 100BASE-TX physical layer, so any compliant cable is fine. Industrial connectors (M12, M8) are common but not required.
Can EtherCAT run on standard Ethernet hardware?
The master side: yes. Any computer with a regular Ethernet port can be an EtherCAT master, given the right software stack. The slave side: no. Slaves need an EtherCAT Slave Controller chip to do the on-the-fly processing.
What is the difference between EtherCAT and EtherNet/IP?
EtherNet/IP is an application-layer protocol on top of standard TCP/IP and UDP/IP. It uses CIP objects and runs on regular Ethernet switches, with cycle times of 1 ms or slower. EtherCAT replaces the standard Ethernet behaviour with its own on-the-fly mechanism and reaches cycle times an order of magnitude shorter. Different design goals, different performance.
Is EtherCAT used in Siemens PLCs?
Rarely. Siemens promotes PROFINET as its primary industrial Ethernet protocol. Some Siemens hardware can act as an EtherCAT slave (motion drives, for example), but Siemens PLCs are not typically EtherCAT masters. For Siemens-centric designs, PROFINET is the natural fit.
What are the EtherCAT states?
EtherCAT slaves move through four main states: INIT (basic startup, no communication), PRE-OP (mailbox communication active, used for configuration), SAFE-OP (inputs read, outputs forced to safe state), and OP (full cyclic operation). An optional BOOT state is used for firmware updates. Slaves stuck below OP are the most common cause of EtherCAT commissioning issues.
Can EtherCAT be routed across networks?
The direct variant can’t — routers don’t forward EtherType 0x88A4, so it stays within one subnet. The UDP/IP variant can be routed at slightly higher overhead, and the standard intends it for less time-critical applications such as building automation.
What is an FMMU?
The fieldbus memory management unit inside each slave. It maps regions of the 4 GB logical address space to the slave’s own memory with bit-level granularity, which is what lets a single datagram serve many devices at once.
Does the physical order of EtherCAT devices matter?
Only during initialization. Once configured, the order is arbitrary — the process image is built from logical addresses, not positions. Change the order without updating the configuration, though, and the mapping points at the wrong hardware.
How does EtherCAT locate a cable fault?
Each slave recalculates the frame check sequence and, on finding an error, increments its own error counter instead of repairing the frame. Reading the counters along the line narrows the fault to the segment between the last clean node and the first one reporting errors.
What’s the difference between buffered and mailbox mode?
Buffered mode is for cyclic process data: either side may access at any time and the newest data wins, so nothing blocks. Mailbox mode is for acyclic messages, with handshaking so a message can’t be overwritten before it’s read.