EtherCAT for Distributed Joint Networks: Latency, Topology, and Practical Limits
EtherCAT gets recommended in robotics discussions almost reflexively — "use EtherCAT for real-time joint control" appears in enough forum posts and robot architecture documents that teams often adopt it without fully understanding what it actually requires. It does deliver genuinely impressive performance: cycle times of 250 µs to 1 ms across 12 joints are achievable in practice. But EtherCAT has topology constraints and integration requirements that aren't obvious until you're already commissioning hardware. This is a field guide for teams starting that process.
How EtherCAT Actually Works
EtherCAT uses a master-slave architecture over standard Ethernet physical layer (100BASE-TX or 1000BASE-T). The master sends a frame that passes through each slave device in sequence — each slave reads its input data and writes its output data into the frame on the fly, without fully receiving the frame first. This is the "processing on the fly" mechanism that gives EtherCAT its low latency: a 12-slave network with a 1500-byte frame can complete a full cycle in under 300 µs on standard Ethernet hardware.
Distributed Clocks (DC sync) is the mechanism that makes this useful for coordinated joint control. Each slave has an internal clock that can be synchronized to the master with sub-microsecond accuracy using the DC algorithm. With DC sync active, all slave devices trigger their control actions at the same physical instant — important for coordinated multi-joint torque application in a legged robot. Without DC sync, joint update times drift relative to each other, which introduces inter-joint timing jitter that appears as unpredictable force coupling in the kinematic chain.
Topology Constraints You Will Hit
EtherCAT mandates a daisy-chain or ring topology. Each slave has exactly one upstream and one downstream port in the main communication path. Branching is possible with junction slaves (slaves that have three or more ports), but each junction adds latency to the downstream branches. In practice, humanoid robot wiring follows joint chain topology fairly naturally — joints in a leg chain, arm chain, and trunk chain can each form a linear daisy-chain segment.
The constraint that surprises most teams is the cable length limit relative to cycle time. Standard Ethernet propagation delay is approximately 5 ns/m. For a 10-meter cable run between two joints, that's 50 ns of propagation delay one-way, 100 ns round-trip. In a 12-joint network with total cable runs of 8–15 meters, cable propagation adds 400–750 ns to the cycle budget. That's manageable for a 1 ms cycle time, but leaves little margin if you're targeting 250 µs.
Latency Budgeting for Joint Networks
A useful model for estimating EtherCAT cycle latency in a robot joint network:
| Latency Component | Typical Value | Notes |
|---|---|---|
| Master processing time | 20–50 µs | Depends on OS scheduler and NIC driver; PREEMPT_RT reduces this |
| Per-slave processing delay | 1–3 µs per slave | Hardware-dependent; FPGA-based slaves are at the low end |
| Cable propagation | ~0.1 µs per meter | Both directions; multiply total cable length by 0.2 µs/m |
| Jitter (non-RT OS) | 50–500 µs | Cycle jitter dominates total latency on non-RT kernels |
| Jitter (PREEMPT_RT) | 5–20 µs | Typical with tuned RT kernel and CPU isolation |
The master OS scheduler jitter is the single largest variable. On a standard Linux kernel, cycle jitter from scheduler interruptions easily exceeds 100 µs, rendering sub-millisecond cycle times unreliable in practice. PREEMPT_RT with CPU isolation and tickless operation brings jitter down to 5–20 µs, making 500 µs cycles reliably achievable. For a humanoid locomotion controller, 500 µs is fast enough for most impedance control implementations.
The EtherCAT master runs on your control computer's CPU. That CPU's OS scheduler matters as much as the bus protocol. Plan your software stack before you finalize your hardware.
Practical Integration Steps
From our work commissioning EtherCAT networks on evaluation hardware, here's the order of operations that saves time:
- Configure the master OS first: Set up PREEMPT_RT, isolate CPU cores for the EtherCAT master thread, configure tickless operation, and verify jitter with
cyclictestbefore connecting any slaves. Latency numbers above apply to this baseline. - Commission slaves one at a time: Bring each joint slave up individually, verify DC sync lock, confirm slave state machine transitions (INIT → PREOP → SAFEOP → OP) before adding the next slave.
- Validate DC sync across all joints: Use the EtherCAT master's DC sync diagnostics to confirm all slaves are synchronized to within ±1 µs. Joints that don't lock DC sync (often due to cable signal quality) will cause subtle timing issues that look like control instability.
- Profile cycle time before running control loops: Log actual cycle times at full slave count for at least 5 minutes. Look for worst-case outliers — a 1-in-10,000 cycle that runs 3x long will trip safety watchdogs unpredictably if you don't account for it.
EtherCAT vs. CAN FD: When Each Makes Sense
CAN FD remains relevant for humanoid joint networks in configurations where strict topology constraints are a problem. CAN FD supports bus topology naturally — multiple nodes on a shared cable — and doesn't require the per-slave FPGA or ASIC that EtherCAT slaves need. For a platform with fewer than 8 joints or a prototype where wiring simplicity matters, CAN FD at 5 Mbit/s gives you 1–2 ms cycle times with simpler master software.
EtherCAT's advantage becomes clear above 8 joints and when sub-millisecond coordination matters. For a full bipedal platform with 12–18 joints, EtherCAT with DC sync is the practical choice. The overhead of a proper RT kernel setup and FPGA-based slave hardware is justified by the latency and synchronization performance you get in return.
Our joint modules support both EtherCAT and CAN FD fieldbus, with the same SDK API and the same DC sync behavior on the EtherCAT path. If you're evaluating either bus for a specific platform architecture, reach out to discuss what our commissioning experience tells us about the tradeoffs at your joint count.
