EtherCAT · CODESYS · Real-time control

EtherCAT Cycle Time, Jitter and Distributed Clocks: A Practical Guide

Published September 30, 2026 · Approximately 10 minutes

When an EtherCAT system has timing problems, engineers often ask the wrong first question:

How fast is EtherCAT?

The better question is:

Can my complete control system execute the application, exchange the required process data, synchronize the devices, and absorb worst-case jitter inside the target cycle?

EtherCAT itself can operate at very short cycle times. But a reliable machine cycle depends on more than the protocol. The controller runtime, operating system, CPU scheduling, network interface, task structure, PDO size, slave characteristics, and application code all contribute to the result.

This guide explains how to build a practical timing budget and what to measure during commissioning.

1. Start with the required machine cycle

Do not begin with the fastest number the network can achieve. Begin with the process.

Ask what the machine actually requires:

• Does a temperature or utility process need 10 ms updates?
• Does coordinated motion need 1 ms?
• Does a high-speed motion or semiconductor subsystem need hundreds of microseconds?

The answer determines how much engineering effort is justified.

As an illustrative planning range, general automation often operates in multi-millisecond cycles, advanced coordinated automation may target roughly 500 us to 1 ms, and the most timing-sensitive CNC or semiconductor applications can push into the low hundreds of microseconds. These are not protocol limits or guarantees. They are design classes that help frame the real-time problem.

The faster the target cycle, the less tolerance the system has for operating-system jitter, long application paths, background work, and poorly behaved drivers.

2. Understand what EtherCAT does differently

Conventional switched Ethernet typically receives an entire frame, examines it, and then forwards it. EtherCAT uses a different mechanism: slave controllers read and write the data intended for them while the frame is passing through.

The EtherCAT Technology Group describes this as processing on the fly. The design makes efficient use of the available 100 Mbit/s full-duplex bandwidth and reduces the per-device forwarding overhead associated with conventional store-and-forward switching.

That is why EtherCAT scales well for cyclic I/O and motion networks.

But the wire time is only one piece of the machine cycle.

3. Build a timing budget

For a first-pass analysis, break the target cycle into components.

A useful simplified model is:

Target cycle >= application execution + EtherCAT communication + platform overhead + jitter reserve + engineering margin

For example, consider a 1 ms target:

The design has positive margin, so 1 ms may be feasible. But this is still a planning estimate. Commissioning measurements must confirm it.

Free EtherCAT timing tool

Use the EtherCAT Cycle Time Planner to create a first-pass budget from slave count, process-data size, cable length, application time, jitter allowance, and target cycle:

https://controlscalculator.com/#ethercat-cycle-card

4. Do not confuse task interval with execution time

In a CODESYS application, a cyclic task has a configured interval. If the interval is 1 ms, the runtime attempts to release that task every 1,000 us.

The task does not normally execute for the entire 1,000 us. Its logic might take 200 us on average and 500 us in a worst observed case.

That creates two different questions:

1. 1. Does the application finish before the next deadline?
2. 2. Does the task start when it is supposed to start?

The first is about execution time. The second is about jitter and latency.

A controller can have low average CPU utilization and still have bad real-time behavior if the task occasionally starts late.

5. Jitter matters because deadlines repeat

CODESYS defines periodic jitter as the deviation between the actual task period and the configured interval.

If a 1 ms task sometimes arrives at 1,040 us and sometimes at 960 us, the timing is varying even if the long-term average is 1 ms.

CODESYS exposes useful values in Task Configuration monitoring, including:

• last cycle time
• average cycle time
• maximum cycle time
• minimum cycle time
• current jitter
• minimum jitter
• maximum jitter
• CPU core

For real-time fieldbuses, the maximum cycle time and jitter outliers often matter more than the average.

A practical commissioning habit is to reset the monitoring statistics after startup, run the machine under realistic load, and watch the max values while exercising HMI, logging, recipe changes, network traffic, and other background functions.

Free CODESYS timing tool

Paste the values from CODESYS Task Monitoring into the CODESYS Task & Jitter Analyzer:

https://controlscalculator.com/#codesys-card

It converts the raw values into execution utilization, worst-case margin, and jitter as a percentage of the task interval.

6. PDO size directly affects communication time

EtherCAT carries process data for many devices in one or more frames. The amount of cyclic input and output data therefore affects the time required on the wire.

A network with eight small digital I/O blocks has a very different cyclic payload from a network with dozens of servo drives exchanging status words, positions, velocities, torques, modes, and diagnostics.

Before estimating cycle time, total the cyclic process data:

• RxPDO bytes sent from controller to devices
• TxPDO bytes returned from devices to controller
• number of repeated device types
• any additional cyclic data added by the configuration

This is why it is useful to calculate the PDO payload separately from the overall timing budget.

Use the free EtherCAT PDO Size Calculator:

https://controlscalculator.com/#pdo-card

7. Distributed Clocks solve a different problem

A short bus cycle does not automatically mean every distributed device acts at the same instant.

For coordinated motion and synchronized acquisition, the system needs a shared time reference. EtherCAT Distributed Clocks provide that network-wide timing base.

When enabled and supported by the devices, the EtherCAT master and slaves coordinate around a common clock. CODESYS can transfer the configured master cycle time to Distributed Clock-capable slaves, allowing precisely synchronized data exchange.

This distinction matters:

• Cycle time asks how often the network updates.
• Jitter asks how much timing varies.
• Distributed Clocks coordinate when distributed devices act relative to a shared time base.

A machine can have a fast cycle and still need Distributed Clocks to achieve synchronized motion.

8. Check slave minimum cycle times

The controller is not the only device with timing limits.

Servo drives, I/O couplers, measurement terminals, and other EtherCAT devices may specify minimum supported Sync0 or process-data cycle times. A master setting faster than the slowest required device can create a configuration that is impossible even if the controller itself is capable of the rate.

During design, record for each time-critical slave:

• minimum cycle time
• supported Distributed Clock modes
• Sync0 / Sync1 requirements
• PDO size
• required watchdog behavior

The ControlsCalculator Distributed Clock Checker can help verify that a proposed master cycle, Sync0 factor, shift, and slave minimum cycle are internally consistent:

https://controlscalculator.com/#dc-card

It is a planning checker, not a substitute for the device ESI file or manufacturer documentation.

9. The operating system can be the limiting factor

An industrial PC with a fast CPU is not automatically a real-time controller.

General-purpose operating systems optimize for overall responsiveness, throughput, power consumption, and user experience. A real-time control task cares about something different: bounded worst-case delay.

That is why CODESYS offers different runtime approaches for different timing requirements. Standard Windows or standard Linux may be sufficient for slower control. Tighter cycles can require a real-time runtime, a real-time Linux configuration, CPU/task isolation, or additional platform tuning.

The key principle is simple:

Choose the runtime and OS based on the timing class of the application, not just convenience.

10. Background workloads can steal timing margin

A Soft PLC platform is attractive because it can run multiple applications. That is also where problems can appear.

Common background workloads include:

• HMI rendering
• database writes
• historian compression
• file access
• antivirus or endpoint security
• remote support software
• container workloads
• web applications
• system updates
• analytics

CODESYS recommends separating real-time-critical fieldbus work from less critical tasks and giving the bus-cycle task high priority. Blocking operations such as file access should not be placed in the real-time bus task.

If one industrial PC runs control and compute workloads together, CPU affinity, priorities, service configuration, and resource isolation become part of the control design.

11. Test under worst-case conditions

A ten-minute idle bench test is not enough to validate deterministic behavior.

A more useful test plan includes:

• machine at maximum production rate
• all EtherCAT nodes active
• HMI animations running
• historian writes enabled
• recipe downloads or product changes
• northbound network traffic
• remote diagnostics
• expected background services
• hot operating temperature if applicable
• extended-duration cyclic latency testing

Watch for outliers, not just averages.

A system that runs at 100 us average jitter but spikes to 900 us once every few minutes may be unacceptable for a 1 ms motion task even though the average looks fine.

12. A commissioning checklist

Before signing off an EtherCAT Soft PLC system:

• ☐ Confirm the required machine cycle.
• ☐ Confirm every slave's minimum supported cycle.
• ☐ Calculate total cyclic PDO payload.
• ☐ Set an EtherCAT cycle with engineering margin.
• ☐ Confirm task interval and fieldbus cycle relationship.
• ☐ Review CODESYS max cycle time and jitter.
• ☐ Verify Distributed Clock configuration where synchronization is required.
• ☐ Run the machine under maximum realistic background load.
• ☐ Check CPU/core assignment and task priority.
• ☐ Review power-management and network-driver settings.
• ☐ Run an extended-duration latency test.
• ☐ Define what happens if a timing deadline is missed.

Final takeaway

EtherCAT performance should be treated as a system timing problem, not a protocol benchmark.

The best design starts with the process requirement, creates a timing budget, selects the correct CODESYS runtime and hardware, calculates process-data load, configures Distributed Clocks where required, and validates the finished system under real load.

That approach makes the difference between a network that looks fast on paper and a control system that behaves predictably in production.

Free ControlsCalculator tools

• EtherCAT Cycle Time Planner: https://controlscalculator.com/#ethercat-cycle-card
• EtherCAT PDO Size Calculator: https://controlscalculator.com/#pdo-card
• EtherCAT Distributed Clock Checker: https://controlscalculator.com/#dc-card
• CODESYS Task & Jitter Analyzer: https://controlscalculator.com/#codesys-card

Technical references

• EtherCAT Technology Group: EtherCAT technology and Distributed Clocks
• CODESYS: Task Monitoring and jitter definitions
• CODESYS: EtherCAT Master / Distributed Clock configuration
• CODESYS: Fieldbus task configuration guidance

ControlsCalculator.com provides planning tools for engineering estimates. Validate final cycle-time and real-time performance on the actual controller, runtime, OS, network, and EtherCAT device set.