People treat a PLC as a device that reads inputs, runs logic, and writes outputs all at once. It doesn’t. It does it in slices, and the size of those slices decides whether your machine runs like a closed loop or like a guy reading a checklist.
What a scan actually is
A typical scan does three things in order: it reads all physical inputs into an image table, it runs the ladder logic once from top to bottom, then it writes the image table out to physical outputs. Then it loops.
A small program on a mid-range PLC might scan in 5 to 15 milliseconds. That sounds fast until you’re tuning a loop where the process changes in 20 ms. By the time the output updates, you’ve already blown past the setpoint.
The trap is that nothing on the screen tells you this. The HMI shows the input and output as live values, but they aren’t live. They’re snapshots. The input you see on screen is from the start of the scan; the output you see is from the end of the previous one.
When the delay bites
For a conveyor that starts and stops once a minute, a 10 ms scan delay is invisible. Nobody cares. The motor doesn’t know.
It bites in three situations. First, fast closed-loop control: temperature, pressure, or position loops where you’re PID tuning inside the PLC. If your scan is 10 ms and your process time constant is 50 ms, your loop gain is already limited before you write a single line of logic. You can tune the gains all day; the sample rate is the ceiling.
Second, interlocked motions. If a gripper has to confirm it’s holding a part before the axis moves, and that confirmation lags by half a scan, you can command motion on a part that was dropped two scans ago. On a press or a riveter, that’s a bad part or a jammed tool.
Third, counting. Encoder pulses that arrive between input scans get missed unless you use a high-speed input module. A regular digital input on a 10 ms scan can see pulses shorter than that as noise or nothing at all.
The fixes, ordered by cost
Before you buy a faster PLC, check what’s actually slow.
Most scans don’t waste time on logic. They waste time on communication. A MODBUS poll that takes 8 ms, a few HMI tags updating, a serial port waiting for a barcode scanner, and suddenly your 15 ms program is a 40 ms scan. Move the slow comms to an interrupt or a separate task, and you get most of the speed back without touching the CPU.
Next, look at what you put in the cyclic task. String handling, floating-point math, and array operations are expensive on small PLCs. If a recipe calculation only needs to run when a recipe changes, put it in a triggered subroutine, not in every scan.
If you truly need sub-millisecond response, you have to leave the cyclic scan. Most PLCs support interrupt-driven tasks: an input edge triggers a routine that runs immediately, outside the normal scan. Use that for e-stop acknowledgment, high-speed latch inputs, and fast counters. Don’t use it for everything, or you’ve just rebuilt an operating system inside the scan.
What to measure before you tune
Don’t guess at scan time. The PLC already tells you: most controllers expose the last scan, max scan, and average scan as system tags. Log them for a day of real production, not a bench test. A bench test with no comms and no HMI will lie to you by a factor of three.
Then look at the worst-case number, not the average. The average scan might be 8 ms, but the moment a recipe downloads or an alarm fires, it jumps to 30 ms. That spike is the one that ruins your loop.
The part nobody budgets for
Input and output filtering adds delay on top of the scan. A digital input configured for 20 ms of debounce will delay every signal by up to that much, regardless of how fast your PLC runs. Analog inputs have hardware filters too, often set to 100 ms by default. If you’re controlling a fast loop and someone left the default filter on, you’ve built a lag you can’t tune away.
Check the filter settings on every analog channel that matters. Set them as fast as the noise allows, not as fast as the salesman suggested.
Bottom line
The scan cycle isn’t a footnote. It’s the sample rate of your whole machine. If you’re buying or specifying a PLC for motion or process control, ask what the worst-case scan actually is, on the actual program, with the actual comms running. The datasheet number is for an empty program. Your program is never empty.
