Learn Automation with MINATA #32: PLC Basics and the Scan Cycle — Why the Logic Does Not Run Continuously

PLC Basics and the Scan Cycle: Why the Logic Does Not Run Continuously

A PLC is a programmable controller, but do not picture it as a person watching every sensor and reacting in the same instant. Most PLCs run a scan cycle: read the inputs, execute the program, update the outputs, repeat. Getting this loop right is what lets you write stable logic — and what lets you explain faults that look like "the PLC is slow".

What you will learn

What a PLC does inside a machine panel, and what the scan cycle consists of.
When timers, short pulses and input changes can mislead you.
How to write logic that carries state, is easy to check and is safer.

Where the PLC sits in the system

The PLC takes inputs from pushbuttons, sensors, safety switches and device status. The program decides the outputs: solenoid valves, interposing relays, indicator lamps, drive commands. An HMI, a VFD or an instrument may exchange data with the PLC over a network, but the PLC still needs a correct I/O structure and a correct supply from the very beginning.

Hard-wired circuits do not disappear. The E-stop, the safety interlocks and the electrical protection must be designed from the risk assessment, never handed over entirely to a condition in software.

What happens in one scan

Read inputs: the PLC takes a snapshot of the input terminals into the input image.
Run the program: the ladder, ST or FBD logic executes in the programmed order, working from that snapshot.
Update outputs: the results are written to the output modules.
Background and communication tasks: depending on the PLC, diagnostics, networking and the watchdog run here.

Then the PLC returns to the top of the loop. Scan time depends on the CPU, the number of instructions, the communication load and the tasks — do not take one "default" figure and apply it to every machine. When a sensor changes state for less time than the program can see, the PLC will miss it unless a high-speed input or a pulse-catch function is used.

A conveyor logic example

Say B1 detects a product. The program uses B1 to stop the conveyor, energise a pusher valve for 300 ms, then run again. If you write "B1 ON means valve ON" directly, the valve stays energised for as long as the product covers the sensor. The better approach is to create a rising-edge event, latch a sequence step, and use a timer for the interval you actually want.

The habit worth keeping is this: inputs are observations, a state variable says which step the machine is on, and outputs are the result of that step. That way an input that stays ON does not make the machine repeat an action nobody asked for.

What must be designed together with the scan cycle

Short pulses: use high-speed inputs, interrupts, or stretch the pulse in hardware or with a PLC function when needed.
Timers: do not treat a software timer as an exact clock; account for the scan and the resolution.
Program order: the same bit written in several places depends on scan order. One output should have one clear place where it is decided.
Restart: define the safe state when the PLC is powered up again; the machine must not start simply because an old bit was retained.
Watchdog and I/O faults: decide what happens when a module or a network link fails.

A worked engineering situation

In a pick-and-place station the PLC can use a part sensor to move from "waiting" to "clamping", use an end-of-travel signal to move to "lifting", and energise valves only according to the current step. Every step needs an entry condition, a completion condition, a timeout and a fault response. That structure is far easier to trace online than a pile of overlapping conditions.

Scan figures, fast inputs, timeouts and start-up modes have to be confirmed against the actual PLC, the actual devices and the real risk assessment.

PLC basics checklist

[ ] Inputs, outputs, safety signals and communication are listed explicitly.
[ ] Any pulse shorter than the scan time has been identified.
[ ] Every actuator has a state, a timeout and a way out on fault.
[ ] No output is written in scattered places across several networks.
[ ] Behaviour after power loss and restart has been tested.

Understanding the scan cycle is the step from "writing instructions until it runs" to designing a control system that behaves predictably. The next post goes into PLC inputs and the PNP/NPN choice.

Read more automation knowledge at MINATA: https://minatavn.com/en/blog/industrial-automation

Previous — #31: The connection diagram and the terminal schedule: https://minatavn.com/en/blog/automation-31-wiring-diagram-terminal-schedule

Next — #33: PLC inputs, PNP and NPN: https://minatavn.com/en/blog/automation-33-plc-inputs-pnp-npn

View all MINATA technical articles