Which Term Sets EtherCAT’s Cycle Time?
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.
See the relationship before changing it
The figure reads from left to right. The blue card is frame size. The middle card applies the page rule. The green card is ethercat cycle. Walk the arrows once: set the input, apply the rule, then read the result with its unit.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 1500 bytes.
- 2
Name the relationship. cycle = 25 us propagation + bytes x 8 / 100 bits/us
- 3
Substitute with units. 25 + 1500 x 8 / 100 = 145.00 us
- 4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.
Predict, then change frame size
Try Predict the direction of cycle = 25 us propagation + bytes x 8 / 100 bits/us. Test another frame size, then compare ethercat cycle.
Observe Below the crossover, frame bytes matter more than the fixed node-propagation term. Reset frame size to 1500 and compare ethercat cycle.
Explain Below the crossover, frame bytes matter more than the fixed node-propagation term.
Check yourself
What should you do before trusting a moved-control result?
What does this small model leave out?
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.
Only propagation and frame serialization enter the 145 us sum; stack delay, topology changes, clock error, jitter, retries, and competing traffic do not.
Work the audit first, then check the displayed derivation.
Every number above is taken from the chapter’s own material and re-derived step by step.