A PLC doesn't watch its inputs continuously — it takes one snapshot, runs the whole program against that frozen picture, then reports the result. Repeat.
It's tempting to picture a running PLC as something that continuously watches its wired-in field devices and continuously drives its outputs, reacting instantly and constantly to whatever is happening in the real world at that exact instant. That mental model is wrong, and the actual behavior matters a great deal for anyone troubleshooting a system or wiring up a fast or brief signal. A PLC executes a strict, repeating three-phase cycle called the scan cycle: it reads every physical input into memory once, at the start; it runs the entire logic program against that frozen snapshot, top to bottom; then it writes every physical output once, at the end. Only then does it start the next scan and read inputs again. Nothing about a physical input is visible to the logic mid-scan — the logic only ever sees what was captured at the last read.
Every scan is the same three steps in the same order: Read Inputs — capture the current state of every physical input point into an internal input image table, all at once, at the start of the scan. Execute Logic — evaluate the entire ladder (or structured text, or function block) program from top to bottom, entirely against that input image table, updating internal memory and an internal output image table as it goes. Write Outputs — push the resulting output image table out to the physical output modules, all at once, at the end of the scan. Then the cycle repeats, typically tens or hundreds of times per second.
Every physical input point is sampled and copied into an internal input image table in a single pass. Whatever state a field device is in at that instant is what the program will see — and the only thing it will see — for the entire rest of this scan.
The entire program is evaluated once, against the frozen input image captured in step 1 — never against live, changing field wiring. Every rung sees the exact same input values, no matter how far down the program it sits, which is what makes the logic's behavior deterministic and repeatable.
The output image table built up during logic execution is pushed out to the physical output modules in a single pass — not continuously as each rung evaluates. Physical outputs only change state once per scan, at this one moment.
If a PLC re-read a physical input every time a rung referenced it, two rungs referencing the same input at different points in the same scan could see two different values if that input changed in between — the program's behavior would depend on exactly when, mid-scan, an unrelated field event happened to occur. By reading every input once at the start and holding that image table fixed for the entire logic execution pass, every rung in the program — first rung or last — sees exactly the same input state. That's what makes a scan's outcome fully predictable from its inputs, and it's a deliberate design choice, not a limitation the industry hasn't gotten around to fixing.
False, and it's the assumption behind a lot of confusing field troubleshooting. A standard PLC samples every physical input exactly once, at the start of the scan, into an input image table — and the logic program runs against that fixed snapshot for the rest of the scan, no matter how many times the physical input actually changes state in the real world during that same interval. If a field signal changes state mid-scan, the logic that scan cycle sees the oldvalue captured at the start, not the new one — the change won't be visible to the program until the next scan's read. Taken to the extreme, this is exactly why a very short, brief pulse — one that starts and ends entirely within the gap between two read points, shorter than one full scan time — can be completely missed by a standard scan: it never coincides with either read instant, so it never makes it into the input image table at all. Catching signals that brief reliably requires either a faster scan time (shrinking the gap between reads) or dedicated high-speed input hardware that latches transitions independently of the scan, outside the standard read-execute-write loop entirely.
Explains the repeating three-phase cycle every PLC executes — read all physical inputs into memory once at scan start, execute the entire logic program against that frozen snapshot, write all physical outputs once at scan end — and why a signal change mid-scan isn't seen until the next scan, which is why very brief pulses shorter than one scan time can be missed entirely by standard I/O.
At the start of every scan, the PLC samples the state of every physical input point in a single pass and copies those values into an internal input image table. This is the only moment in the entire scan when physical field wiring is actually read. Whatever value is captured here is what the logic program will use for every rung, for the entire rest of the scan — the program never queries a physical input terminal directly mid-scan. If the field device changes state a microsecond after this read, that change simply isn't visible yet.
The processor then evaluates the entire program — every rung of ladder logic, or every line of structured text — exactly once, from top to bottom, entirely against the input image table captured in the read phase. Because that table doesn't change during execution, every rung sees consistent, unchanging input values regardless of its position in the program. This determinism is deliberate: it guarantees that a given set of inputs always produces the same logical result within a scan, independent of exactly when during the scan a field signal happened to change in the real world.
Once logic execution finishes, the resulting output image table — built up rung by rung during execution — is written out to the physical output modules in a single pass at the end of the scan. Physical outputs do not change state the instant a rung commanding them evaluates true; they change once, at this write phase, after the entire program has finished running. The scan then repeats: read, execute, write, over and over, typically many times per second.
Because inputs are only sampled at discrete read instants rather than continuously, a physical signal that pulses on and off entirely within the gap between two consecutive reads never coincides with either sample and is never captured — the input image table shows it as continuously off, even though it was briefly, genuinely on in the real world. This is a real and common source of "phantom" missed events on fast processes: a proximity sensor catching a fast-moving part, a brief contact bounce, or a quick pressure spike. The fix is either reducing scan time so the gap between reads shrinks below the shortest pulse that must be caught, or using dedicated high-speed input hardware (interrupt-driven or latching inputs) that captures a transition independently of the standard scan entirely.
No. A standard PLC samples every physical input once, at the start of the scan, into an input image table, and the entire logic program executes against that one frozen snapshot for the rest of the scan. Physical input terminals are not re-read mid-scan — the next read happens only when the next scan begins.
The logic sees the old value — whatever was captured at the start of that scan — for the entire remainder of the scan, regardless of when the physical change actually happened. The new value only becomes visible to the program at the next scan's read phase.
If a pulse rises and falls entirely within the gap between two consecutive input reads — shorter than one full scan time — it never coincides with either read instant, so it never enters the input image table at all. From the program's perspective, that input never changed state, even though the physical signal genuinely did.
Either reduce the scan time so the gap between reads is shorter than the shortest pulse you need to catch, or use dedicated high-speed input hardware — interrupt-driven inputs or built-in high-speed counter/latching inputs — that captures a transition independently of the standard read-execute-write scan.
No. Outputs are written to the physical modules once, in the write-outputs phase at the end of the scan, after the entire program has finished executing — not the instant the driving rung evaluates true mid-execution. The output image table holds the pending result until that single write point.
Try our SCADA Studio
More calculators, simulators, and guides for this discipline.