Enter your program size, I/O count, and CPU class to get a rule-of-thumb scan cycle estimate — with an honest explanation of what actually drives scan time.
Rule-of-thumb estimate only. Always verify with your controller’s benchmark utility. All calculations are client-side.
CPU class
Estimated scan time range
3.2 ms – 6.0 ms
±30% spread accounts for overhead jitter, OS service tasks, and cache variability. Verify against the actual controller scan-time diagnostic.
How the scan works
Every PLC executes the same repeating loop. Understanding which phase dominates your scan budget is the first step in reducing it.
Background
Every PLC executes a continuous loop — read all inputs into an image table, run every rung of your ladder program against that snapshot, write the output image table back to physical outputs, then service communications. The total elapsed time for one complete cycle is the scan time. Typical values range from under 1 ms for a small micro PLC to 50 ms or more for a heavily loaded mid-range controller.
Scan time matters for three reasons. First, the PLC cannot respond to an input change faster than one scan — a 20 ms scan misses any event shorter than 20 ms unless you use an interrupt task. Second, PID controllers placed in the main scan execute at a variable rate, which degrades loop performance; most PLC platforms provide periodic interrupt tasks specifically to give PID a consistent sample rate. Third, HMI responsiveness and remote I/O update rates both depend on the comms slice within the scan budget.
The estimator multiplies your instruction count by a per-instruction execution time (0.05 µs for a high-end controller, 0.5 µs for a micro PLC — conservative rule-of-thumb values). It adds digital I/O time (approximately 1.5 µs per point), analogue I/O overhead (roughly 2.5 ms per 8-channel card, accounting for ADC conversion latency), and your estimated communications overhead. A ±30% spread is applied to reflect jitter from OS servicing, instruction-cache misses, and remote-I/O variability.
CPU-specific pipeline stalls, instruction-mix effects (floating-point vs. bit instructions can differ by 10×), motion-control axis servicing, and any interrupt tasks you run outside the main scan. For accurate scan time on your specific controller, use the manufacturer’s scan-time diagnostic: Allen-Bradley uses the GSV instruction to read the Overhead Time Object; Siemens TIA Portal shows OB1 cycle time in the Watch Table; Omron reads D8012/D8013 system memory.
The simulator’s scan cycle lesson shows how a slow scan affects output timing. The scenario auto-grades whether your outputs respond within the correct scan window. If your estimator result is marginal for your process, that scenario is the fastest way to observe the consequences.
Numbers in a calculator are one thing. Watching outputs respond — or not — in a graded scenario makes the concept stick.