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.
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
- Safety
SIL or PL: which one does your machine need?
Two standards, two scales, and one machine. Which one applies, how they map to each other, and why the answer is usually ISO 13849.
- Safety
Categories B, 1, 2, 3 and 4, in plain terms
Five architectures, what a single fault does to each, and the practical wiring that goes with them.
- Safety
Safety relay or safety PLC: how to decide
One is a wiring decision, the other is a programming one. The count of safety functions, not the size of the machine, is what settles it.