Subscribe
Tools Automation

PLC Scan Time & Memory Calculator

t_scan = t_overhead + Σ(n_i × t_i) + t_io + t_comm µs, ms, KB, MB

Estimate scan cycle from program size in rungs. Assumes a "typical" rung with ~5 bit operations, 1 word operation, and occasional timers/counters.

Estimates only. Real scan time depends on the specific CPU firmware, actual instruction mix, communication traffic, and OS overhead — the published per-instruction times are typical values, not guarantees. For safety-critical timing decisions, measure the actual scan cycle on your live PLC using the vendor's diagnostic tools (Siemens task monitor, RSLogix scan-time display, etc.). This calculator gets you within about ±30% for typical programs — good enough for CPU selection and program-size planning.

What is PLC scan time?

The scan cycle is how long the PLC takes to run through its complete program once — read inputs, execute every rung of ladder logic (or the equivalent structured text / function block), write outputs, and handle communication and housekeeping. It’s the single most important performance metric for a control system: everything the PLC does happens on this cycle. A 10 ms scan means outputs update at most every 10 ms, and inputs are seen no faster than that.

How to use this calculator

Three modes cover the three real questions:

  • Scan time (quick) — estimate from program size (rungs), complexity, I/O count, and communication load. Best for “will this fit on an S7-1200 or do I need an S7-1500?” decisions.
  • Scan time (detailed) — enter counts of each instruction type. Best for tuning an existing program or estimating a specific piece of logic.
  • Memory usage — estimate program and data memory footprint from tag counts and rung count. Flags whether the target CPU has enough headroom.

Pick your CPU platform from the dropdown at the top — everything below uses the timing and memory characteristics of that specific CPU. Custom lets you enter values from a datasheet.

The formula

The scan time model is straightforward:

t_scan = t_overhead + t_io + t_comm + Σ (n_i × t_i)

Where:

  • t_overhead — fixed per-scan system tasks (OS, task manager, watchdog)
  • t_io — I/O scan time (proportional to I/O count)
  • t_comm — communication task overhead (HMI updates, EtherNet/IP, PROFINET, etc.)
  • Σ (n_i × t_i) — sum of instruction counts times per-instruction execution times

Per-CPU timing data

The heart of the calculator is a database of typical per-instruction execution times for the most common industrial PLC platforms:

  • Siemens S7-1200 (1214C class) — mid-range mid-2010s design. Bit ops ~85 ns, real math ~2.3 µs, timers ~5 µs.
  • Siemens S7-1500 (1513-1PN class) — high-performance mid-range. Bit ops ~10 ns, real math ~0.2 µs. About 15-20× faster than the 1200 on typical workloads.
  • Siemens S7-1500 (1518 top-end) — flagship. Bit ops ~1 ns, real math ~18 ns. Serious floating-point capability.
  • Allen-Bradley CompactLogix 5380 — mid-range AB, comparable to S7-1500 mid-tier.
  • Allen-Bradley ControlLogix 5580 — top AB range, comparable to S7-1500 top-end.
  • Allen-Bradley Micro850 — entry-level. Bit ops ~300 ns, real math ~5 µs. Fine for simple machines, painful for complex ones.
  • Mitsubishi FX5U — mid-range Mitsubishi. Modern, competitive with S7-1500 mid.
  • Mitsubishi iQ-R — top-end Mitsubishi. Very fast, targeted at motion and process.
  • Omron NX1P2 — mid-range Omron.
  • Beckhoff CX2000 / TwinCAT — PC-based control. Effectively unlimited memory; instruction times comparable to fast dedicated PLCs.

These are typical published values — real firmware may vary, and specific instructions (like advanced math or communication commands) can be significantly slower than the averages.

Complexity presets in quick mode

The quick mode uses per-rung instruction averages calibrated to three complexity profiles:

  • Simple — mostly bit logic. Think basic machine sequencing, simple interlocks, on/off control. About 3 bit ops per rung.
  • Typical — mix of bit logic, word moves, comparisons, occasional math and blocks. Most industrial programs. 5 bit ops, 1 word op, 0.5 compares per rung on average.
  • Heavy — process control with lots of math, PID loops, block calls, communication. 7 bit ops, 2.5 word ops, plus significant real math and block calls per rung.

What drives scan time in practice

Three things dominate real-world scan cycles:

  1. Communication — HMI polling, EtherNet/IP or PROFINET traffic, and OPC UA servers can consume 20–40% of scan time on heavily-communicating CPUs. A quiet standalone PLC scans much faster than the same program with a busy SCADA connection.
  2. Floating-point math — REAL operations are 10–30× slower than bit ops on entry-level CPUs, only 3–4× slower on flagships. If you have many PID loops or calculations, the CPU tier matters enormously.
  3. I/O count and organization — reading 1000 remote I/O points across two PROFINET networks is much slower than reading 100 local I/O. Distributed I/O is convenient but scan-costly.

Memory usage

Data memory scales with tag count. Different platforms use different sizes for the same data types:

  • BOOL — 1 byte on Siemens, 4 bytes on Allen-Bradley (DINT-aligned). AB’s BOOL is 4× the size of Siemens’.
  • INT — 2 bytes everywhere
  • DINT / REAL — 4 bytes everywhere
  • STRING — 88 bytes on AB (fixed 82-char), 256 bytes on Siemens (fixed 254-char), 32 or 128 bytes on Mitsubishi/Omron depending on config
  • Timer / Counter — 8–16 bytes for the instance data, depending on platform

Program memory scales with the number of rungs (typically 40–60 bytes per rung), plus function block and add-on-instruction storage overhead. The calculator shows both totals and flags if either exceeds the target CPU’s typical capacity.

Scan time targets by application

  • ≤ 1 ms — high-speed machine control, servo integration, packaging
  • 1–5 ms — general machine and process control — the sweet spot for most applications
  • 5–20 ms — slow process control, batch operations, HVAC, water treatment
  • > 20 ms — becomes noticeable on operator interfaces, unusable for machine sequencing

If you need better than 1 ms deterministic response, don’t try to solve it with faster scan — use hardware axis modules, dedicated motion controllers, or interrupt-driven tasks. Scan is best-effort; hardware is deterministic.

Things this calculator can’t predict

  • Worst-case jitter — interrupts, communication tasks, and IO refresh can extend individual scans significantly. Real-time control needs measurement of worst-case, not average.
  • Communication buffer overflow — heavy protocols may drop packets rather than slow scan; separate math needed for CPU load.
  • Task priority effects — modern CPUs run scan alongside cyclic and event-driven tasks with different priorities. The average matters less than task worst-case timing.
  • Non-standard instructions — motion, comms, and manufacturer-specific block functions can be much slower than the averages in this calculator.
  • Optimization by firmware — compilers may remove dead code, cache frequently-accessed tags, or inline block calls; real behavior can be better than the model.

For anything safety-critical or deterministic, use the vendor’s diagnostic tools to measure actual scan time on a running CPU. This calculator is for planning and CPU selection — get you to the right ballpark before you commit to hardware.

How to reduce PLC scan time

If you find your scan is too slow, options in order of effort:

  1. Move slow logic to a slower cyclic task — HVAC control at 100 ms doesn’t need to be in the main 5 ms loop
  2. Reduce communication load — cut HMI update rates for non-critical values, remove unused OPC connections
  3. Consolidate rungs — collapse repeated logic into loops or subroutines that share a single execution
  4. Use fewer instances — avoid creating 100 timer instances when 5 dispatched dynamically will do
  5. Upgrade the CPU — the last resort, but sometimes the right answer when the platform is genuinely undersized
← All Tools