The PLC scan

The Core Idea

A programmable logic controller (PLC) scan is a repeated cycle of reading inputs, executing the program, and updating outputs. Following that cycle helps you distinguish a change at a field device from the program's observation and response.

What you will learn

• Name the three parts of a scan: read inputs, execute the program, and write outputs.

• Predict which completed scan changes an output when a field input changes.

• Step whole scans in the Ladder example, then step individual phases to see what happens when a field input changes after the read.

Why it matters

Timing and memory make more sense when you know which stage of the cycle you are examining. A changing input and its output response are separate events.

The problem

An operator turns a maintained Request switch on to light an indicator. There is one rung: a normally open contact for REQUEST_SWITCH drives an ordinary output coil for LAMP.

The program repeats a three-part scan. First it reads inputs, taking a snapshot of the switch. Next it executes the program, calculating the lamp command from that snapshot. Last it writes outputs, sending the command to the lamp. Then the next scan begins. Here, each complete step represents one 100 ms scan. Read, execute, and write are parts of that one scan, not three separate scans.

Predict

Pause with Request off and Lamp off. Turn Request on while paused, then press Step one scan once. What will the lamp show at the end of that step?

Pause the example. If Lamp is already on, turn Request off and step once to clear it. Turn Request on while still paused. Notice that the switch/input display changes but the lamp stays off until you step. After the step, read the completed phase checklist and the LAMP value.

Try it

Use the demo above for a second prediction: with Request on and Lamp on, Pause, turn Request off, and predict the result of exactly one step. Step once. LAMP should become FALSE at the end of that scan. Turn Request on again and step once; it should become TRUE. Try Run briefly, then Pause. Running repeats the same steps automatically, which makes the three phases too quick to distinguish by eye.

Look closer

The scan stepper reports values after a completed scan. Trace one switch-on step this way:

The Ladder example exposes the switch's new input value while paused so you can choose what the next whole-scan step will read. Its phase checklist appears after the whole step. To inspect the boundary inside a scan, use the phase model below.

First reset the model, turn the field switch on, and step Read, Execute, and Write. The lamp changes only at Write. Then reset again, step Read while the switch is off, turn the field switch on, and finish Execute and Write. The current scan still uses the earlier snapshot. Step through the next scan and watch when the lamp finally turns on.

This stepper uses the same rung, switch, lamp, and power flow as the example above, so the field input, the sampled input image, the program's output image, and the physical output are all visible at once.

Change it

Open this guided version. Its single contact starts as normally closed, so the lamp does the opposite of what the operator requested. Pause, turn Request off, and step: the lamp comes on. Change the contact to normally open. With Request off, step once and check Lamp off. With Request on, step once and check Lamp on. The input read and output write sequence is the same; the contact's result during execution changed. (New to switching contact types? NOT Logic: Negated Contacts is a quick refresher.)

Show the guided change

Use one normally open REQUEST_SWITCH contact followed by one ordinary LAMP output coil. When a scan reads Request TRUE, the contact passes power and the output write turns the lamp on. When a later scan reads FALSE, the coil writes FALSE and the lamp turns off.

Check yourself

Build the same requirement from an empty program: the lamp must follow Request at the end of the first scan that reads each new switch position. In the editor, add the contact and output coil, then use the switch and Step one scan to check both directions before running Validate. The checks include Request already on at the first read and repeated on/off changes. Retry as often as you need.

Hint 1

What should a rung read to decide whether the lamp is on after this scan?

Hint 2

The rung needs a contact that is true when REQUEST_SWITCH is TRUE, followed by one coil that writes LAMP.

Hint 3

Use a normally open REQUEST_SWITCH contact and an ordinary LAMP output coil on one rung.

Show the worked solution

One rung with a normally open REQUEST_SWITCH contact followed by an ordinary output coil for LAMP passes. The contact reads the sampled input during execution, and the coil's result is sent to the lamp during output write. An equivalent program with the same behavior also passes the checks.

What happened and why

The scan turns a field change into an output change in a predictable order: read → execute → write. A switch position available at the read can affect the output at the write of that same scan. A change that arrives after the read waits for the next scan's input sample. The controller repeats this cycle, so the exact arrival time relative to input sampling matters when diagnosing an apparently late response.

Stepping is useful because it separates completed scans you can inspect. For a real machine, scan duration, input modules, and output modules also affect timing; this lesson's 100 ms step is a teaching model, not a guarantee about a particular controller.

Common mistakes

• Expecting the lamp to change during Pause. Cause: confusing a changed field switch with a completed program scan. Symptom: the switch display changes while Lamp keeps its old value. Fix: step once and inspect the output after the write phase.

• Counting three scans for three phases. Cause: treating read, execute, and write as separate cycles. Symptom: predicting a third-step lamp response. Fix: trace all three phases inside one step.

• Using the inverted contact. Cause: choosing a normally closed contact for an on-when-requested lamp. Symptom: Lamp is on when Request is off. Fix: use a normally open contact, then step with Request in each position.

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