A sensor detects a fast-moving part, but the PLC sometimes misses it. The input light flashes, the wiring is correct, and the logic works in slow testing. The problem is the scan: the controller reads inputs, executes the program, and writes outputs in a repeating cycle, and an event shorter than that cycle can fall between reads.
The scan cycle
A PLC does not run continuously in the way a simple relay does. Each scan, it reads all physical inputs into an input table, executes the user program from top to bottom using that table, and then updates the physical outputs. During program execution the input values are fixed, even if a signal changes in the middle of the scan. The scan time is the total for input read, program execution, overhead, and output write.
A typical small program scans in one to a few milliseconds; large programs with complex instructions, loops, and communication can take ten milliseconds or more. The actual scan time is displayed by the controller and should be measured, not assumed from the processor speed.
Why short pulses are missed
If an input is true for less than one scan, the PLC may never sample it during the read phase. A part passing a photo eye for 2 ms, on a 5 ms scan, can arrive and leave between two input reads. Making the sensor or the part faster worsens it; the limiting factor is the scan, not the device.
The common fix uses a high-speed or interrupt input that captures the pulse in hardware independent of the scan, latching it for the program. Another approach lengthens the signal mechanically, slowing the target or widening the sensed feature. Don’t simply shorten the whole program if a dedicated capture input is available.
Input and output delays add up
The total response is not just scan time. Digital input modules have filtering and delay, often set to reject contact bounce; outputs have switching delay; and the driven device, a relay or valve, adds its own time. A safety or high-speed response must count the full chain from sensor to actuator, where the PLC scan is only one term. Input filters left at a long default can themselves swallow a short pulse before the program sees it.
Interrupts and immediate I/O
Event interrupts pause the normal scan to run a short routine when a critical input changes, giving response well below scan time. Immediate input and output instructions read or update a physical point during the program rather than waiting for the scan boundary. These tools suit time-critical actions, but interrupt routines should stay short, since long interrupts disrupt the main scan and communication timing.
Scan time variation
Scan time is not always constant. Conditional code, communication loads, and fluctuating program paths change it cycle to cycle. A response that usually fits can occasionally miss when the scan lengthens. Use the maximum or worst-case scan time for timing decisions, and monitor it for unexpected growth as the program and communication load expand.
A suddenly increasing scan time after a program change often points to looping code, excessive communication, or a fault being retried; investigate rather than accepting slower response.
Program order and internal signals
Within one scan, an output set early in the program is visible to later logic using its internal address, even though the physical output updates only at the end. This one-scan behavior matters with counters, latches, and handshaking. A signal passed between routines can lag one scan, which is irrelevant in slow sequences but breaks tight step logic. Understand whether a given contact reads the current scan’s result or the previous scan’s value.
Communication with other devices
Data exchanged over fieldbus or serial updates on its own cycle, often slower than the PLC scan. A value from a drive or another controller may be several or tens of milliseconds old regardless of local scan speed. Don’t assume networked data is current; check the communication update time and account for it in the response budget.
Timing a real application
Consider a high-speed wrapper where a part passes a sensor and a rejector must fire within a fixed window. The input filter adds 1 ms, the worst-case scan is 4 ms, the output and a solenoid valve add 15 ms, and the actuator travel adds time. The total is dominated by the valve, not the scan, which means upgrading the PLC does little while replacing the valve with a faster type or timing the trigger earlier does. Lay out every term in the chain before deciding where to spend money; engineers often optimize the scan while a slow pneumatic actuator sets the real limit.
Watchdog and fault behavior
A scan watchdog stops the controller if the scan exceeds a set time, catching runaway loops or a locked program. Set it above the legitimate worst-case scan but low enough to catch a true stall. If the watchdog trips, treat it as a fault in the program or hardware rather than simply extending the limit, since it indicates the scan no longer completes in the expected time. Define safe output state on a watchdog stop, especially for motion and heating that should not remain energized.
Task scheduling in larger controllers
Many modern controllers split logic into tasks: a fast cyclic task for critical motion or control, a slower task for general logic, and background tasks for communication. Assigning time-critical code to a fast task gives short, predictable response without running the entire program at that rate. Don’t place slow communication or heavy math in the fastest task, since it lengthens the critical cycle. Match each part of the program to the response speed it actually needs.
Counters and high-speed signals
Conventional counters incremented in the normal program undercount pulses faster than the scan. Hardware high-speed counter modules count encoder and pulse signals independently and the program reads the accumulated total, which is the correct approach for encoders and flow meters. Similarly, pulse-width and frequency outputs that must be precise use dedicated hardware rather than toggling outputs in the logic, where scan jitter corrupts the timing.
Debounce versus responsiveness
Input filtering and debounce prevent false counts from mechanical contact bounce and electrical noise, but they add delay and can block genuine fast signals. Set the filter to the minimum that reliably rejects the noise of the actual device rather than leaving a conservative default. For solid-state sensors with clean signals, little filtering is needed; for mechanical switches, more is appropriate. Adjust per input rather than applying one global filter.
Testing timing properly
Use an oscilloscope or the controller’s trace tools to measure the real delay from sensor edge to output change, including worst-case scan. Logic tested by slowly forcing inputs does not reveal scan-related misses. Test at production speed with the real cycle and deliberately exercise the fastest events and heaviest communication load. Record measured scan time and response so later program additions can be checked against the timing margin rather than discovered in production.
Determinism and real-time control
For motion and closed-loop control, average scan time matters less than determinism: the cycle must complete in a consistent, bounded time so control does not jitter. A task that usually runs in 2 ms but occasionally takes 8 ms produces unstable motion even though its average looks good. Isolate the control task from communication and general logic, avoid variable-length loops and unbounded data handling inside it, and verify the worst-case cycle under full load. This is where a simple scan-time number is not enough; the distribution and the maximum determine whether real-time control is trustworthy. Standard PLC sequencing tolerates moderate variation, but coordinated axes and high-speed regulation do not, and treating them with the same loose timing as ordinary logic is a common source of tuning problems that no gain adjustment can fix.
Finally, keep timing in mind when adding features to a running machine. New communication messages, data logging, and larger screens all consume scan or task time, and a controller with margin at commissioning can drift to its limit after several additions. Recheck the measured worst-case scan after each significant change, and reserve spare capacity deliberately rather than sizing the processor to barely handle the first version. A small timing margin protects against the slow growth that otherwise appears as mysterious, intermittent misses months later.
A quick timing check at commissioning, repeated after each later change, takes minutes and prevents the intermittent faults that are hardest to diagnose on a production line.
That habit alone removes most timing surprises.
That simple habit alone removes most timing surprises over the years.
Bottom line
The PLC responds through a scan that samples inputs once per cycle, so events shorter than the worst-case scan can be missed. Measure scan time, include input filters, output delays, and network update in the response budget, and use interrupts or high-speed inputs for short pulses. Keep interrupt routines short and watch scan time growth. Fast sensors don’t guarantee fast control; the scan and the full signal chain decide what the controller can actually catch.
