How to Use PLC Scan-Cycle Highlight to Debug Ladder Logic Faster

Professional PLC programmers debug faster than beginners for one reason: they do not guess. They observe the exact state of every bit, every contact, and every coil at the exact moment the logic fails. Scan-cycle highlight is the tool that makes this possible.

This guide explains what scan-cycle highlight shows you and, more importantly, how to use it systematically to find bugs — not just notice them.

What Scan-Cycle Highlight Shows You

When the scan-cycle highlight is active, the simulator overlays each rung with live state information as the virtual processor evaluates it:

• Contact state — each contact is marked TRUE (conducting) or FALSE (blocking), updated to the input image table snapshot taken at the start of this scan
• Rung result — whether the complete input condition on the rung evaluated to TRUE or FALSE
• Coil state — whether the output coil was energised (TRUE) or de-energised (FALSE) this scan
• Timer/counter values — the accumulator and done bit of any timer or counter on the rung

In slow mode, the processor pauses after evaluating each rung and waits for you to advance manually. This gives you unlimited time to inspect the state of every element before the next rung executes.

The highlighter steps through the same four phases the processor runs on every scan, so it helps to know which phase you are watching.

Logic only runs in the second phase, and outputs only physically change in the third. That ordering is what produces most of the bugs below.

Because the input image is latched at the very start of the scan and the coil is only written to the output image partway through the logic phase, a coil energises within a single scan like this:

This is exactly what each highlighted rung is showing you in miniature. A typical seal-in rung — a Start contact, a normally-closed Stop, and a Motor coil — is marked true or false as the processor reaches it:

Enabling Slow Mode

1. Open any scenario or curriculum lesson in the simulator
2. In the toolbar at the top of the editor, click the Scan button (or use the keyboard shortcut Shift+S)
3. Choose Slow from the mode selector
4. Click Run — the scan begins and pauses after the first rung
5. Click Step to advance one rung at a time, or Continue to run to the next scan

The current rung is highlighted in yellow as it executes. After evaluation, it turns green (result TRUE) or stays dimmed (result FALSE).

Case Study 1: Diagnosing a Rung-Order Bug

Symptom: Y0 (motor output) does not respond immediately when X0 (start button) goes TRUE. It activates one scan later.

How to find it with slow mode:

1. Press start, then step through the scan rung by rung
2. Find the rung that sets M0 (the seal-in bit): LD X0 → OUT M0
3. Note which rung number this is — say, rung 7
4. Now look for the rung that reads M0 to energise Y0: LD M0 → OUT Y0
5. If the Y0 rung is numbered above (before) the M0 rung — say, rung 3 — then rung 3 runs before rung 7. In the current scan, M0 is still FALSE when rung 3 evaluates it. Y0 only turns on in the next scan.

Fix: Move the M0 consumer rung (Y0 coil) to a rung after the rung that sets M0. Now in the same scan where X0 goes TRUE, M0 is set on rung 7, and rung 8 (the Y0 coil) reads it as TRUE in the same scan.

This is documented in Top 5 PLC Programming Mistakes as Mistake #2.

Case Study 2: Diagnosing a Timer Bug

Symptom: The motor starts 500ms after the start button is pressed instead of 5 seconds.

How to find it with slow mode:

1. Enable slow mode and step through until you find the timer rung
2. Watch the timer accumulator value in the overlay — it counts in display units, not real time
3. Check what units the preset is in: is it K50 (50 × 100ms = 5s) or K50 on a 10ms resolution timer (50 × 10ms = 500ms)?

In Mitsubishi dialect, T0–T199 are 100ms resolution; T200–T255 are 10ms resolution. If you used T200 instead of T0 with K50, your timer runs in 500ms instead of 5 seconds.

Fix: Change the timer device number to the correct resolution range, or recalculate the preset: for a 5-second delay on a 10ms timer, use K500 (500 × 10ms = 5s).

For IEC/AB timers, verify the preset format: T#5S means 5 seconds; T#5000MS also means 5 seconds. But PRE: 5 on a legacy SLC timer means 5 × 10ms = 50ms, not 5 seconds.

Case Study 3: Diagnosing a Latch Coil That Will Not Reset

Symptom: The motor stays running after the stop button is pressed.

How to find it with slow mode:

1. Step through the scan, looking for the SET/OTL coil that energised the motor
2. Check if there is a matching RST/OTU rung anywhere in the program
3. If the RST rung exists, check its input condition: is Stop_PB being evaluated as XIC (normally-open) or XIO (normally-closed)?

A common bug: the stop button is wired normally-closed (NC), so it reads TRUE (24V present) when not pressed. The RST rung has XIC Stop_PB — which reads TRUE all the time the button is not pressed. But when you press the stop button, the circuit opens, the input reads FALSE, and the RST rung becomes FALSE — which means the RST coil de-energises. A de-energised RST coil does not reset; only a TRUE RST coil resets.

Fix: Change XIC Stop_PB to XIO Stop_PB on the reset rung. Now the RST rung is FALSE while the button is not pressed (no reset), and TRUE when the button is pressed (reset fires).

Case Study 4: Finding Which Rung Is Holding a Fault Latch

Symptom: The machine is in fault state and cannot be reset. Operator pressed the fault-reset button; nothing happened.

How to find it with slow mode:

1. Look for the fault coil in the scan — it should be a latch coil (OTL or SET)
2. Verify the reset coil (OTU or RST) exists and evaluate its rung condition
3. Look for any additional interlock contacts that might be holding the fault state

In many programs, a fault can only be reset if: (a) the fault cause has cleared AND (b) the reset button is pressed. If the fault cause is still present (the sensor is still blocked, the pressure is still high), the reset will not work regardless of how many times the operator presses the button. The scan-cycle highlight will show you that the reset rung's input condition is FALSE because of the fault cause contact, not the reset button.

Systematic Debug Protocol

When a machine misbehaves and you cannot see why, use this protocol:

1. Enable scan-cycle highlight in live mode — observe the output state of the failing element
2. Find the output coil that should control the failing element — is it TRUE or FALSE?
3. If coil is FALSE: step upstream. Find the input rung for that coil and look at each contact — which contact is blocking the rung?
4. Trace that contact's source bit — is it driven by a field device? A timer? A latch coil? Another rung?
5. If coil is TRUE but output not energised: the problem is outside the PLC program (wiring, output card, field device)

This is the same method field engineers use with connected hardware. The simulator lets you practise it risk-free.

Run through enough scans this way and you start recognising the same handful of problems on sight — these are what scan-cycle highlight trains you to spot:

For a deeper dive into the scan cycle itself, read The PLC Scan Cycle Explained. To practise debugging with injected faults, try the fault diagnosis module.

---

Practise scan-cycle debugging in the simulator — free. Slow mode, step mode, and live highlight available on all plans including Free.

Start the free curriculum →