EtherCAT is the protocol you reach for when 1ms 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 1ms to 10ms 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.
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.
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.
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 measures the propagation delay between the reference and every other slave by sending a special frame and timing the response. Then each slave’s local clock is adjusted by its measured delay. After this calibration, all slaves think it is the same instant.
EtherCAT Distributed Clocks typically achieve synchronization accuracy well below 1 µs and are 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. We compare both in our PROFINET vs EtherCAT guide when that piece is ready.
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 field-bus 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 Machine (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 in the line (forbidden), or industrial noise on cable | EtherCAT must run direct cable to cable. No switches. 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 != expected_value— Catch Working Counter mismatches
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: down to 31.25 µs in optimal 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 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. Cycle times are 1ms or slower. EtherCAT replaces the standard Ethernet behavior with its own on-the-fly mechanism. Cycle times are 31µs or faster. 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.