The Scan Cycle

A PLC does not run your program once. It runs it over and over, in a fast loop called the scan. Understanding that loop explains almost everything about when an output changes — and it works the same whether you write in Ladder Logic or Structured Text.

The loop

Each scan, the PLC does three things in order:

1. Read all inputs into memory.
2. Evaluate your whole program, top to bottom.
3. Write all output results out.

Then it starts again — typically many times a second. In rungs.dev, Start uses a configurable scan period, which is 100 ms by default. If the browser runs a scan slightly late, Studio keeps its simulated time aligned to that schedule, so the small delay does not change timer values.

Studio automatically pauses the simulation when you switch to another browser tab. It resumes when you return only if switching tabs caused the pause. If you clicked Pause yourself, it stays paused.

Because the entire program is re-evaluated every scan, outputs always reflect the latest inputs. There is no "stuck" logic: an output turns off automatically the moment its condition becomes false — unless you deliberately latch it.

Scans and timer time

Scan order decides when an instruction gets a chance to update. A timer measures the simulation time between the times its instruction runs.

The first scan that starts a timer adds no time. A new TON or TOF starts at .ACC = 0; a retentive timer resumes at its held value. Each later scan measures the time since that timer last ran.

A timer can only finish when its instruction executes. With 100 ms scans, .PRE = 2000 can finish exactly at 2000 ms. .PRE = 2050 finishes at the next sampled time, 2100 ms, and keeps that value instead of being forced back to 2050.

Before the first scan

When a program starts — on a real controller, the moment you switch it to Run — the PLC makes one preparation pass before the first scan. Rockwell® controllers call it prescan, and rungs.dev mirrors it. Your logic does not run yet; instead, every instruction is put into a known starting state:

• Timers enter their startup state. In Ladder Logic, a TON starts from 0, a TOF starts timed out with .ACC = .PRE and .DN = 0, and an RTO retains its accumulated value. A Structured Text timer sets its visible members the first time its instruction runs.
• One-shots and counters treat the starting inputs as already seen. An input that is already on when the program starts is not a new event — nothing fires and nothing counts until that input goes off and comes on again.
• Your rungs and assignments write nothing. Outputs simply start from their tag values, and non-retentive coils (OTE) start off.

That second rule is the one to remember, because it protects real machines: a line powering up with a part already sitting on a sensor must not count that part as a fresh arrival. If your logic needs to react to "already on at startup", read the level (XIC) instead of an edge (ONS, a counter).

In rungs.dev, prescan runs every time you press Start in the simulator, and at the start of every test case.

Top to bottom, every scan

Step 2 — "evaluate top to bottom" — is the part that surprises people. The PLC works through your program in order:

• In Ladder Logic, it solves rung 0, then rung 1, then rung 2, and so on.
• In Structured Text, it runs the first statement, then the next, down the routine.

As it goes, it updates the bits each rung or statement writes, and everything below sees those updated values right away. Everything above has already run for this scan, using the values from before.

Later wins

One direct consequence: if two places write the same output, the last one to run wins, because its write is the one that survives to the end of the scan.

• In Ladder Logic, the lower rung wins.
• In Structured Text, the later statement wins.

The fix is the same in both: drive each output from exactly one place.

When a scan stops early

Some mistakes are serious enough that a real controller does not shrug them off — it raises a major fault and stops executing. rungs.dev mirrors this when your program reads or writes an array with an index that is out of range, divides by zero inside an index, or runs a Ladder timer when its negative preset is needed. The scan stops at that instruction. Everything before it in the scan stays applied; everything after it does not run, and the value being written is left untouched. The fault appears in the status panel naming what went wrong, and a test scan that faults fails its test case — the same way the loop watchdog works. Structured Text timers report an invalid preset in their status members instead of stopping the scan.

This is deliberate: on a plant floor a fault like this halts the machine, so the simulator treats it as a bug to fix, not a value to work around.

Why order matters more than it looks

"Later wins" is the easy case — two writes to the same bit. The subtler case is when one rung or statement reads a bit that another one writes. Then the order decides whether the read is fresh or a scan old — and an output can end up changing one scan early or late even though the logic looks correct.

That is the next page: Scan Order and One-Scan Delays.

Summary

• A PLC runs your program in a loop: read inputs, evaluate top to bottom, write outputs, repeat.
• Before the first scan, a prescan pass prepares timers and arms one-shots and counters — an input already on at startup never fires an edge.
• Timers measure the time between instruction runs instead of adding a fixed amount per scan. They can finish only when their instruction runs.
• Rungs (Ladder) and statements (Structured Text) both run top to bottom, every scan.
• If two places write the same output, the later one wins — drive each output from one place.
• The order in which things run decides the timing of your outputs, not just the logic.