EtherCAT
Last reviewed
May 2, 2026
Sources
17 citations
Review status
Source-backed
Revision
v1 · 3,880 words
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation.
Suggest edit
CtrlK
Last reviewed
May 2, 2026
Sources
17 citations
Review status
Source-backed
Revision
v1 · 3,880 words
Add missing citations, update stale details, or suggest a clearer explanation.
| EtherCAT | |
|---|---|
| Full name | Ethernet for Control Automation Technology |
| Type | Industrial real-time Ethernet fieldbus |
| Developer | Beckhoff Automation |
| Introduced | April 2003 |
| Standardized | IEC 61158, IEC 61784, IEC 61800-7, ISO 15745 |
| EtherType | 0x88A4 |
| User organization | EtherCAT Technology Group (ETG) |
| ETG founded | November 2003 |
| ETG members | ~8,650 (2025) |
| Typical link rate | 100 Mbit/s (Fast Ethernet) |
| Higher rates | EtherCAT G (1 Gbit/s), EtherCAT 10G (10 Gbit/s, study) |
| Minimum cycle time | ~12.5 µs (demonstrated) |
| Synchronization jitter | < 100 ns (Distributed Clocks) |
EtherCAT (Ethernet for Control Automation Technology) is an industrial fieldbus protocol that runs over standard Ethernet hardware and delivers microsecond-class real-time performance for factory and motion control systems. It was developed by Beckhoff Automation and first presented at the Hannover Messe in April 2003. Beckhoff handed the specification to a vendor-neutral user organization, the EtherCAT Technology Group (ETG), in November of the same year. The protocol has since been published as part of IEC 61158, IEC 61784, IEC 61800-7, and ISO 15745.
What makes EtherCAT distinct among real-time Ethernet variants is the way it processes data. Instead of each PLC station receiving, copying, processing, and forwarding a complete frame, every node lets the frame run through its hardware while reading and writing the bytes addressed to it on the fly. The frame keeps moving downstream, gets turned around at the last node, and returns to the master with all of the slave responses already inserted. This eliminates most of the per-hop latency that limits conventional industrial networks, giving cycle times in the tens of microseconds and node-to-node synchronization below 100 ns.
EtherCAT is now the de facto real-time bus for high-end industrial automation, CNC machine tools, semiconductor production equipment, and industrial robots. In the last few years it has also become the dominant motion bus inside humanoid robots from Chinese vendors such as Unitree, AgiBot, Fourier Intelligence, and Lumos Robotics, which all need to coordinate dozens of joint actuators at kilohertz rates over a single cable. The AgiBot X1 and Lumos NIX are two recent examples that explicitly cite EtherCAT for joint-level motor control.
EtherCAT began as an internal project at Beckhoff Automation in Verl, Germany, in the early 2000s. Beckhoff, a privately held vendor of industrial PCs, PLCs, and I/O terminals, had hit the ceiling of its older Lightbus system and wanted a successor that could keep up with servo drives without throwing away the cost advantages of standard Ethernet silicon. The company's engineers settled on the unconventional idea of leaving the master-side hardware completely standard, just an off-the-shelf network interface controller, and concentrating all of the real-time intelligence into a small slave-side controller chip that could read and write the frame as it passed through. That choice is what eventually let EtherCAT undercut competing real-time Ethernet protocols on both performance and bill of materials.
The specification was first shown publicly at the Hannover Messe in April 2003. By November 2003, Beckhoff had handed control of the specification to the newly founded EtherCAT Technology Group, which acts as the user organization and promotes the technology in the same way that PROFIBUS International, ODVA, and EPSG promote competing fieldbuses. The ETG took over maintenance of the specification, certification, and conformance testing, and Beckhoff continues to license the technology free of charge to ETG members.
Formal standardization came quickly. EtherCAT was first published as IEC/PAS 62407 in 2005, and that publicly available specification was retired at the end of 2007 once EtherCAT had been adopted into IEC 61158 along with IEC 61784-2 (real-time Ethernet) and IEC 61800-7 (drive profiles). All three standards were approved unanimously in late 2007. EtherCAT also appears in ISO 15745, and the safety variant Safety over EtherCAT (FSoE) was added to IEC 61784-3-12 in 2010.
The core idea behind EtherCAT is that a frame leaves the master, traverses every slave on the network, and returns to the master in one round trip, with each slave injecting and extracting its own data while the frame is in motion. Every slave port runs an EtherCAT Slave Controller, an ASIC, FPGA bitstream, or microcontroller block that sits in the receive path and reads or writes the addressed bytes within a couple of clock cycles. The forwarding delay is dominated by hardware (cut-through forwarding, not store-and-forward) and adds on the order of one microsecond per node on a 100 Mbit/s link. There is no per-station copy of the frame, no per-station packet queue, and almost no software in the data path.
Frames are standard IEEE 802.3 Ethernet II frames with EtherType 0x88A4. Inside the frame are one or more EtherCAT datagrams, each carrying a command (read, write, or read-write), an address, a length, and a payload. A Working Counter at the end of each datagram is incremented by every slave that successfully services it, giving the master a built-in integrity check on return. A single frame can carry up to nearly 1500 bytes and address dozens of slaves, so most networks fit a complete process image into one frame and one round trip. Bandwidth utilization on the wire commonly exceeds 90% of the nominal 100 Mbit/s, far above what TCP/IP-based industrial protocols can achieve.
EtherCAT slaves do not carry an IP address. The master can address them in three ways. Auto-increment addressing uses a position counter that each slave decrements as the frame passes; the slave acts when the counter hits zero, which is mostly used during start-up and topology discovery. Configured station addressing assigns each slave a fixed 16-bit address independent of physical position, used for acyclic mailbox traffic. Logical addressing maps each slave's process data into a flat 4 GB logical address space through Fieldbus Memory Management Units (FMMUs) inside the slave controller. A single datagram with a logical address can hit many slaves at once, which is why a master can poll thousands of distributed I/O points in tens of microseconds.
Long-distance buses normally suffer from clock drift: each node has its own local oscillator, and small frequency differences add up over time. EtherCAT solves this with Distributed Clocks. The first DC-capable slave becomes the reference clock for the segment, and the master measures propagation delays in both directions (forward and reverse paths can differ because of cable lengths and per-node delays). It then writes a corrected offset into every slave's local DC register and keeps correcting for drift on every cycle. The resulting jitter between any two slaves typically stays below 100 ns, enough to drive coordinated motion control for tens of axes without a separate sync signal.
The key piece of silicon in any EtherCAT system is the EtherCAT Slave Controller (ESC). Beckhoff sells its own family (the ET1100, ET1200, and ET2000 ASICs plus several IP cores), but the ESC is now integrated into general-purpose microcontrollers from Texas Instruments (Sitara AM335x and AM6x families), Renesas, Infineon, ST, and Microchip. The ESC handles cut-through forwarding, FMMU translation, sync managers, distributed clock registers, and the EEPROM-based Slave Information Interface (SII). The application processor behind it only sees a flat block of process data, which means EtherCAT slaves can be built around almost any microcontroller without losing real-time guarantees.
Beckhoff's target was cycle times below 100 µs, and most modern installations sit comfortably below that. In 2012 the ETG demonstrated a complete EtherCAT PLC running at a 12.5 µs cycle time with 15 slave devices and a software master on a standard industrial PC, still cited as the reference for what the protocol can sustain. Typical machine builds run cycles between 250 µs and 1 ms, while servo drives in motion control often run at 4 kHz to 10 kHz (250 µs and 100 µs respectively). With Distributed Clocks active, jitter across nodes stays below 100 ns even on long line topologies. Because the return path of the frame uses the same physical pair as the forward path, EtherCAT effectively gets close to 200 Mbit/s of usable bandwidth on a 100 Mbit/s link, and a single frame can poll more than a thousand digital I/O points or several hundred drive records in around 30 µs of wire time.
Logically, an EtherCAT network behaves as a single ring: the frame leaves the master through port 0 of the first slave, travels downstream through each ESC, gets turned around in the last slave's unused port, and returns to the master on the same line. Physically the cabling can take almost any shape. The most common is a daisy chain (line topology), but the same protocol supports star, tree, and ring layouts through junction slaves with extra ports. Up to 65,535 devices are addressable in a single segment, with copper runs up to 100 m between nodes and fiber runs of several kilometers.
For robotics the line topology is by far the most common: cables run from the controller to the first joint actuator, daisy chained through the second joint, and so on out to the end-effector. EtherCAT P combines that data line with a 24 V DC power supply on the same four-wire cable, which simplifies the harness inside a robot arm or humanoid limb.
The core EtherCAT specification only defines the data link layer. Higher-level device behavior is defined through a family of mailbox protocols, usually called by their four-letter abbreviations:
| Profile | Full name | Purpose |
|---|---|---|
| CoE | CANopen over EtherCAT | Carries the CANopen object dictionary, SDO, and PDO model. Most servo drives use the CiA 402 motion profile through CoE, including cyclic synchronous position, velocity, and torque modes. |
| SoE | Servo profile over EtherCAT | Implements the SERCOS drive profile (IEC 61800-7-204) on top of EtherCAT. |
| EoE | Ethernet over EtherCAT | Tunnels arbitrary Ethernet frames (TCP/IP, web servers, remote desktop) through the segment without disturbing real-time traffic. |
| FoE | File over EtherCAT | A trivial file transfer protocol used for firmware downloads and diagnostic uploads. Modeled on TFTP. |
| AoE | ADS over EtherCAT | Beckhoff's Automation Device Specification routing protocol, used for remote diagnostics inside TwinCAT. |
| VoE | Vendor-specific over EtherCAT | Catch-all for vendor mailbox protocols outside the standard set. |
| FSoE | Safety over EtherCAT | Black-channel safety profile certified to SIL 3 (IEC 61508) and standardized in IEC 61784-3-12. Used for safe stop, safe direction, and emergency-stop signals on the same wire as standard process data. |
For industrial robotics and motion control, CoE with the CiA 402 drive profile is the dominant choice. It defines the Controlword and Statusword bits, all of the operating modes, and a uniform set of cyclic position, velocity, and torque variables that any conforming drive exposes. This is one reason drives from very different manufacturers can share the same EtherCAT segment and the same master without rewriting motion code.
The ETG owns the EtherCAT specification, runs conformance testing, manages the brand, and represents EtherCAT in standards bodies. It was founded in November 2003 with 33 founding members and is now the largest industrial Ethernet user organization in the world. ETG numbers published in early 2025 put membership at roughly 8,650 companies across more than 60 countries, with around 400 new members joining each year over the last decade. As of the same publication, 43% of members were from Asia, 42% from Europe, 14% from the Americas, and 1% from the rest of the world, which reflects how strongly EtherCAT has been adopted in East Asian automation and robotics. The organization runs technical working groups for specific verticals (drives, semiconductors, robotics, industrial PCs), plus regional offices in Germany, Japan, China, Korea, and the United States. Beckhoff supplies the technical chair and the administrative office in Nuremberg, but the ETG itself is vendor-neutral; any company can join, license the technology free of charge, and ship conformant products.
EtherCAT is one of several industrial Ethernet protocols competing for the same slot in factory networks. The four most common alternatives are PROFINET, EtherNet/IP, POWERLINK, and SERCOS III.
| Protocol | Backed by | Approach | Typical cycle time | Notes |
|---|---|---|---|---|
| EtherCAT | ETG (Beckhoff) | Processing on the fly, single ring, dedicated slave silicon | 12.5 µs to 1 ms | Standard Ethernet on master side; ESC required on slaves. |
| PROFINET IRT | PI / Siemens | Time-slot scheduling on every switch | < 1 ms | Requires special PROFINET-IRT switches. |
| EtherNet/IP | ODVA (Rockwell) | TCP/IP plus CIP application layer; TSN for hard real time | 1 ms or above | Most common in North American factories. |
| POWERLINK | EPSG (B&R) | Polling master with isochronous slot scheduling | 200 µs to 1 ms | Open-source openPOWERLINK stack. |
| SERCOS III | SERCOS International | Telegram aggregation similar to EtherCAT | 31.25 µs to 1 ms | Strong in European machine tools. |
The choice often comes down to which automation vendor is dominant in a given market: PROFINET in Siemens-heavy plants, EtherNet/IP in Rockwell territory, EtherCAT in Beckhoff and Asian shops, POWERLINK in B&R installations, SERCOS III in older machine-tool builds. EtherCAT consistently wins on raw cycle time and bandwidth efficiency, which is why motion-heavy applications (CNC, packaging, semiconductor lithography, humanoid robotics) tend to choose it.
The EtherCAT master sits on the controller side and is what most engineers actually program. Commercial and open-source options exist, all using the same wire protocol.
| Implementation | Vendor / project | License | Platform | Notes |
|---|---|---|---|---|
| TwinCAT 3 | Beckhoff | Commercial | Windows, real-time kernel | Reference EtherCAT master with full IDE, PLC, and motion. |
| CODESYS Control | CODESYS Group | Commercial | Windows, Linux, embedded | EtherCAT master add-on, used by many third-party controllers. |
| EC-Master | acontis technologies | Commercial | Linux, Windows, VxWorks, QNX, RTX64, INtime, FreeRTOS | Portable C/C++ stack, Python and Rust bindings. |
| IgH EtherCAT Master (EtherLab) | IgH Essen | GPLv2 | Linux kernel module | Kernel-side master with native drivers for several Ethernet chips. Common in academic robotics labs. |
| SOEM | OpenEtherCATsociety | BSD-style | Linux, Windows, embedded RTOS | User-space C library focused on simplicity. Used in ROS ROS-Industrial drivers and by many Chinese humanoid vendors. |
| SOES | OpenEtherCATsociety | BSD-style | Embedded | Slave-side reference stack matched to SOEM. |
| KPA EtherCAT Master | Koenig-PA | Commercial | Many | Used in some semiconductor equipment. |
Most humanoid makers that publish their stacks pick either SOEM (small footprint, permissive license) or IgH EtherCAT Master (kernel-level real-time on Linux PREEMPT_RT), both usually paired with ROS or ROS 2 for higher-level perception and planning.
The original EtherCAT spec is tied to 100 Mbit/s Fast Ethernet, which is enough for almost all motion control but starts to feel tight when machines integrate machine vision, condition monitoring, and large process images on the same wire. Beckhoff announced EtherCAT G at SPS 2018 as a gigabit extension that uses the same wire format but runs on 1 Gbit/s links, with a proof-of-concept EtherCAT G10 (also called EtherCAT 10G) running at 10 Gbit/s for very large process images. EtherCAT G is backward compatible: a 100 Mbit/s segment can hang off a 1 Gbit/s master through a special branch controller (Beckhoff's CU14xx series) which buffers traffic and lets multiple slow segments operate in parallel inside one fast segment.
EtherCAT P is a separate Beckhoff extension introduced in 2015 that combines two electrically isolated 24 V/3 A power supplies (one for sensor logic, one for actuator power) onto the same four-wire Ethernet cable. The connector uses an IEC 61076-2-114 P-coded M8 layout to keep users from plugging it into a standard Ethernet device by mistake. EtherCAT P is widely used in robotics because it removes the need for separate power and data harnesses inside an arm or limb.
EtherCAT is now standard across much of European and Asian factory automation, especially in machine tools, packaging machinery, semiconductor production, and high-speed printing. Many CNC controls, including the European builds of Heidenhain and Fagor, use EtherCAT as their primary motion bus, and semiconductor equipment from ASML and other lithography vendors uses it for stage coordination where sub-microsecond synchronization is essential.
In the industrial robot sector the picture is mixed. Long-running brands tend to keep proprietary internal buses and expose EtherCAT only as an optional cell-controller interface. KUKA controllers (KR C4, KR C5) support EtherCAT through the KUKA.EtherCAT package for external I/O and add-on axes; the internal joint bus stays proprietary. ABB IRC5 and OmniCore controllers offer EtherCAT as an option for external devices. Yaskawa Sigma-7 and Sigma-X servo drives are widely used as EtherCAT slaves in third-party machines, and Yaskawa's MOTOMAN robot controllers support EtherCAT as a peripheral bus. FANUC sticks with FANUC I/O Link and EtherNet/IP and offers EtherCAT only as a less common option. Universal Robots cobots use Modbus/TCP and serial RS-485 internally, but the tool flange and cell-side interfaces reach EtherCAT through third-party gateways.
Humanoid robots are an increasingly important market for EtherCAT. A typical adult-sized humanoid has 25 to 50 actuated joints, each needing position, velocity, current, and temperature feedback at kilohertz rates. Coordinating that many drives over CAN, the older fieldbus of choice, runs into bandwidth and latency limits. EtherCAT's high bandwidth, microsecond cycle times, single-cable daisy chaining, and CoE/CiA 402 drive profile make it the pragmatic choice for new designs, especially in China, where most recent humanoid startups ship EtherCAT-based motion stacks.
| Humanoid robot | Maker | Country | EtherCAT role |
|---|---|---|---|
| AgiBot X1 | AgiBot | China | Joint-level motion bus on a dual-bus EtherCAT plus FDCAN architecture. |
| Lumos NIX | Lumos Robotics | China | Primary motor control bus for all 30+ joints. |
| Unitree H1 | Unitree | China | EtherCAT for joint motors with PREEMPT_RT Linux master. |
| Unitree G1 | Unitree | China | EtherCAT-based joint control, exposed through SDK. |
| Fourier GR-1 / GR-2 | Fourier Intelligence | China | EtherCAT-based motor control, with ROS 2 stack on top. |
| Walker S | UBTech | China | EtherCAT joint bus. |
| HRP-5P | AIST | Japan | EtherCAT joint bus over IgH master. |
| TIAGo | PAL Robotics | Spain | EtherCAT for arm and torso motors. |
| NimbRo OP2X | University of Bonn | Germany | EtherCAT used on the dynamixel-replacement actuators. |
The newer all-electric Atlas from Boston Dynamics has not been documented as EtherCAT-based at the joint level, and earlier hydraulic Atlas generations used a Boston Dynamics proprietary servo bus. Tesla Optimus and Figure have not publicly disclosed their internal motor bus, though interviews suggest both use EtherCAT or a similar high-rate Ethernet variant. For most open and academic humanoid stacks, EtherCAT plus SOEM plus ROS 2 has become the unofficial reference architecture.
Academic groups have pushed the design further. A 2024 MDPI paper, "Real-Time EtherCAT-Based Control Architecture for Electro-Hydraulic Humanoid," describes embedding an EtherCAT slave controller (LAN9252) inside each electro-hydraulic actuator on a humanoid leg so the central controller can close current loops over EtherCAT in under 200 µs.
EtherCAT has no built-in cryptographic authentication or encryption on the wire. The protocol was designed for closed cell networks where physical access is controlled, on the assumption that cell-level Ethernet would not be reachable from the wider plant or the internet. That assumption has come under scrutiny as factory networks flatten into shared IT/OT layouts. The ETG security white paper recommends keeping EtherCAT segments behind firewalls, VPN gateways, and time-sensitive switches whenever they cross outside the cell. Work on an optional message-authentication profile is ongoing, but most installations rely on segmentation.
Time-Sensitive Networking (TSN), the IEEE 802.1 family that brings deterministic behavior to switched Layer 2 networks, is sometimes presented as a competitor to EtherCAT, but the two solve different problems. TSN is a switch-side technology for sharing a backbone between multiple traffic classes with bounded latency. EtherCAT achieves determinism without switches by using cut-through processing in the slaves. In real plants the two are typically combined: a TSN backbone connects machines or cells, and each cell runs an EtherCAT segment internally for the motors. The ETG-defined EtherCAT-over-TSN bridge lets an EtherCAT segment run as a TSN traffic class on the backbone.
A recurring pattern in modern humanoid stacks is the layering of EtherCAT under ROS 2 with PREEMPT_RT Linux as the operating system. The lowest layer is the EtherCAT segment running at 1 to 8 kHz and talking to all joint drives over CoE/CiA 402. Above it is a ros2_control hardware interface that exposes joint state and command topics, then the planner, perception, and AI policy code, often a learned policy from imitation or reinforcement learning. The protocol does not solve any of the AI side of the problem, but it keeps the inner motor loop deterministic enough that the policy can be trained against a stable, low-latency action interface. That matters for humanoid AI specifically. Most learned policies treat the robot's actuators as a continuous control surface, and a jittery motor bus injects noise into the action channel that degrades both real-world performance and simulation-to-real transfer. With EtherCAT's sub-microsecond synchronization, the action commanded at time t is applied to every joint with a known, small, repeatable delay across all joints.