Understanding the PLC Scan Cycle: Why Rung Order Matters

Here's something that trips up even technicians with a few years of experience: a PLC doesn't execute your program the way you might imagine — all rungs "running at once," reacting instantly and simultaneously. It executes in a strict, repeating loop, top to bottom, over and over, many times a second. Understanding that loop explains a lot of behavior that otherwise looks like a mystery.

The Three-Phase Loop

Every scan cycle, broadly, does three things in order:

1. Input scan

the PLC reads the current state of all physical inputs and stores them in an input image table (a snapshot, essentially a memory copy of what the field looked like at that instant).

2. Program execution

the PLC executes every rung, top to bottom, left to right, using that snapshot of inputs. Any changes to outputs during this phase are written to an output image table, not directly to the physical field yet.

3. Output scan

the PLC updates the actual physical outputs to match the output image table all at once.

Then it repeats. On modern PLCs this whole cycle might take single-digit milliseconds for a modest-sized program, but it's still a loop, not instantaneous parallel execution — and that distinction matters more than people expect.

Why This Explains "Weird" Behavior

Because inputs are only read once per scan (at the start), if a physical input changes state in the middle of program execution, the PLC won't see that change until the next scan starts. For almost everything you do, this happens so fast it's irrelevant. But for very short pulses — faster than the scan time — the PLC can genuinely miss them entirely. This is one real-world reason ultra-fast pulse counting sometimes needs dedicated high-speed counter hardware or interrupt-driven logic rather than standard ladder scanning.

Why Rung Order Actually Matters

Because the program executes top to bottom within a single scan, a rung further down can use the result of a rung above it from the same scan — but a rung above can only see results from the previous scan for anything below it. This is called scan-order dependency, and it's exactly why the order you write your rungs in isn't just cosmetic.

Practical example:

If you have a rung that sets a "Permissive OK" bit based on several conditions, and a second rung further down that uses that Permissive bit to allow a motor start, this works fine — the permissive is calculated first, then used. But if you accidentally reversed the order — motor start logic above, permissive calculation below — the motor start rung would always be working with last scan's permissive value, one scan behind. Usually harmless because scans are so fast, but in certain timing-sensitive interlock chains, this lag is exactly the kind of thing that causes intermittent, hard-to-reproduce faults.

Field Tip: When "It Works Sometimes" Really Means Timing

If you're chasing an intermittent fault that seems to happen only occasionally, and normal signal-level checks (wiring, sensor health, noise — like the Allen Bradley DI card faults we covered from motor-start transients) come back clean, consider whether it's a scan-timing issue: a race condition between two rungs, or an input event faster than the scan can reliably catch. These are rare compared to wiring and sensor faults, but they're real, and they're worth ruling in or out once the obvious causes are exhausted.

Why This Matters for You as a Technician

You don't need to calculate scan times by hand to be good at this job. But understanding that the program runs top-to-bottom, once per loop, using a snapshot of inputs — rather than reacting instantly and continuously — will change how you read unfamiliar ladder logic. You'll start asking "what order does this actually execute in" instead of assuming everything happens all at once, and that question alone solves more mystery faults than you'd expect.

Next in the series:

motor start/stop circuits — tracing the full journey from old-school relay panels to modern ladder logic, and why understanding the relay heritage still makes you a better PLC troubleshooter today.

Recent & Popular Articles

🔗 Related Articles You Might Find Useful

📘 Want to Go Deeper? Check Out My Guides

I've put together practical, field-tested resources for exactly the topics I write about here. No fluff — just what you need on the job.

Industrial Instrumentation Fundamentals — Interactive Course
6 modules, 30 interactive lessons built from 25 years of real field experience →

Electrical Fundamentals for Beginners — Interactive Course
5 modules, 30 animated lessons — a genuinely solid foundation before advanced work →

🎥 Watch It Explained on PLC Key Channel

Prefer video? I break down topics like this with animations on my YouTube channel.

▶ Watch the full playlist on PLC Key Channel →

🛠️ Tools I Actually Use in the Field

A few affiliate links to tools that come up constantly in instrumentation work — I only list things I'd recommend to my own team:

Digital Multimeter (Fluke-class) — for loop checks and voltage/continuity testing
Clamp Meter — quick current checks without breaking the loop
4-20mA Loop Calibrator — essential for transmitter and I/O card checks
Insulation Resistance Tester (Megger) — for motor and cable health checks

As an Amazon Associate I earn from qualifying purchases. It doesn't cost you anything extra.

Got a specific instrumentation problem you're stuck on? Drop it in the comments — I answer based on real plant troubleshooting, not textbook theory.

industrial instrumentation basics

Search This Blog