← Resources
Practice·7 min read·

When scan time matters, and what to do about it

Most programs do not need optimising. Recognising the ones that do, and knowing where the time actually goes.

Short answer

First measure rather than guess: most platforms report scan time and per-task timing. The usual causes are large loops, unnecessary floating point in cyclic code, and communication instructions executing every scan. Moving slow work into a periodic task at a lower rate fixes most problems without touching the logic.

PLC scan cycleRead inputsSolve logicWrite outputsHousekeepingRepeat1-20MILLISECONDS

Most programs never need this. The ones that do usually have one specific cause rather than a general slowness.

Measure before changing anything

Every platform reports scan time, and most report it per task. Guessing which routine is slow is almost always wrong, and optimising the wrong thing costs a day and changes nothing.

The usual causes

  • Loops over large arrays executed every scan when they could run once every hundred.
  • Floating point in cyclic code. Slower than integer maths, and often unnecessary.
  • Communication instructions triggered unconditionally rather than on demand.
  • Long conditional chains where a small reorder lets the common case exit early.

The fix that usually works

Move slow work out of the main cyclic task and into a periodic task running at a rate the work actually needs. A recipe calculation does not need to run every 5 ms.

This is almost always better than making the slow code faster, because it changes the requirement rather than the implementation.

When it genuinely matters

When the shortest signal you must catch approaches the worst-case scan. Below that, scan time is a number on a screen and not a problem.

Common questions

What is a normal PLC scan time?
One to twenty milliseconds for a typical machine program on a modern controller. What matters is not the average but the worst case and whether it is stable, because a scan that occasionally stretches to fifty milliseconds will miss signals that the average suggests it should catch.
How do I find what is slowing down my PLC scan?
Use the platform's task monitoring rather than guessing. Rockwell reports per-task scan times; Siemens exposes cycle time statistics. The usual culprits are loops over large arrays, floating point maths in cyclic code, and messaging instructions triggered every scan rather than on demand.

Keep reading