EtherCAT for Robot Joint Networks: How the Cycle-Time Budget Actually Works

EtherCAT for robot joint networks gets pitched with one line: it processes frames "on the fly," so it is fast enough for real-time servo control. That is true, but it hides the actual question a builder needs answered before wiring six or twelve joint drives into a chain: how many axes actually fit inside your control cycle, and at what point does adding one more joint blow your timing budget? Answering that takes an actual calculation, not a marketing bullet point.

Why EtherCAT processes frames differently than CAN

On a classic CAN bus (see our CAN bus joint network article for the bit-timing side of that protocol), every node listens to a shared electrical bus and arbitrates for access one message at a time. EtherCAT works differently. The master sends a single Ethernet frame that travels through the whole chain of slave devices in a physical loop. Each slave's EtherCAT Slave Controller (ESC) reads the data addressed to it and writes its own response into the same frame as it passes through, without stopping to fully receive, decode, and re-transmit like a normal Ethernet switch would. This is the "processing on the fly" part, and it is the reason EtherCAT cycle times can get into the tens of microseconds even with a dozen nodes on the chain.

But "on the fly" does not mean zero time. Every slave still adds a small, real delay as the frame passes through it, and the frame itself still takes a fixed amount of time to transmit at the physical line rate. Your cycle time is the sum of those pieces, not a fixed number a datasheet hands you.

The four pieces of an EtherCAT cycle-time budget

For a robot arm or mobile base with N joint drives daisy-chained on one EtherCAT segment, the cycle time has four components:

1. Frame transmission time. At the standard 100 Mbit/s EtherCAT physical layer, transmission time is frame length in bits divided by 100,000,000 bits/s.
2. Per-slave forwarding delay. Each ESC introduces a small delay as it reads and writes its process data segment before forwarding the frame to the next node. This is on the order of a few hundred nanoseconds per slave, and it applies twice per slave on a standard EtherCAT ring topology (once on the way out to the last node, once on the way back).
3. Cable propagation delay. Signal propagation through Ethernet cable is roughly 5 nanoseconds per meter. For joint-to-joint cable runs of a meter or less inside a robot arm, this term is small but not always negligible once you sum it across many hops.
4. Master and application processing time. The time your master's real-time task needs to prepare the outgoing frame and process the incoming one before the next cycle can start. This is set by your control software, not the fieldbus, and is easy to forget when people only quote the "wire time."

Worked example: six joints on one EtherCAT segment

Take a 6-DOF arm with one drive per joint, each drive contributing 8 bytes of process data in each direction (typical for target position, target torque, actual position, and status word packed into a compact PDO mapping). We want to know if this fits inside a 1 kHz (1000 microsecond) control cycle.

Step 1: frame length and transmission time

The Ethernet frame carries an EtherCAT header, one datagram header plus payload per slave, a working counter, and the standard Ethernet frame overhead (preamble, addresses, type field, frame check sequence, inter-frame gap). Adding up 6 slaves at roughly 8 bytes payload plus about 12 bytes of per-slave datagram overhead, plus around 60 bytes of fixed frame overhead, gives a total frame length of approximately 60 + 6 x (12 + 8) = 180 bytes, or 1440 bits.

At 100 Mbit/s, transmission time is:

t_frame = 1440 bits / 100,000,000 bits/s = 14.4 microseconds

Step 2: forwarding delay

Assume a representative forwarding delay of 500 nanoseconds per slave, a typical order of magnitude for real ESC hardware. With 6 slaves and the frame passing through each one twice (out and back on the ring), that is:

t_forward = 6 slaves x 2 passes x 500 ns = 6 microseconds

Step 3: cable propagation

With six 0.5-meter cable segments between joints, round trip distance is 6 x 0.5 m x 2 = 6 meters at roughly 5 ns/m:

t_cable = 6 m x 5 ns/m = 30 nanoseconds

This term is small enough to fold into your margin rather than track precisely, which is exactly why it is safe to ignore for short in-arm cable runs but not for a robot with joints spread across several meters of cabling, like a large gantry or a multi-arm cell.

Step 4: total wire time and the real budget

t_wire = t_frame + t_forward + t_cable = 14.4 + 6 + 0.03 ≈ 20.4 microseconds

Against a 1000 microsecond (1 kHz) cycle, 20.4 microseconds of wire time leaves roughly 98% of the cycle for the master's application logic: reading sensor data, running your control loop (see our real-time control loop article for how to budget the rest of that time against jitter), and preparing the next frame. This is the actual reason EtherCAT scales well: the wire time for a realistic joint count is a tiny fraction of a typical servo control cycle, not because the protocol is magic, but because the arithmetic genuinely works out that way at 100 Mbit/s.

Where the budget actually breaks

The wire-time math scales roughly linearly with slave count, so doubling to 12 joints roughly doubles t_forward to 12 microseconds and modestly increases t_frame, keeping total wire time comfortably under 1000 microseconds. The budget does not break from axis count alone at 1 kHz; it breaks from three other places builders hit in practice:

• Faster cycle rates. Push to a 4 kHz cycle (250 microseconds) for a high-bandwidth force-control application, and a 20 microsecond wire time is suddenly 8% of the budget instead of 2%, leaving much less room for jitter and master processing.
• Larger payloads per slave. A drive reporting full motor current waveforms or multi-turn absolute position data instead of a compact 8-byte PDO can push frame length up significantly, since frame transmission time scales directly with total payload across all slaves.
• Master jitter, not fieldbus jitter. A non-real-time operating system task scheduler missing its deadline by hundreds of microseconds will blow a 1 kHz budget long before the EtherCAT wire time does. This is a software problem, not a fieldbus problem, and it is the most common cause of a robot arm that "should" hit 1 kHz on paper but does not in practice.

Practical takeaway

Before committing to an axis count and cycle rate for an EtherCAT robot joint network, run the same four-step calculation with your actual PDO sizes, slave count, and target cycle time. If wire time comfortably clears 10-20% of your cycle budget, you have margin for real-world jitter and master processing. If it starts approaching 50% or more, either drop the cycle rate, trim PDO payload per slave, or split the chain across multiple EtherCAT masters. The protocol's speed comes from real, calculable numbers, and treating it that way during design saves you from discovering the limit on a robot that is already wired.