Execution order and the one-scan delay

The Core Idea

The order of instructions affects which value a program reads. Reading a tag before the instruction that updates it can use a value from an earlier scan, even when both instructions run in the same cycle.

What you will learn

  • Why the programmable logic controller (PLC) runs rungs in order, top to bottom, every scan.

  • How reading a bit before another rung writes it causes a one-scan delay.

  • How reordering the rungs removes that delay.

Why it matters

A one-scan difference can be difficult to see while a machine runs. Following reads and writes in order makes the delay explainable.

The problem

A Request pushbutton turns on an indicator lamp — but not directly. It goes through an internal memory bit in between.

SignalMeaning
REQUEST_PBTRUE while the Request pushbutton is pressed.
REQUEST_MEMAn internal bit that copies the button.
LAMPTRUE turns the indicator lamp on.

The program has two rungs, run top to bottom every scan. In this version the lamp rung is on top, above the rung that updates memory:

  1. REQUEST_MEM → LAMP

  2. REQUEST_PB → REQUEST_MEM

A real scan takes milliseconds — far too fast to watch — so the demo below is slowed way down for learning, running one scan every two seconds. Press Request and watch how the lamp responds.

See it go wrong

Predict first: when you switch Request on, does the lamp come on right away, or is something off? Hold your guess, then switch REQUEST on and watch MEMORY and LAMP. Be patient — each scan is two seconds.

Memory turns on one scan after you press Request, and the lamp lags one scan behind that. It feels sluggish, and nothing is broken — the rung order is doing it. The lamp rung runs first, reads the memory bit before it has been updated this scan, and sees last scan's value. The memory rung updates the bit a moment later, but the lamp rung has already run. Only on the next scan does the lamp catch up.

See it go right

The fix is just to run the writer before the reader. In the program below, drag the memory rung (REQUEST_PB → REQUEST_MEM) above the lamp rung, then press REQUEST and watch again.

Now memory and lamp turn on together, in the same scan. Because the memory rung runs first, the lamp rung reads the value it just wrote — no delay. A lower rung can always use a bit a higher rung set this scan; a higher rung can only see what a lower rung wrote on the previous scan.

What happened and why

The PLC executes rungs in order and each rung sees the values as they stand at the moment it runs. A rung that reads a bit before another rung writes it gets the value left from the previous scan — a one-scan delay. Put the writer first and the reader sees the fresh value in the same scan. The delay comes entirely from read-before-write order, not from any built-in wait between rungs. This is why the order of rungs can change how a program behaves, not just how it reads.

Common mistakes

  • Assuming the logic all happens at once. Cause: treating the whole execute phase as simultaneous. Symptom: expecting the lamp to respond immediately regardless of rung order. Fix: read the rungs top to bottom and update each value as its coil runs.

  • Assuming rung order never matters. Cause: thinking two rungs produce the same result in either order. Symptom: a one-scan delay you did not expect. Fix: when one rung writes a bit another reads, put the writer first.

Enable JavaScript to run the embedded simulator and complete the interactive exercises.