The PLC scan cycle

A PLC does not “watch” its inputs all the time or react instantly like a relay circuit. It works in rounds: it reads, thinks, acts and starts again, hundreds of times per second. That round is called the scan cycle. Really understanding it is what most separates a good programmer from a bad one: it explains why an output written twice ignores you, why a counter counts too much or why a PLC goes to STOP for no apparent reason.

What the PLC does in each scan

With small differences between manufacturers, every PLC repeats these steps:

1. Read the inputs. The PLC copies the state of all the physical inputs into an area of memory called the process image of the inputs.
2. Execute the program. It runs through the program from top to bottom, network by network, using that copy, not the real inputs. In Siemens PLCs, the main cyclic program is organisation block OB1 (“Main”).
3. Write the outputs. The results the program has left in the process image of the outputs are copied to the physical outputs.
4. Internal tasks. Communications (with the HMI, other PLCs or the computer), diagnostics and self-tests.

And round again. The time a complete round takes is the cycle time (or scan time).

The process image: the program works with a snapshot

Having the program use a copy of the inputs has a huge advantage: during the whole scan, an input has the same value in every network, even if the real sensor changes halfway through. Without it, network 3 could see a part and network 40 not see it, and the program would make contradictory decisions.

The same happens with the outputs, but the other way round: the program writes to the image and the physical output only changes at the end of the scan. That is why, if an output is written in two places, only the last write counts. We will come back to this with the double coil.

The cycle time

A scan normally lasts a few milliseconds, but not always the same: it depends on the CPU, the size of the program, which parts run in that scan and the communications. What you need to know:

• The PLC can take almost two cycles to react. If the input changes just after being read, it will not be seen until the next read, and the output will not change until the end of that scan. On top of that comes the input filter delay, which is usually a few milliseconds.
• There is a cycle time watchdog. If a scan takes longer than the configured maximum (in many Siemens PLCs, 150 ms by default), the PLC raises a time error and may go to STOP. It protects against programs that hang.
• You can check it. Programming tools show the minimum, current and maximum cycle time. Looking at it during commissioning is a good habit.

Signals faster than the cycle

If a signal switches on and off between two input reads, the program never finds out. It happens with very short pulses: an encoder, a sensor watching small parts go by very fast, a pulse from another device. For those cases there are specific solutions:

• High-speed counters (HSC), which count in hardware without depending on the cycle.
• Hardware interrupts, which run a piece of program as soon as a specific input changes.
• Stretching the pulse at the source, or choosing a sensor with a timed output.

What does not work is trying to “read faster” in the normal program: the problem is not the program, it is when the input image is updated.

Order matters: top to bottom

The program runs in order. If a memory bit is calculated in network 10 and used in network 3, network 3 reads the value it had in the previous scan. Often it does not matter, but sometimes it causes one-scan delays or strange behaviour that is hard to spot. Rule of thumb: calculate things before using them, and organise the program in a logical order (first inputs and conditions, then sequences, outputs at the end).

The double coil: the classic mistake

Writing the same output (or the same memory bit) with two coils in different places in the program is a very common mistake. Since the physical output is only updated at the end, the last coil executed wins and the first one is useless. The symptom is baffling: you look at the first network, see that its condition is true, and yet the output does not turn on.

Edges: detecting the change, not the state

A push button stays pressed for many scans. If you use it to increment a counter “while it is 1”, it will count once per scan: hundreds of times in one press. To do something only once per press you use an edge:

• Rising edge (positive): gives a pulse of a single scan when the signal goes from 0 to 1.
• Falling edge (negative): gives a one-scan pulse when it goes from 1 to 0.

To know whether there has been a change, the PLC compares the current value with the one from the previous scan, which it stores in a memory bit belonging to that instruction. That bit cannot be shared between two different edge detections: if two edges use the same memory bit, one of them will stop working.

Loops: the program cannot wait

Another mistake made by people who do not understand the cycle is writing something like this in Structured Text:

WHILE NOT "Part_sensor" DO
    ;  // wait for the part to arrive
END_WHILE;

It looks logical, but while the program is inside the loop the input is not read again: the process image is only updated when the scan ends. The loop never ends, the scan grows until it exceeds the maximum time and the PLC goes to STOP. The right way is to ask in every scan: “has the part arrived? if not, carry on with everything else and look again in the next scan”. Waits are programmed with steps (a sequence) and timers, never with loops.

Timers and the cycle

A timer measures real time, but the program only finds out its state when it executes the timer instruction. That is why the timer instruction must run in every scan: if it sits inside a jump or a block that is not always called, it may not update the way you expect. And a timer is no more precise than the cycle: with a 10 ms cycle, the output of a 1 s timer will be seen with an error of up to one scan.

Start-up, STOP and retentive memory

• When going to RUN, a start-up block runs first (in Siemens, a Startup OB such as OB100) where values are initialised. Then the normal cycle begins.
• In STOP, the outputs go to a defined state, normally 0. The machine must be designed so that this state is safe.
• Retentive memory: variables marked as retentive keep their value after a power cut (for example, a part counter). Non-retentive ones go back to their initial value.

Typical mistakes that give away someone who does not understand the cycle

• Writing an output in two networks (double coil).
• Counting or triggering actions on the level of a signal instead of its edge.
• Reusing the same memory bit for several edges.
• Waiting inside a loop for an input to change.
• Using a memory bit before calculating it without understanding the one-scan delay.
• Expecting the normal program to catch pulses shorter than the cycle.
• Never looking at the cycle time, not even during commissioning.

Summary

• The PLC reads inputs, runs the program top to bottom, writes outputs and does its internal tasks, in a loop.
• The program works with a copy of inputs and outputs (process image): consistency within each scan.
• If an output is written twice, the last write wins. One output, one coil.
• Edges give a single-scan pulse and need their own memory bit.
• Never wait in a loop: the scan gets longer, the watchdog trips and the PLC may go to STOP.
• For signals faster than the cycle: high-speed counters or interrupts.