PLC Input/Output Lag Time: system response time explained
On this page
What causes PLC input/output lag time, and how do you reduce it?
Total system response time is the sum of three delays: input filtering (the deliberate RC filtering on digital inputs, typically several milliseconds), the scan cycle lag (the program must run before a new input reaches the outputs), and output module switching (relay outputs are the slowest, transistor outputs the fastest). The optimisation sequence: switch slow output types for faster ones where the load allows, clean up the program so the scan shortens, and move genuinely time-critical signals onto high-speed counter or interrupt inputs that bypass the ordinary scan.
An earlier version of this page attributed a named facility's lag-reduction case study that could not be verified. It has been removed; the optimisation reasoning below stands on how the delays arise.
The anatomy of response delay
| Component | Where it comes from | Typical scale |
|---|---|---|
| Input filtering | Deliberate RC filtering on digital inputs that rejects electrical noise | milliseconds, set per module |
| Scan cycle lag | An input change waits for the next input scan, then the program must run before the output scan | a few to tens of milliseconds, growing with program size |
| Output module delay | The output stage's own switching time | sub-millisecond for transistors; longest for relays |
Scroll the table horizontally to view all columns.
Source: general PLC architecture and I/O hardware practice per manufacturer documentation. Exact figures are per module and model; confirm in the module specifications.
What affects lag time
- Output hardware type. Relay outputs switch mechanically and are the slowest; transistor outputs switch in the sub-millisecond class and are the choice for fast duty; triac outputs sit between, for AC loads.
- Program size and structure. The scan lengthens with every executed instruction. Unused routines, duplicated logic and deep nesting all add scan time that the application never asked for.
- Input filter settings. Where the module allows configuring the filter, the noise-rejection requirement (not habit) should set it.
- Where the signal enters the scan. An ordinary input waits for the next input scan; a high-speed counter or interrupt input responds immediately, outside the ordinary program flow.
Optimisation strategies
- Match output hardware to the speed requirement. Where a fast response matters, transistor outputs are the documented choice; keep relay outputs for slow, high-current switching.
- Shorten the scan by cleaning the program. Remove dead rungs, reduce redundant evaluations, and move heavy math to slower tasks where the result tolerates it.
- Route time-critical signals to special inputs. High-speed counter and interrupt inputs respond outside the ordinary scan, which is the documented way to catch fast events.
- Measure before and after. Record the response time with a scope or the controller's own diagnostic tools so the improvement is verified, not assumed.
Example: the optimisation order
A packaging station's reject gate fires too late. The checks in order: the gate's relay output switches in about ten milliseconds, so a transistor module replaces it (largest single win); the program is cleaned and the reject logic moved earlier in the scan (a further reduction); and the reject sensor is rewired to a fast input with a shorter filter, justified by the shielded cabling already in place. Each step is measured; together they bring the response inside the machine's window.
Sourcing help
KOEED supplies fast output modules, high-speed counter inputs and the controllers that carry them, across the major brands, in active and EOL stock. Send the application's timing requirement for a quote.
Need a quote for this part?
Send us the part number or article link — we will confirm price, availability and lead time.