Understanding Scan Cycles

PLC code starts making sense once you understand the loop that reads inputs, solves logic, and updates outputs, and then how cyclic, interrupt, event, and async behaviour sit on top of it.

Most PLC concepts get easier once the scan cycle clicks. Timers make more sense. Interlocks make more sense. Troubleshooting becomes more structured. Even more advanced topics like state machines sit on top of the same foundation.

A lot of people learn tags, contacts, coils, timers, and function blocks before anyone explains the part underneath all of it. A PLC does not run your program once and then wait for a new event. It cycles continuously, checking the world, solving the logic, and then updating outputs.

That repeated routine is the scan cycle. It is not something you can gloss over. It is a fundamental part of the PLC’s operating architecture, and once you understand it, a lot of industrial control behaviour starts to feel very predictable.

How Your PLC Scan Operates

At a practical level, your PLC is looping continuously:

• It reads the status of its inputs.
• It executes the program.
• It writes the state of its outputs.
• It starts again.

That loop continues whether your machine is busy, idle, or faulted.

I often describe it like a security guard making rounds. First, the guard checks all the doors and sensors. Then they decide what action to take based on the rules they’ve been given. Then they carry out those actions. Then they go round again. They are not reacting to every event in a magical instant. They are checking, deciding, and acting in a very disciplined order.

That order matters. A PLC is deterministic by design. Given the same input conditions and the same program, it should produce the same result every time. This is one of the reasons PLCs are so reliable in industrial environments. They are not general office computers running whatever happens to wake up next. They are built to execute control logic in a repeatable way.

This is also why scan cycles are universal. Siemens, Rockwell, CODESYS, Beckhoff, Schneider, Omron, Mitsubishi, and many others all differ in features and syntax, but the underlying idea remains the same:

• Read the inputs.
• Execute the code.
• Update the outputs.
• Repeat.

Once you start thinking that way, many PLC behaviours that seem confusing at first become obvious. A button press is only seen when the PLC reads the input. A timer only advances as the PLC keeps scanning. An output only changes when the scan reaches the point where outputs are updated. The controller is always working from snapshots taken at high speed, not from an infinitely smooth awareness of the real world.

The Three Main Phases Of A Scan Cycle

Different platforms add their own details, but the classic scan cycle has three main phases.

First, the PLC reads inputs. Digital and analog input values are collected from the real hardware and copied into memory. This memory area is often called the input image table or process image, depending on the platform. The important idea is that the PLC now has an internal copy of the current field conditions.

Second, the PLC executes the program. It solves the logic using those stored input values, not by constantly looking back at the input terminal every line of code. It works through the logic in a defined order. In ladder, that is normally left to right and top to bottom. In structured text, it is the written sequence of the instructions. During this phase, internal bits, timers, counters, and calculated values all update as the program executes.

Third, the PLC writes outputs. Once the logic has been solved, the controller updates the physical output modules. Motors energise, solenoids de-energise, lamps turn on, and analog values get sent out to drives or valves.

Then the next scan begins and the whole process repeats.

That sounds simple, but it explains a lot. Suppose a pushbutton changes state halfway through program execution. In a basic scan model, the program does not suddenly re-run from the beginning with the new value. It keeps solving the current scan using the input snapshot it already took, then it reads the new input state on the next scan.

This is why we say the logic sees a snapshot of the world. If your scan time is 10 milliseconds, the PLC is working with a view of the plant that is refreshed every 10 milliseconds. For many industrial processes, that is more than fast enough. For very fast events, however, that timing becomes extremely important.

// Simplified view of a PLC scan
// 1. Read inputs from hardware into memory
// 2. Execute the program using those stored values
// 3. Write output states from memory to hardware

IF StartPB AND NOT FaultActive THEN
    MotorRunCmd := TRUE;
END_IF;

// If StartPB changes halfway through the scan,
// this line still uses the value read at the start of the scan.

There are platform-specific exceptions in advanced systems such as immediate I/O instructions, hardware interrupts, high-speed counters, fast tasks, and dedicated motion processors. Those are important in the right applications, but they are exceptions added on top of the standard model. For most beginners, and for a surprising amount of real plant logic, the simple three-phase scan model is the correct mental starting point.

Cyclic, Interrupt, And Event Tasks

The classic scan model is the right foundation, but modern PLCs often run more than one task. That is where terms like cyclic, interrupt, and event execution start to matter. They do not replace the scan cycle. They are different ways of scheduling work on top of it.

Cyclic tasks run on a fixed period or continuous loop. A 10 millisecond task might hold your main machine sequence, while a slower 100 millisecond task handles diagnostics, logging, or other housekeeping. Each cyclic task has its own execution time, and the controller keeps trying to run it on schedule.

Interrupt tasks are used when the controller must react faster than the normal cyclic task can guarantee. A hardware edge, a high-speed counter event, or a motion-related trigger can interrupt lower-priority logic, run immediately, and then hand control back. That is why interrupt code is usually kept short. It is there to capture, latch, or react quickly, not to carry half the plant sequence.

Event tasks are triggered because something happened rather than because the next time slice arrived. Depending on the platform, that might be a communication message arriving, a technology object changing state, a rising edge on a variable, or a system event such as startup or fault handling. The key idea is that the task wakes up on demand.

The important interaction is priority. A fast interrupt or high-priority event task can pre-empt a slower cyclic task. When the fast task finishes, the lower-priority task resumes from where it was paused. That is powerful, but it means your PLC no longer has just one neat scan time to think about. It has several execution contexts competing for CPU time.

That is also why two timings matter in real projects: the period of a task and the execution time of a task. You might schedule a cyclic task every 5 milliseconds, but if higher-priority events keep stealing CPU time, the effective response seen by some logic can still move around inside defined limits. Good platforms manage this well, but good engineers still design with it in mind.

If the same tag is written in more than one task, timing starts to matter in a different way. The final value may depend on which task ran last. That is why multi-task PLC programs often use latched flags, queues, or request-and-acknowledge handshakes instead of letting several tasks fight over the same output or state bit.

Why Scan Cycles Matter

The scan cycle is the execution model your code runs inside, so it directly affects how the machine behaves.

Take a basic motor start. You press a start button, the PLC reads that input on the next scan, the logic decides the motor should run, and the output turns on when outputs are updated. That is not a problem because the whole process usually happens in a few milliseconds. To a human operator it feels instant. To the PLC, it is still a sequence.

Now consider a fault input that flickers for 2 milliseconds because of electrical noise. If your PLC scan is 10 milliseconds and the fault comes and goes between scans, the PLC may never see it at all. This is not because the PLC is broken. It is because the signal changed faster than the controller was checking for it.

Or imagine a fast packaging machine where a sensor pulse indicates product position. If that pulse is shorter than the scan time, standard program logic may miss it. That is why high-speed applications often use high-speed counters, interrupt tasks, or dedicated hardware. The normal scan cycle is reliable, but it still has a limit.

On slower processes, the opposite is true. A water treatment plant may have scan times that are much slower than a packaging line, and it can still operate perfectly well because tanks, valves, and pumps usually do not need microsecond decisions. A 20 millisecond or even 50 millisecond scan can be completely acceptable if the process itself moves slowly.

This is the key point: scan time only matters relative to the speed of the process you are controlling. Beginners sometimes hear “faster is better” and assume every PLC should be chasing the smallest possible scan time. In practice, the right scan time is the one that comfortably matches the application while leaving headroom for future changes and maintaining predictable behaviour.

Understanding the scan cycle also improves troubleshooting. When somebody says, “The PLC should have seen that input,” your next thought should be, “How long was the signal present, and how often is the PLC scanning?” That question alone can save a lot of wasted time.

Understanding Scan Time And Building Intuition

Scan time is the amount of time it takes the PLC to complete one full pass through the cycle. If a controller has a 10 millisecond scan time, it is completing 100 scans per second. If it has a 5 millisecond scan time, it is completing 200 scans per second.

That does not mean every part of the program is equally fast in every situation. Complex math, communication traffic, loops, data handling, and extra program blocks all add work. Larger programs usually mean longer scan times. Poorly structured code can make that worse. Platform settings can affect it too, especially when tasks are split by priority or periodic scheduling.

In a simple controller, people talk about the scan time as if there is only one number. In a multi-task PLC there may be several meaningful numbers: a 1 millisecond motion task, a 10 millisecond sequence task, and a 100 millisecond housekeeping task. The better question is often not “what is the scan time?” but “which task is responsible for this behaviour, and how often does that task run?”

Response time is also usually worse than a single task period. A signal may change just after a cyclic task has read its inputs, which means the logic may wait nearly a full period before seeing it. Then the task still has to execute, and the output still has to be updated. Interrupts and event tasks reduce that delay by catching or handling the change earlier, but they also add CPU load and more interaction between tasks.

Higher-priority tasks affect lower-priority tasks as well. If a fast event task fires repeatedly, a slower task may stretch or show jitter. That does not make the controller random. It means determinism now has to be understood per task and priority level, not just as one average scan number for the whole PLC.

What matters for a working engineer is building a feel for the numbers. A 100 millisecond scan means the PLC only refreshes its view of the world 10 times per second. Humans can often notice that if pushbuttons, lamps, or HMI-driven actions feel sluggish. A 10 millisecond scan feels instant to an operator. A 1 millisecond scan is very fast and often used where response time is more demanding.

Think about a sensor pulse that lasts 50 milliseconds. A PLC scanning at 10 milliseconds has a very good chance of seeing that pulse. A PLC scanning at 100 milliseconds may miss it depending on the timing. That simple thought experiment helps you judge whether a signal is likely to be reliable in normal cyclic logic.

Scan time also affects how you interpret timers. A timer is not a magical clock floating outside the program. It relies on repeated scans to evaluate whether its enable condition is still true and whether enough time has passed. PLC timers are accurate enough for industrial work, but they still live inside the real execution behaviour of the controller.

Many systems let you view current, minimum, and maximum scan times online. Make a habit of checking them. If a program used to scan in 8 milliseconds and is now running at 35 milliseconds after a series of modifications, that tells you something important. Even if the plant still runs, you may have less headroom than you think.

Jitter, Minimum Scan Times, And Watchdog Timers

Average scan time on its own is not enough. Jitter, minimum scan time, and watchdog limits tell you just as much about how healthy the execution model really is.

Jitter is variation in when a task actually starts or how long it takes to complete. A 10 millisecond task that normally completes in 10 milliseconds but occasionally stretches to 13 or 14 milliseconds is showing jitter. Interrupts, event tasks, communication bursts, and uneven code paths can all cause it. That matters when your logic depends on consistent timing rather than just acceptable average timing.

Minimum scan time is worth understanding in two ways. Diagnostics often show the minimum observed scan time, which tells you the shortest cycle the controller has achieved under light load. Some platforms also let you configure a minimum cycle time, which stops the PLC or task from running faster than a defined rate. That can make execution more consistent, reduce unnecessary CPU loading, and give background services time to run.

Watchdog timers protect the controller from tasks taking too long. If a task or scan exceeds its watchdog limit, the PLC treats that as a fault condition because something has tied up execution longer than it should. Depending on the platform, that may fault the task, stop the CPU, or log a watchdog event for diagnostics.

The practical lesson is simple. Do not only look at the average scan time. Check current, minimum, and maximum values. Know whether important tasks are showing jitter. Know what the watchdog limit is and how much margin the program still has under worst-case conditions.

If a machine only misbehaves during startup, recipe loads, alarm floods, or communication bursts, this is one of the first places to look. Those are exactly the moments when execution stretches, jitter increases, and watchdog margin disappears.

What Async Means In A PLC

The word async can sound more mysterious than it really is. In PLC work, it usually means the program starts something now, keeps scanning, and then handles the result later when it becomes available.

A communication function block is a good example. You trigger a message to a drive, a remote I/O node, a database, or another controller. The PLC does not freeze the whole machine until the reply comes back. Instead, the block often sets a Busy bit, the rest of the logic keeps running, and a later scan sees Done or Error when the external operation finishes.

That is asynchronous behaviour. The request and the response are separated in time. They may even happen in different tasks. A cyclic task might issue the request, a communication service or background task might process it, and an event task or a later cyclic scan might consume the result.

This does not usually mean a PLC behaves like a free-for-all multithreaded PC program. Most PLC async patterns are still very structured. One part of the system launches work, another part reports status, and your main logic moves on only when it sees a clear handshake such as Busy, Done, Error, Request, or Acknowledge.

// Cyclic task
IF SendRecipeReq AND NOT RecipeBusy THEN
    RecipeStart := TRUE;
    RecipeBusy := TRUE;
END_IF;

// Later scans keep running normally
IF RecipeDone THEN
    ActiveRecipeLoaded := TRUE;
    RecipeBusy := FALSE;
END_IF;

// Background service or event task
// eventually sets RecipeDone or RecipeError

Once you see async that way, it fits naturally into PLC thinking. The PLC is still scanning. The difference is that not every useful action begins and ends inside the same scan. Some actions are requested in one scan, completed somewhere else, and confirmed in a later scan.

This is why handshake design matters so much. If you use async communication, event tasks, or background services, you need clear ownership of tags and clean state transitions. Set a request once. Latch that it is in progress. Wait for done or error. Clear the request deliberately. That discipline keeps asynchronous behaviour deterministic instead of messy.

Common Misunderstandings That Catch Beginners

One common misunderstanding is believing the PLC reacts instantly to every change. In practice, it reacts on the next scan. That is usually very fast, but it is not zero time. The difference matters when you are dealing with short pulses, interlocks that appear to change order, or systems that feel delayed for no obvious reason.

Another misunderstanding is assuming the PLC is constantly reading physical inputs throughout the program. In the basic model, it is not. It reads them into memory first, then solves the program from that stored image. That is why a contact later in the program is generally seeing the same input state that an earlier network saw during the same scan.

People also assume outputs change the instant the coil or assignment line is solved. Logically, the output command may become true at that point in memory, but the physical output is normally updated at the output phase of the scan. That difference is small in time, but important when you are trying to understand execution order.

A related mistake is thinking code execution order does not matter because the PLC is “always scanning anyway.” Order matters a great deal. If one rung sets a bit and a later rung resets it in the same scan, the final result depends on the order of execution. The cyclic nature of the PLC does not remove that. It makes it more important to understand.

Beginners sometimes keep adding logic without ever revisiting performance. Most of the time that works for quite a while. Then one day a sequence becomes unreliable, an HMI update feels slow, or communication timeouts start appearing after a new feature was added. The issue may not be one bad rung. It may simply be that the cumulative scan time has crept upward until a timing margin disappeared.

There is also confusion around deterministic behaviour. Deterministic does not mean infinitely fast. It means predictable. A PLC with a steady 12 millisecond scan is far more useful in control applications than a system that sometimes responds in 1 millisecond and sometimes in 200 milliseconds for no clear reason. Predictability is what lets you design with confidence.

How Scan Cycles Affect Troubleshooting

When a machine behaves strangely, the scan cycle often explains the behaviour faster than staring at the code in frustration.

Suppose an operator says a level switch was definitely active, but the pump did not stop. You have a few immediate questions. Was the switch actually wired to the PLC input you think it was? Was the signal active long enough to be seen? Was there an input filter delaying recognition? Did the logic require the condition to be true for more than one scan? Was the output being held by some later piece of logic in the same cycle?

That line of thinking is much stronger than randomly forcing outputs and hoping something becomes obvious.

Scan cycle awareness also helps with nuisance alarms. If an alarm chatters on and off rapidly, it may be because the underlying signal is oscillating around the threshold and being evaluated every scan. The answer might be deadband, filtering, or a time delay before annunciation. In other words, the scan cycle is doing its job faithfully and your logic needs to account for the real behaviour of the process.

Intermittent faults are another area where scan understanding matters. If a machine only fails occasionally and you cannot reproduce it easily, ask yourself whether a short-lived event could be slipping between scans. Fast sensor pulses, bouncing contacts, noisy feedback signals, and brief communication dropouts can all create symptoms that look random until you think about timing.

One of the most useful habits during troubleshooting is watching live values online while thinking in scans, not in vague time. Which signal went true first? Did the PLC ever actually see the bit change? Did a timer reset because its condition dropped out for a single scan? Did the sequence advance and then immediately fall back because another condition was evaluated later in the same cycle?

That is where scan-cycle thinking becomes very practical. You stop treating the PLC like a black box and start treating it like a very fast but very orderly machine.

Where Scan Cycles Connect To The Rest Of PLC Programming

Once scan cycles click into place, a lot of other topics stop feeling disconnected.

Inputs and outputs become more intuitive because you understand that the PLC is working from an image of the field, not from magical direct awareness. When you monitor online, you are looking at that internal representation as it is being refreshed each cycle.

Ladder logic becomes easier to read because execution order means something. Left to right and top to bottom is not just a drawing convention. It affects how internal bits are set, reset, and carried through the current scan.

Timers and counters make more sense because they depend on repeated evaluation. A counter usually needs an edge because without edge logic it could count every scan while a condition remains true. A timer needs conditions to stay true through repeated scans long enough to reach its preset.

Communications and device integration become easier to reason about because many instructions are asynchronous. One scan sends the request, later scans observe Busy, Done, or Error, and event or background tasks may be involved in the middle.

State machines and sequences sit comfortably on top of the scan model. On each pass, the PLC checks the current state, evaluates transition conditions, and then executes the logic for the active state. This is one reason state-based design feels so natural in PLCs. The scan cycle is already providing the repeated evaluation loop that the sequence needs.

Troubleshooting improves because you start asking sharper questions. Instead of saying “the PLC ignored the signal,” you ask how long the signal was present, whether the input was filtered, what the scan time was, and where in the logic the result was later overwritten.

That is why scan cycles are not just an introductory topic. They are the base layer that supports almost everything else you will learn in industrial automation.

What Good Engineers Start Noticing Early

The engineers who get strong quickly in PLC work tend to build the same set of instincts. They ask how fast the process is moving. They check scan time without being prompted. They think about whether a signal is a maintained condition or a short pulse. They understand that a sequence may need confirmation over more than one scan, not just a single true bit at the perfect moment.

They also develop respect for the difference between plant reality and PLC memory. Just because the logic thinks an output is on does not guarantee the field device has moved yet. Just because a bit is true for one scan does not mean the operator ever saw it. Just because a signal appeared in history does not mean it lasted long enough for every part of the program to respond the way you expected.

Those instincts do not come from memorising definitions. They come from understanding the cycle and then looking at real behaviour through that lens.

If you are new to PLCs, the biggest takeaway is simple: start thinking in repeated scans, snapshots, and execution order. Whenever something behaves unexpectedly, ask yourself what the PLC read, when it read it, what order the logic executed in, and when the output was actually updated.

That one habit will make the rest of PLC programming feel far less mysterious. The scan cycle sits underneath everything the PLC does. Once that is clear, the code starts making sense.