Scan time is the measured execution duration of one controller pass, while task cycle time is the configured period at which the runtime triggers that pass; confusing the two is the most common reason an otherwise correct motion program ships with jitter or watchdog trips.
This reference compares how the two metrics interact on modern discrete and motion controllers, with concrete numbers for typical instruction counts, deterministic motion tasks, and the multi-task scheduling behaviour that drives the programmable logic controller selection decision.
What the two metrics actually measure
Scan time is defined as the measured execution duration of a controller task or cyclic program pass, and it is not automatically the task period or end-to-end cycle [S2]. The runtime still has to spend time on input scan, program execution, output write, and housekeeping/communications before the next cycle can be scheduled, which is why scan time is usually expressed as a worst-case figure rather than an average [S1].
The decomposition most estimators use is T_scan = T_program + T_IO + T_comm + T_housekeeping, where T_program scales roughly as N_rungs times a base per-instruction time, T_IO as N_points times a per-point I/O time, and T_comm as N_modules times a per-module comm time [S1]. For a typical discrete-machine PLC, a 5 to 50 ms scan is the normal band when running 2,000 to 5,000 instructions on a moderately loaded program [S3].
Comparison: how scan time and task cycle time differ on a real controller
On a modern PLC the runtime exposes both a cyclic task (fixed period) and one or more event or periodic tasks (interrupt-driven, e.g. on a high-speed counter overflow or a motion event), and the designer is expected to size the period above the worst-case scan plus a guard band of typically 10 to 25 percent [S5].
Four practical criteria illustrate the difference. (1) Definition: scan time is measured execution of one pass, task cycle time is the configured trigger period; the two are equal only when scan is the full budget. (2) Worst-case response: the longest input-to-output delay is up to one cycle plus one scan, which is why many designers budget two scans for any inter-step hand-off [S4]. (3) Determinism on motion: a generic logic scan in the 5 to 50 ms band is far too slow to drive a servo loop, which is why motion is run on a separate task with a sub-millisecond period and a dedicated motion controller or motion engine. (4) Failure mode: if scan exceeds the configured period, the runtime reports a scan-overrun or watchdog fault rather than silently dropping cycles, and the published productivity model shows that a 30 ms scan versus a 6 ms scan on a six-step 30 s machine running 8 hours/day can add about 2,250 parts/year to throughput [S4].
Where each number actually matters: discrete logic vs motion
For discrete logic, scan time in the 5 to 50 ms range is the engineering norm, and the dominant variables are I/O count, comm modules, and program size rather than raw CPU clock [S1][S3]. On a 64-point I/O, 250-rung program with two comm modules, the public FIRGELLI estimator returns roughly 1.06 ms scan and 2.13 ms worst-case response, which is a useful sanity check for low-density cells [S1].
For motion and high-speed logic, the period is set independently of the discrete scan and typically lands in the 0.5 to 2 ms range for servo loops and 0.1 to 0.5 ms for electronic gearing and cam profiles; this is one reason motion tasks are dispatched on their own priority and are paired with a dedicated motion controller rather than left inside the main logic scan. The scan-time productivity case study in the public Schneider material uses a six-step 30-second machine example to show that the 30 ms versus 6 ms scan delta can move the throughput number on the order of 2,250 parts per year per machine, an effect that compounds across cells [S4].
How to set the cycle period correctly
The standard rule is to set the task period at or above the worst-case scan plus a 10 to 25 percent guard band, so transient overruns do not trip the cycle-overrun fault [S5]. Program-level controls include modularising logic, dropping unused tags, and splitting time-critical work into a separate periodic or interrupt task so the main scan stays deterministic [S5].
Hardware-level controls include compact I/O blocks, EtherNet/IP or PROFINET instead of slower fieldbus, and policing comm traffic so the housekeeping slice stays bounded; older or entry-level CPUs lose determinism under modern workloads even at higher clock speeds, which is one reason multi-core controllers are now the default for mixed logic-plus-motion cells [S5]. When the program is split, the linear motion axis control typically lives on its own task with a hard real-time budget, while the supervisory logic runs on the slower 5 to 50 ms scan [S3].
What to monitor, and what a real overrun looks like
The two numbers worth exporting to SCADA are worst-case scan (not the rolling average) and the cycle-overrun counter; a single recurring overrun is enough to justify either trimming the program or raising the period with a documented guard band [S5]. On motion cells the additional numbers are the servo loop period, the position-error following deviation, and the bus jitter on the line-scan camera or encoder front-end, because a 1 ms scan jitter becomes a measurable position error at high axis speeds.
Two trackable signals going into late 2026: (1) more vendors publishing per-instruction execution time tables so first-principles scan estimates can replace the older 0.1 to 0.5 ms per-rung rule of thumb; (2) tighter integration of time relay style sequencing and safety tasks into the same multi-task scheduler, which raises the bar on documented worst-case rather than average figures. For related reading on the discrete side, see ball screw and linear guide lead times, September 2026 stock vs custom tiers.