LADX
Start free
← Resources
Fundamentals·7 min read·

What actually happens in one PLC scan

Read inputs, solve logic, write outputs, repeat. Plus the three details in that sentence that cause most of the bugs beginners write.

Short answer

A PLC repeats four steps forever: it copies every physical input into memory, solves the program top to bottom, writes the output image to the terminals, then does housekeeping. On a modern controller that loop takes one to twenty milliseconds. Three consequences follow: a pulse shorter than one scan is invisible, outputs do not change mid-scan, and rung order decides what sees what.

PLC scan cycleRead inputsSolve logicWrite outputsHousekeepingRepeat1-20MILLISECONDS

A PLC does the same four things forever: it reads its inputs, solves the program top to bottom, writes its outputs, and does its housekeeping. Then it starts again.

That description is in every textbook, and it is correct. It is also where most beginner bugs come from, because three details inside it are easy to skim past and impossible to work around once you have.

Inputs are a photograph, not a window

At the start of the scan, the controller copies the state of every physical input into memory. That copy is the input image, and your program reads it rather than the terminal.

So if a proximity sensor pulses high and low again in the middle of your scan, your program never sees it. Not 'might miss it': cannot see it. The photograph was taken before the pulse and will not be retaken until the next scan.

This is why a fast pulse needs a high-speed counter input rather than a contact in your ladder. The counter has its own hardware that does not wait for your scan.

Outputs are written at the end

The same thing happens in reverse. When your coil energises, it sets a bit in the output image. The physical terminal does not change until the end of the scan, when the whole image is written out at once.

For internal bits this rarely matters. For a rung that reads an output written by a *later* rung, it matters enormously, which brings us to the third detail.

Rung order is real

The program is solved top to bottom. A coil on rung 12 that sets Motor_Run is visible to a contact on rung 13 in the same scan, because rung 13 has not been solved yet.

A contact on rung 4 reading that same bit sees the value from the *previous* scan, because rung 4 was already solved before rung 12 wrote anything.

This is the single most common source of 'but it should work'. The logic is right. The order is wrong. Moving one rung above another fixes it, and nothing about the rung itself changed.

How to see it happen

Reading about a one-scan delay is not the same as watching one. Most teaching simulators solve rungs like a system of equations, so this behaviour never appears and students arrive at a real controller with a mental model that has never been contradicted.

The simulator in LADX Studio keeps the output image, so a backward reference lags by exactly one scan the way it does on a real PLC. Build the two-rung case above, press Run, and watch the second rung catch up one sweep late.

Common questions

How long is a typical PLC scan?
One to twenty milliseconds on a modern controller, depending on program size and processor. Small programs on fast CPUs run under a millisecond. The figure that matters is not the average but the worst case, because that sets the shortest signal your program can reliably see.
Why does my PLC miss a fast input pulse?
Inputs are sampled once per scan into the input image. A pulse that goes high and low again between two samples never appears in memory, so the program cannot see it. Signals shorter than one scan need a high-speed counter or an interrupt input, not ladder logic.
Does rung order matter in ladder logic?
Yes. The program solves top to bottom, so a coil on rung 12 is visible to a contact on rung 13 in the same scan, but a contact on rung 4 reads the value from the previous scan. Moving a rung can fix logic that looked correct.

Keep reading