CODESYS Task & Jitter Calculator
This free CODESYS task and jitter calculator turns the values from your CODESYS task monitoring into a plain timing health check. Enter the task interval, average and maximum execution times, maximum and minimum jitter, and the watchdog limit; it calculates average and worst-case utilization, the execution margin left in each cycle, peak-to-peak jitter, and how much room your worst execution leaves before the watchdog. It's for controls and automation engineers commissioning a CODESYS controller, hunting an intermittent task overrun, or deciding whether a task can run faster or take on more code. No account, no spreadsheet — the formulas and verdict thresholds are shown below so you can reproduce every figure by hand.
Turn CODESYS task-monitoring values into utilization, timing margin, and jitter indicators.
Uses the task interval and observed CODESYS monitoring values you enter. Utilization is execution time ÷ task interval; peak-to-peak jitter is maximum jitter minus minimum jitter. The health message is a planning indicator only and does not certify real-time performance.
The formula
Everything here is a ratio or a subtraction — the value of the calculator is that it applies all of them, plus the verdict thresholds, to the same set of monitoring numbers at once:
Utilization (execution time as a share of the interval) Average utilization = t_avg ÷ T × 100% Worst utilization = t_max ÷ T × 100% Headroom left in each cycle Execution margin = T − t_max Watchdog margin = t_wd − t_max Jitter Peak-to-peak jitter = j_max − j_min (j_min is normally negative) Max jitter share = j_max ÷ T × 100%
| Variable | Meaning | Where it comes from |
|---|---|---|
| T | Task interval (µs) — the configured cycle time of the task | The task's configuration in CODESYS |
| t_avg | Average execution time (µs) over the observation window | CODESYS online task monitoring |
| t_max | Maximum execution time (µs) observed — the worst single cycle | CODESYS online task monitoring |
| j_max | Maximum positive jitter (µs) — the latest the cycle effectively ran | CODESYS online task monitoring |
| j_min | Minimum jitter (µs) — the earliest it ran; normally a negative value | CODESYS online task monitoring |
| t_wd | Watchdog limit (µs) — the execution bound the watchdog enforces | The task's watchdog configuration, converted to µs |
Why the worst case runs the verdict: a task does not fail on its average cycle, it fails on its worst one. The average utilization tells you how busy the task is in general; the maximum execution decides whether any single cycle overruns the interval or reaches the watchdog. Jitter is treated the same way — the peak-to-peak spread (latest minus earliest) is the timing uncertainty your I/O, fieldbus, and motion actually experience, so that is what the calculator reports rather than either extreme in isolation.
The thresholds the verdict applies (all verified in the source): the strongest warning triggers when maximum execution reaches the interval or the watchdog margin is zero or negative — both mean a limit has effectively been met. The caution triggers when worst utilization is at least 80%, maximum jitter is at least 20% of the interval, or the execution margin is down to 20% of the interval or less. Anything else is reported as having useful margin. §6 walks through each output.
What each input means
Every field below is exactly as it appears in the live calculator (labels and defaults verified in source). All values are in microseconds — a 10 ms task interval is entered as 10000, not 10.
| Input | Unit | Default | What breaks if you get it wrong |
|---|---|---|---|
| Task interval (µs) | µs (min 1) | 1000 | The denominator of every percentage. Entering the interval in milliseconds (1 instead of 1000) makes utilization look a thousand times worse; entering a different task's interval invalidates the whole result |
| Average execution (µs) | µs (min 0) | 310 | The baseline load figure. Using it alone hides the spikes — a task can average 31% and still overrun on its worst cycles. It never drives the warning verdicts by itself |
| Maximum execution (µs) | µs (min 0) | 680 | The decisive input: margin, worst utilization, and watchdog margin are all computed from it. Reading it after a few quiet minutes understates it — the observed maximum only grows the longer the task runs under real load |
| Maximum positive jitter (µs) | µs (min 0) | 90 | The late extreme only. Entering the peak-to-peak figure here double-counts the spread, and entering a "typical" jitter instead of the observed maximum hides the worst scheduling behaviour |
| Minimum jitter (µs) | µs (negative) | −65 | Enter it as a negative number — it is how early the cycle ran. Entering 65 instead of −65 understates peak-to-peak jitter by 130 µs at these defaults (25 µs instead of 155 µs). This is the only field that takes a negative value |
| Watchdog limit (µs) | µs (min 1) | 1000 | The bound the task watchdog enforces, in µs (convert it if your task configuration expresses it in ms). If the limit you enter is at or below the maximum execution, the verdict goes straight to its strongest warning — because in the controller, that spike is a watchdog trip |
Worked example
Scenario: a 1 ms cyclic task on a CODESYS controller, observed in online task monitoring under normal production load. The inputs below are the calculator's own starting values, so you can reproduce this example exactly by opening the calculator and pressing "Analyze task timing" without changing anything.
Inputs (the calculator's defaults):
- Task interval: 1000 µs
- Average execution: 310 µs
- Maximum execution: 680 µs
- Maximum positive jitter: 90 µs
- Minimum jitter: −65 µs
- Watchdog limit: 1000 µs
Step by step:
- Average utilization: 310 ÷ 1000 × 100 = 31%
- Worst utilization: 680 ÷ 1000 × 100 = 68%
- Execution margin: 1000 − 680 = 320 µs left in the worst cycle
- Peak-to-peak jitter: 90 − (−65) = 155 µs
- Maximum jitter share: 90 ÷ 1000 × 100 = 9% of the task interval
- Watchdog margin: 1000 − 680 = 320 µs between the worst execution and the watchdog limit
The calculator's verdict for these inputs reads: "Observed execution time has useful margin against the configured interval. Max positive jitter is 9% of the task interval; watchdog margin is 320 µs."
What the example shows: the average (31%) makes the task look half asleep; the worst case (68%) is the honest picture — comfortably inside the cycle, but with less than a third of the interval in reserve. None of the caution thresholds is close: worst utilization is below 80%, jitter is 9% of the interval against a 20% trigger, and the margin is 32% of the interval against a 20% trigger.
Contrasting case — the same task, more code. Add a feature block and the observed maximum execution climbs to 850 µs (everything else unchanged):
- Worst utilization: 850 ÷ 1000 × 100 = 85% — over the 80% trigger
- Execution margin: 1000 − 850 = 150 µs — 15% of the interval, under the 20% trigger
- Watchdog margin: 1000 − 850 = 150 µs
The verdict flips to: "Timing margin is relatively thin. Review task load and jitter, especially for motion or fieldbus tasks. Max positive jitter is 9% of the task interval; watchdog margin is 150 µs." Note the average barely moved — this is exactly the change an average-only check would miss. Push the maximum to 1050 µs and the verdict becomes the strongest warning: worst utilization 105%, execution margin −50 µs, watchdog margin −50 µs — the task is not finishing inside its own cycle.
What the result tells you
The result panel shows four figures (labels as displayed by the live calculator), followed by a verdict line that always ends with two extra facts: "Max positive jitter is {X}% of the task interval; watchdog margin is {Y} µs."
- Average execution utilization — average execution ÷ interval, in percent: how busy the task is on a typical cycle. Useful for spotting a task that is steadily growing, but never the figure to judge safety by.
- Worst observed execution utilization — maximum execution ÷ interval, in percent. This is the verdict's main input: at 80% or above, the calculator flags the margin as thin. At 100% or more the task is overrunning its cycle outright.
- Execution margin to task interval — interval − maximum execution, in µs: the time left over in the worst observed cycle. When it falls to 20% of the interval or less, the caution triggers even if utilization somehow looks acceptable. A negative margin means the worst cycle did not fit.
- Peak-to-peak observed jitter — maximum jitter − minimum jitter, in µs: the total spread of timing variation. The verdict separately reports the maximum positive jitter as a percentage of the interval; at 20% or above, jitter alone triggers the caution.
- The verdict line — one of three messages. Useful margin: no threshold is near. Relatively thin: worst utilization ≥ 80%, jitter ≥ 20% of the interval, or margin ≤ 20% of the interval — the task works today but has little room for spikes, interrupts, or more code. Reaches or exceeds an important timing limit: maximum execution ≥ the interval, or watchdog margin ≤ 0 — review task load, priorities, blocking calls, and watchdog configuration before trusting the task in production.
Common mistakes
- Judging the task by its average execution. In the worked example the average is 31% and the worst case is 68% — and the contrasting case reaches an 85% worst case without the average becoming alarming. Overruns, watchdog trips, and missed cycles live in the maximum, not the mean.
- Entering the minimum jitter as a positive number. Minimum jitter is how early the cycle ran, so it is negative. Typing 65 instead of −65 turns a 155 µs peak-to-peak spread into 25 µs and makes a jittery task look rock steady.
- Reading the monitor too early. Maximum execution and jitter extremes are records — they only grow with observation time and load. Values captured minutes after a download, or with the machine idle, flatter every figure. Read them after a full, representative production run.
- Entering cycle time where execution time belongs. Monitoring also reports cycle-related figures that include waiting and idle time. This calculator's method divides execution time by the interval; entering the full cycle time inflates utilization and can make a healthy task look overloaded.
- Treating the watchdog as usable headroom. A watchdog margin near zero is not "just making it" — it means one bad cycle stops the application. The watchdog is the last line of defence, not part of the timing budget; if worst execution is anywhere near it, the task needs restructuring, not optimism.
FAQ
How do I check whether my CODESYS task is overloaded?
Read the task's values from CODESYS online task monitoring — average and maximum execution time, minimum and maximum jitter — and enter them here with the task interval. If the worst observed utilization is under 80% and the maximum execution stays clear of both the interval and the watchdog limit, the calculator rates the task as having useful margin. At or above 80% worst-case utilization it flags the margin as thin, and if maximum execution reaches the interval or the watchdog limit, it flags a limit problem: the task is, at least occasionally, not finishing in time.
Where do I find the execution time and jitter values in CODESYS?
Go online with the controller and open the Task Configuration: the task's monitoring view reports the measured cycle and execution times (current, average, and maximum) and the jitter as minimum and maximum values in microseconds. The task interval and watchdog come from the same task's configuration settings. Take the figures after the machine has run under representative load, not in the first minutes after a download — the maximum and jitter extremes keep growing the longer the task is observed.
What task utilization should I aim for?
There is no single number every controller vendor agrees on, but the worst observed execution — not the average — is the one to watch. This calculator treats a worst-case utilization below 80% of the interval, with maximum jitter under 20% of the interval, as having useful margin. Above that, spikes, interrupts, communication load, and the next program change have very little room. Motion and fieldbus tasks are usually kept well below the threshold; a slow, non-critical task can run closer to it.
What is jitter, and why does the calculator use peak-to-peak?
Jitter is the variation in when a task actually starts and finishes relative to its ideal schedule. CODESYS reports it as a minimum (the cycle started early, a negative number) and a maximum (it started late). Peak-to-peak jitter — maximum minus minimum — is the total spread your process actually experiences: with +90 µs and −65 µs, the timing wanders across a 155 µs band. For fieldbus synchronization and motion, that spread matters more than either extreme alone.
What happens when maximum execution exceeds the task interval?
The task cannot finish within its own cycle: cycles are overrun or skipped, outputs update late, and if the execution reaches the watchdog limit the controller raises a watchdog error and typically stops the application. The calculator flags this state directly — a maximum execution at or above the interval, or a watchdog margin of zero or less, produces its strongest warning. The fixes are to move work to a slower task, split the task, raise the interval, or find the blocking code path that produces the spike.
Does a good result guarantee my task will keep up in production?
No. The calculator is a planning indicator built from the monitoring values you enter — the same caveat the calculator itself shows. Those values are a snapshot: they change with machine state, communication load, recipe or program changes, and how long the controller has been observed. Re-check after any significant program change and after the machine has run a full production cycle, and treat a thin margin as a warning even when today's verdict is good.
Related tools and reading
- EtherCAT Cycle Time Calculator — the fieldbus-side companion (live now): a cyclic task driving an EtherCAT network has to fit its execution inside the cycle budget the network allows, and this check tells you whether it does.
- Guide: EtherCAT Cycle Time, Jitter and Distributed Clocks — A Practical Guide — jitter and task timing in the EtherCAT context, in long form.
- All other calculators: EtherCAT PDO Size · EtherCAT Distributed Clock Checker · Modbus RTU Timing · 24VDC Power Supply · Enclosure Cooling · Historian Storage
- Calculator hub — all eight free calculators on one page.
Timing is only one part of the design.
The free Controls Toolkit includes editable Excel workbooks and printable PDF worksheets for system sizing, network planning, and commissioning — starting with Industrial PC sizing and EtherCAT timing budgets, with more resources on the way. Free by email signup.