Every pass a PLC makes through its program is broken into distinct phases, and two of them deal purely with the physical world: the input scan, where the controller reads all its inputs, and the output scan, where it writes all its outputs. In between sits the logic-solving phase, and around them sits housekeeping. This page focuses specifically on how and when physical I/O actually gets updated, which is a narrower question than the overall scan cycle and the one that most often decides whether field timing behaves the way you expect.
Input & Output Scan in one line: The input scan is the phase at the start of each PLC cycle where the controller reads every physical input and copies it into memory, and the output scan is the phase at the end where it writes the computed results out to every physical output. Logic is solved in between, so inputs are captured once per cycle and outputs are applied once per cycle.
A conventional PLC scan runs the same ordered sequence over and over. First comes the input scan: the controller reads the state of all its input modules and stores those states in memory, taking a single coherent snapshot of the field. Second comes the program scan, where the logic is solved from the top of the code to the bottom, examining the captured inputs and computing new output states. Third comes the output scan, where the controller writes those computed states out to the physical output modules all at once. Fourth comes housekeeping - communications, diagnostics, and internal overhead - before the cycle repeats.
The value of this fixed order is that I/O is touched at exactly two well-defined moments, not continuously. Inputs are read once, at the top of the cycle, and are then held stable for the entire logic-solving phase. Outputs are written once, at the bottom, after the logic has fully settled. A programmer can therefore reason about the program as if the field were frozen while the code runs, because as far as the physical I/O is concerned, it is.
This structure is what separates the I/O-update view of a scan from the broader idea of scan time. Scan time measures how long the whole loop takes; the input and output scans are the specific slices of that loop where the controller and the field exchange data. The rest of the time the program is working entirely on internal copies, which is why understanding these two phases explains most field timing questions without needing to time the whole cycle.
Because inputs are read only during the input scan, the moment a signal reaches the program is not the moment it changes in the field - it is the next input scan after that change. A contact that closes just after the input scan finishes waits, unseen, through the entire logic and output phases and is only captured at the start of the following cycle. This is the single most important consequence of phased scanning and the source of most confusion about why the controller seems slow to react to a fast event.
The output side has the mirror behavior. When the logic energizes a coil, the physical output does not move immediately; it changes only when the output scan runs at the end of the cycle. So the total delay from a physical input changing to the resulting physical output changing spans, in the worst case, nearly a full scan of waiting to be read plus a full scan to be written. For process signals that move over seconds this is negligible, but for anything approaching the scan speed it is the dominant timing effect.
This is also why a change-of-state input must persist. If an input is not held true long enough to still be present when the next input scan samples it, the program never sees it. The rule of thumb that an input should be held for at least one full scan comes directly from this: the input scan is a sampling event, and anything that lives and dies between two samples is invisible. Designers of fast or pulsed inputs work around this with edge detection in software or with hardware channels that bypass the phased I/O update entirely.
Local I/O sits on the controller's own backplane, so reading inputs and writing outputs during the scan phases is fast and predictable. Remote I/O changes the picture, because now the input and output data must travel across a network before it can be read or after it is written. The controller's input scan may work from values that a remote I/O adapter gathered a moment earlier and forwarded, and the output scan writes to values that must then be transmitted to a remote rack before they reach a physical terminal. Each hop adds its own delay on top of the controller's own scan.
In distributed oil and gas systems this matters because a single controller may serve I/O spread across a pad or a facility over a fieldbus or an industrial network, and telemetered RTU I/O may be even further away over radio, cellular, or serial links. The field value the program acts on is then as old as the network update interval plus the scan phase timing, and the output the program commands takes that same path back out. The read and write phases still happen once per scan in the controller, but the true field-to-field latency is set by the slowest link in the chain.
Designing around this means matching the update rate of remote I/O to how fast the signal actually needs to move. Slow analog readings and status points tolerate the added latency without trouble, while anything time-critical is kept local to the controller so it stays within the fast, deterministic on-backplane input and output scans. Confusing a leisurely remote update with a local one is a common way to build logic that reacts far more slowly in the field than it appears to on the bench, where everything was wired locally.
The controller runs the input scan first, reading all physical inputs into memory, then the program scan, solving the logic from top to bottom, then the output scan, writing all results to the physical outputs, and finally housekeeping for communications and diagnostics. This ordered sequence repeats continuously. Because I/O is touched only in the input and output phases, the field is effectively frozen while the logic runs.
The overall scan cycle is the entire repeating loop and its total duration is the scan time, while the input scan is just the one phase within that loop where physical inputs are read into memory. Likewise the output scan is only the phase where outputs are written back out. Focusing on the input and output scans answers questions about when field I/O actually updates, rather than how long the whole cycle takes.
The controller still performs its input and output scans once per cycle, but with remote I/O the data has to cross a network before it can be read or after it is written, adding latency. The true delay from field to field then becomes the network update interval plus the scan timing. Time-critical signals are usually kept on local backplane I/O so they stay within the fast, deterministic scan phases.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.