How PLC Scan Cycles Work: Complete Technical Guide

Every PLC runs in a continuous loop called the scan cycle. Understanding how this cycle works is fundamental to writing correct PLC programs — especially when timing matters.

What is a Scan Cycle?

A PLC doesn't execute your program line by line in real-time the way a desktop computer runs software. Instead, it repeats a fixed sequence over and over, thousands of times per second:

1. Input Scan: Read all physical inputs into memory
2. Program Execution: Execute the entire user program from top to bottom
3. Output Scan: Write all output values from memory to physical outputs
4. Housekeeping: Communication, diagnostics, self-checks

This complete cycle typically takes 1–50 milliseconds depending on program size and PLC hardware. The time it takes is called the scan time.

Phase 1: Input Scan

The PLC reads every physical input (sensors, switches, encoders) and stores their current state in an input image table in memory. This happens all at once, creating a snapshot.

Key point: during program execution, your code reads from this snapshot — not directly from the physical inputs. Even if a physical input changes mid-scan, your program sees the state captured at the start of the scan.

This is by design. It ensures consistency: every rung in your program sees the same input state, preventing race conditions where rung 1 sees a sensor ON but rung 50 sees it OFF because it changed between those two rungs executing.

Phase 2: Program Execution

The PLC executes your entire program from the first instruction to the last. In Ladder Logic, this means evaluating every rung from top to bottom, left to right. In Structured Text, it means executing every statement in order.

Important behaviors:

• Top-to-bottom: Rung 1 executes before Rung 2. If Rung 1 changes a tag that Rung 2 reads, Rung 2 sees the updated value within the same scan.
• Internal tags update immediately: Changes to internal variables are visible to subsequent rungs in the same scan.
• Outputs write to the output image table: Physical outputs don't actually change during program execution — they're updated in the output scan phase.

Phase 3: Output Scan

After the entire program executes, the PLC writes the output image table to the physical output modules. Only now do motors start, valves open, and lights turn on.

This means if your program turns an output ON in Rung 5 and OFF in Rung 50 within the same scan, the physical output will only ever be OFF — because only the final state at the end of program execution gets written to hardware.

Phase 4: Housekeeping

Between scans, the PLC handles:

• Communication with HMIs, SCADA, and other PLCs
• Updating timers and counters
• Running diagnostics and watchdog checks
• Handling interrupts (if configured)

Scan Time: Why It Matters

Scan time is the total time for one complete cycle. Typical values:

• Simple programs (100 rungs): 1–5 ms
• Medium programs (1000 rungs): 5–20 ms
• Large programs (5000+ rungs): 20–100 ms

Why this matters:

• Missed inputs: If a sensor pulse is shorter than your scan time, the PLC might miss it entirely. A 2ms pulse won't be seen if your scan time is 10ms.
• Response time: The worst-case response from input change to output change is approximately 2× scan time (input changes just after input scan, must wait for next full cycle).
• Timer accuracy: Timer resolution is limited by scan time. A 1-second timer in a 50ms scan program has ±50ms accuracy.

What Affects Scan Time

• Program size: More instructions = longer execution time
• Instruction type: Math operations take longer than simple contacts/coils
• I/O count: More modules to scan = longer input/output phases
• Communication load: Heavy HMI polling increases housekeeping time
• Conditional execution: Code that doesn't execute (false subroutine calls) still contributes minimally

How to Optimize Scan Time

1. Use subroutines with conditional calls: Only execute code when needed (e.g., don't run the heating routine when in cooling mode)
2. Avoid unnecessary math: Pre-calculate constants, don't recalculate every scan
3. Use high-speed counters for fast inputs: Hardware counters catch pulses between scans
4. Separate fast and slow logic: Put time-critical code in a periodic task with a shorter cycle time
5. Minimize remote I/O: Distributed I/O adds network latency to the scan

Periodic Tasks and Event Tasks

Modern PLCs support multiple task types beyond the continuous scan:

• Continuous task: The default scan cycle. Runs as fast as possible.
• Periodic task: Runs at a fixed interval (e.g., every 10ms). Used for time-critical control like PID loops.
• Event task: Triggered by a specific event (input change, timer, communication). Used for interrupt-driven responses.

Common Scan Cycle Bugs

• One-scan pulse missed: Setting an output TRUE and FALSE in the same scan — the output never physically activates.
• Race conditions: Relying on rung order for timing rather than using proper interlocks.
• Watchdog timeout: Program takes too long → PLC faults. Usually caused by infinite loops in Structured Text.
• Input bounce: A mechanical switch bouncing faster than scan time appears as multiple transitions.

How Plaxio Simulates Scan Cycles

Plaxio's built-in simulator models the scan cycle faithfully. It executes your program in the same input→execute→output sequence, with configurable scan time. You can:

• Watch tags update in real-time as the scan executes
• Step through scans one at a time for debugging
• Toggle inputs between scans to test edge cases
• Verify timer behavior matches expected scan-time accuracy