EtherCAT Cycle Time Calculator
This free EtherCAT cycle time calculator estimates whether your network and application fit inside a target cycle time, before you commit to it in the configurator. Enter your total cyclic process data, slave count and delay, cable length, application execution time, and jitter reserve; it builds a first-pass timing budget from the frame time on the wire plus propagation, application, and reserve, then compares the total against your target cycle. It's for controls and automation engineers sizing a new EtherCAT segment, checking whether added slaves or larger PDOs break an existing cycle, or sanity-checking a vendor's cycle-time claim. No account, no spreadsheet — the formula and assumptions are shown below so you can reproduce the result by hand.
Estimate the communication and application timing budget for a target EtherCAT cycle.
First-pass model: frame time ≈ 5 µs overhead + 0.08 µs per process-data byte at 100 Mbit/s, plus your entered slave delay, cable propagation at about 0.005 µs/m, application execution, and jitter reserve. Actual masters, frame layouts, slave types, OS/runtime behavior, and minimum device cycle times can change the result.
The formula
EtherCAT moves all cyclic process data in a frame that passes through every slave in one trip, so the wire time scales with total bytes, not with the number of frames a master has to build. The budget this calculator builds is:
Communication time T_comm = T_frame + T_slaves + T_cable T_frame = 5 µs + (0.08 µs/byte × D) T_slaves = N × t_slave T_cable = 0.005 µs/m × L Total cycle budget T_budget = T_comm + T_app + T_jitter Fit against your target Margin = T_target − T_budget Utilization = T_budget ÷ T_target × 100%
The cycle fits on paper when T_budget < T_target — with real margin left over, not just a positive number (see Common Mistakes).
| Variable | Meaning | Where it comes from |
|---|---|---|
| D | Total cyclic process data per cycle, in bytes — every slave's inputs and outputs combined (RxPDO + TxPDO) | Your PDO mapping; the EtherCAT PDO Size calculator on this site totals it for you |
| N | Number of slaves on the segment | Your network design |
| t_slave | Forwarding/processing delay per slave, in µs | Slave documentation; ~1 µs is a common planning value (and the live form's default) |
| L | Total cable length on the segment, in metres | Your installation layout |
| T_app | Application execution time — how long the master task needs to run the control program each cycle | Measured on your master/IPC, e.g. from task monitoring |
| T_jitter | Jitter reserve — allowance for timing variation in the master, runtime, and OS | Your judgement; see the glossary |
| T_target | The cycle time you are trying to achieve | Your application requirement |
Why the constants: at 100 Mbit/s, one byte takes 0.08 µs on the wire, so frame time is a fixed 5 µs of overhead plus 0.08 µs for every process-data byte. A signal propagates along copper cable at roughly 0.005 µs per metre. Both are small numbers — which is exactly why, at typical I/O sizes, the application execution time and jitter reserve usually decide whether a cycle fits, not the wire.
What each input means
| Input | Unit | Typical value (live form default) | What breaks if you get it wrong |
|---|---|---|---|
| Total cyclic process data (bytes) | bytes per cycle | 100–1,500 for a single segment; a few hundred is common for a machine I/O network (default 1,000) | Undercounting bytes (e.g. outputs only) understates frame time and gives a budget that passes on paper and misses on the machine |
| EtherCAT slaves | count | 5–50 on a machine segment (default 25) | Only used with the per-slave delay — a wrong count scales the slave-delay total up or down |
| Delay per slave | µs | ~1 µs per slave as a planning value (default 1) | Leaving it at zero makes the budget optimistic; real slaves each add forwarding delay |
| Total cable length (m) | m | 10–100 m across a machine (default 80) | A small term, but on long chains it is not zero; ignoring it understates propagation |
| Application execution | µs | Tens to hundreds of µs, depending on program size and master hardware (default 250) | The most common bad input. Guessing instead of measuring hides the largest term in the budget |
| Master jitter reserve | µs | 10–50 µs on a real-time runtime; more on a non-real-time OS (default 100) | Zero reserve = a budget with no allowance for the timing variation every real master has |
| Target cycle | µs (select) | 250 µs–1 ms (motion), 1–10 ms (general I/O) (default 1,000 µs = 1 ms; options 250 / 500 / 1,000 / 2,000 / 4,000 / 10,000) | Comparing against a wish instead of a requirement; the target comes from the process, not the network |
Worked example
Scenario: a packaging machine retrofit. Eight EtherCAT slaves (drives and I/O) on one segment, target cycle time 1 ms.
Inputs:
- Process data: 8 slaves × 32 bytes each = 256 bytes per cycle
- Slave delay: 1.0 µs per slave
- Cable: 40 m total
- Application execution: 120 µs (measured task runtime on the IPC)
- Jitter reserve: 50 µs
- Target cycle: 1,000 µs (1 ms)
Step by step:
- Frame time = 5 + (0.08 × 256) = 5 + 20.48 = 25.48 µs
- Slave delay total = 8 × 1.0 = 8.00 µs
- Cable propagation = 40 × 0.005 = 0.20 µs
- Communication time = 25.48 + 8.00 + 0.20 = 33.68 µs
- Total budget = 33.68 + 120 + 50 = 203.68 µs ≈ 204 µs
- Fit: 204 µs < 1,000 µs target → the cycle fits, with 796 µs of margin (utilization ≈ 20.4%)
What the example shows: communication is only 34 µs of the 204 µs budget. Doubling the process data to 512 bytes raises frame time to 45.96 µs and the total budget to ≈ 224 µs — still comfortably inside 1 ms. On a network this size, the wire is not your problem; application execution and jitter are. The same budget against a 250 µs target, however, leaves only ≈ 46 µs of margin — at that point the jitter reserve deserves a second look before you commit.
What the result tells you
- Estimated frame time — the wire time for one trip of the frame: 5 µs overhead + 0.08 µs per process-data byte. It grows only with total bytes.
- Communication + propagation — frame time plus every slave's forwarding delay and the cable propagation. If this number alone is close to your target, the network design (bytes, slaves, topology) is the constraint.
- Total entered timing budget — communication + propagation + your application execution + your jitter reserve. This is the number the verdict judges, and the verdict reports it as "Estimated budget utilization: X%" of your target.
- Remaining cycle margin — target minus total budget. A small positive margin is not a pass in practice: the calculator itself flags utilization at or above 85% as feasible "but has little reserve," and a negative margin means the budget exceeds the target. Masters, runtimes, and slave behaviour vary from this first-pass model, so treat a thin margin as a warning, not a success.
- Which term dominates — in most I/O-sized networks it's application execution. If the budget fails, shrinking PDOs rarely rescues it; a faster task, a split cycle (fast loop for motion, slower loop for I/O), or a longer target cycle does.
Common mistakes
- Counting the frame twice. EtherCAT slaves read and write their data as the frame passes through — inputs and outputs travel in the same trip. Don't add a separate "send" and "receive" frame time; enter total process data once.
- Entering only the outputs (or only the inputs). Frame time keys off total cyclic bytes. If your 256 bytes is really 256 each way, the real frame time is roughly double the one you calculated. Total your RxPDO + TxPDO first — the EtherCAT PDO Size calculator on this site does exactly that.
- Treating the estimate as a guarantee. This is a first-pass budget. It does not model frame splitting when process data exceeds a single Ethernet frame (~1,500 bytes), master stack behaviour, frame layout, or a slave's minimum supported cycle time — any of which can move the real number. Large networks should treat the result as optimistic.
- Setting the jitter reserve to zero. A budget that only fits with zero reserve fits only on a perfect master. On non-real-time operating systems, jitter alone can eat tens of microseconds; measured cycles will miss even though the arithmetic "passed."
- Optimising the wire when the application is the problem. Cutting 100 bytes of PDO saves 8 µs. If your task executes in 400 µs against a 500 µs target, bytes are not the fix — task runtime is.
FAQ
How do I calculate EtherCAT cycle time?
Add up everything that has to happen inside one cycle: frame time on the wire (5 µs overhead + 0.08 µs per process-data byte at 100 Mbit/s), the forwarding delay of every slave, cable propagation (about 0.005 µs per metre), the time your application needs to execute, and a reserve for jitter. If that total is below your target cycle time — with margin to spare — the cycle is feasible as a first-pass estimate.
What is a typical EtherCAT cycle time?
Motion applications commonly run at 250 µs to 1 ms; general machine I/O often runs at 1–10 ms. Faster is not automatically better: at small process-data sizes the wire time is a minor term, so the practical floor is usually set by your application execution time and jitter, not by the network.
How much process data fits in one EtherCAT cycle?
One Ethernet frame carries up to roughly 1,500 bytes of process data. Beyond that, the master sends multiple frames per cycle, which adds overhead this first-pass model doesn't price in — it charges 0.08 µs per byte either way. For networks well above 1,500 bytes, treat the estimate as a floor, not an exact figure.
Does this calculator guarantee my network will run at the target cycle time?
No. It estimates a first-pass timing budget from process-data size, slave and cable propagation, application execution, and jitter reserve. Real performance depends on the EtherCAT master, operating system and runtime behaviour, frame layout, slave characteristics, and device-specific minimum cycle times. Verify against your master vendor's tooling and measured task data before final sign-off.
What is the difference between communication time and cycle time?
Communication time is only the network's share: frame time plus slave and cable delays. Cycle time is the whole repeating period, which also has to contain your application execution and jitter. A network can have very fast communication and still miss its cycle because the control task overruns.
My measured cycle is worse than the estimate. Why?
The usual suspects sit outside a first-pass model: frame layout and how the master packs datagrams, runtime and OS jitter larger than your reserve, slaves with minimum cycle times above your target, and Distributed Clock settings interacting with the task. The estimate tells you the floor; measurement tells you what your specific master and slaves add to it.
Our guide to EtherCAT cycle time, jitter and Distributed Clocks works through these effects in detail.
Related tools and reading
- EtherCAT PDO Size Calculator — total your cyclic RxPDO + TxPDO bytes first; that total is this calculator's main input.
- EtherCAT Distributed Clock Checker — once the cycle fits, check Sync0 and shift against your slaves' minimum cycle.
- Guide: EtherCAT Cycle Time, Jitter and Distributed Clocks — A Practical Guide — the long-form companion to this calculator.
- All other calculators: CODESYS Task & Jitter · Modbus RTU Timing · 24VDC Power Supply · Enclosure Cooling · Historian Storage
- Calculator hub — all eight free calculators on one page.
Take this budget into a worksheet.
The free Controls Toolkit includes the EtherCAT timing-budget workbook — slave and PDO inventory, cycle utilisation, and remaining timing margin, with the formulas built in — plus an Industrial PC sizing workbook. Free by email signup.