Which Term Sets EtherCAT’s Cycle Time?
Ada re-derives this chapter’s own numbers step by step, at full precision
ADA · CALCULATION AUDIT
Which Term Sets EtherCAT's Cycle Time?
The chapter models an EtherCAT cycle at 1,000 nodes and a 1,500-byte frame on 100 Mbps: propagation adds 25 us while frame transmission adds 120 us, totalling 145 us. The two terms behave completely differently, meeting only at about 4,800 nodes. This audit confirms the arithmetic and asks which term sets EtherCAT’s cycle time — finding it is the bytes, not the node count.
Companion to the chapter Industrial Communication Protocols — every number here comes from that chapter.
Ada: That 145-microsecond cycle time is a sum of two terms that behave completely differently, and knowing which one dominates tells an engineer which knob actually matters. Let me confirm the model’s arithmetic, then find the tipping point.
Working the two terms at 1,000 nodes and a 1,500-byte frame on 100 Mbps:
- Propagation:
1,000 x 25 ns = 25,000 ns = 25 us - Frame transmission:
(1,500 x 8) / 100 = 12,000 bits / 100 = 120 us(100 Mbps is 100 bits per microsecond, which is why the quotient lands directly in microseconds) - Total:
25 + 120 = 145 us, matching the chapter
Now the behaviour. Transmission is fixed by the frame — 120 us no matter how many nodes — while propagation grows 25 ns per node. Where do the two meet? Setting 25 ns x N = 120 us gives N = 120,000 / 25 = 4,800 nodes. So for any bus below roughly 4,800 nodes (and the calculator caps at 5,000, right at this crossover) it is the wire time to clock the frame out, not the per-node ASIC hop, that dominates the cycle.
That sharpens what “processing on the fly” really buys: each node is nearly free at 25 ns, so the whole cycle-time budget is spent shipping bytes. Notice too that 145 us sits above the chapter’s own < 100 us high-speed-motion tier — by 45 us — which places this configuration in the < 1 ms synchronized-drives band instead. To reach the top tier at 1,000 nodes you would shrink the frame, not the node count: transmission must drop to <= 75 us, i.e. a frame of 75 x 100 / 8 = 937.5 bytes or smaller. The design lesson is that when almost all of a fieldbus’s latency is transmission time, you win determinism by moving fewer bytes or moving them faster — adding or dropping nodes barely shifts the number.
Every number above is taken from the chapter’s own material and re-derived step by step.