The Truth About PLC Scan Cycles and Polling: Why Your SCADA System Misses Critical Data

A SCADA or MES system misses critical machine data because it samples the PLC far more slowly than the PLC scan cycle runs. A controller that scans every few milliseconds can see a fault, act on it and clear it long before the next one-second poll, so the historian records nothing. The fix sits in the controller: latch or queue the event with a timestamp so that a slower reader can still retrieve it. This article explains how PLC scan cycles, memory and polling interact, and which capture pattern fits which signal.

Introduction: Why PLC Data Structures Decide What SCADA Sees

In most manufacturing environments, digital transformation efforts tend to focus on SCADA and MES platforms. These systems are often expected to provide real-time insight, drive efficiency, and enable better decision-making.

But here’s the problem.

Many of the data issues manufacturers face do not originate in the SCADA or MES layers. They begin at the source: the controller. Missed signals, inaccurate values, and gaps in historical trends are often symptoms of how data is structured and handled inside the PLC.

PLCs are not just machines that execute logic. They are the first point of data collection. Every input, every calculation, and every output passes through a memory structure defined in that control system. If this structure is not designed with data quality and visibility in mind, everything that comes afterward is compromised.

Whether you are building new functionality, integrating with third-party systems, or trying to solve a nagging fault, your understanding of PLC data structures will shape the outcome. This article lays the foundation. It explains how data is processed inside a PLC, what assumptions commonly lead to failure, and why a better structure leads to better decisions.

Understanding the PLC Scan Cycle: What the Controller Is Really Doing

Before we can improve the way PLCs handle data, we need to understand how they process information in the first place. At the core of every control system is a predictable and often misunderstood routine: the scan cycle. This sequence defines how quickly the PLC reacts to physical changes in the process and how reliably it communicates those changes to external systems.

The Three-Step Cycle: Read Inputs, Execute Logic, Write Outputs

Every PLC operates using a repeated three-step loop:

• Read inputs: The PLC checks the current state of all connected sensors and input devices.
• Execute logic: Based on the input values, it evaluates the programmed logic using ladder diagrams, function blocks, structured text, or other supported formats (the languages standardised in IEC 61131-3).
• Set outputs: The controller updates the outputs, turning devices on or off, sending signals to drives, or adjusting analog controls.

This cycle repeats continuously, often many times per second. The time it takes to complete one cycle is referred to as the scan time. On most modern PLCs, scan times are in the range of 1 to 10 milliseconds, with 5 milliseconds being a common baseline.

The problem begins when we compare this with the polling intervals used by higher-level systems like SCADA or MES. These systems typically poll the PLC once every 1000 milliseconds (1 second). That means the SCADA system only sees a snapshot of what the PLC is doing every one second, while the PLC has already executed its logic 200 times or more in that same period.

What Gets Missed at 1000 Millisecond Polling

If an input signal changes for just a few milliseconds and returns to its normal state before the next polling cycle, that event is completely invisible to SCADA and MES systems. It existed, the PLC saw it, and it may have even acted on it, but no trace of that signal reaches the historian or operator interface.

This is not a defect of any one product. Most polled protocols read the value a register holds at the moment of the request. The Modbus Application Protocol Specification, for example, defines function code 03 as reading “the contents of a contiguous block of holding registers”: the contents now, with no memory of what they were a moment ago.

This disconnect is one of the most common root causes of confusion during troubleshooting and one of the easiest problems to solve with better PLC-side design.

Sequential vs Asynchronous Execution

Historically, PLCs ran logic in a strictly sequential manner. Each instruction executed line by line, and the output was updated only after the entire program was evaluated. This made it relatively easy to predict timing and behavior.

However, newer PLCs are built with faster, multi-tasking processors and increasingly complex architectures. Many now support asynchronous execution, meaning parts of the logic or special routines may run outside of the standard scan cycle. For example, interrupt routines can be triggered by a high-speed signal and execute immediately, regardless of what the main program is doing. Rockwell’s Logix 5000 tasks manual is a representative vendor example: a project can mix a continuous task, periodic tasks that run on a fixed interval, and event tasks triggered by an I/O module input change.

This capability brings more flexibility and performance, but it also increases complexity. Engineers must now account for multiple timing models, asynchronous behavior, and the risk of assumptions that no longer hold true. A routine may complete faster or slower than expected. Data may be updated mid-cycle. Outputs may change before all logic is evaluated.

When teams rely on outdated assumptions about PLC timing, they often create logic that is brittle, inconsistent, or prone to race conditions. Understanding the scan cycle and how it has evolved is essential for anyone working with high-performance systems, tight tolerances, or advanced diagnostics.

How Data Lives in a PLC

To truly understand the limitations and opportunities in your data pipeline, you need to look inside the PLC. Not just at the logic, but at how information is actually stored, organized, and updated. This section introduces the basic memory structure of a PLC and why the way you define and handle data matters more than most realize.

Registers, Bits, and Basic Memory Concepts

At its core, a PLC is a real-time system that works with very simple data types. Discrete inputs and outputs are typically stored as single bits in dedicated memory, each holding a 0 or a 1 that represents an on or off state. Analog values and counts live in integer or floating-point registers. All of these are updated continuously, as fast as the PLC can scan the inputs and execute logic.

This means that most data inside a PLC is ephemeral. It exists for a few milliseconds before being overwritten. A push button may be pressed and released between two scan cycles. A sensor might briefly trigger due to vibration or machine movement, but by the time the data is polled by a higher-level system, the register already contains a new value.

The memory space inside a PLC is finite. It is optimized for speed and determinism, not for long-term storage. That is why relying on a single value to represent a signal across time can be misleading, especially when the system is running quickly.

If you treat every register as a permanent truth, you are missing the reality that PLC memory is constantly in motion.

The Case for Structured Thinking

Most early-stage PLC programs rely heavily on basic variables: individual bits for on/off signals, integers for counts, and floating-point numbers for analog values. These are easy to read and manipulate, but they carry no context.

As systems grow in size and complexity, this simplicity becomes a problem. A motor may require not just a start bit, but also feedback status, fault codes, runtime, torque demand, and other key attributes. Managing each of these as isolated variables quickly becomes unmanageable.

That is where structured data comes in.

Arrays allow you to group related values in sequence. They are ideal for tracking changes over time or storing repeating patterns. User-Defined Types (UDTs), on the other hand, let you group different kinds of values under a single logical structure. You can define a “motor” type that includes all the data points you need, then reuse that structure across your project.

Structured thinking is not just about keeping your code clean. It is about preparing your system for integration, diagnostics, analytics, and scale. Context becomes critical. When a historian or SCADA system pulls data from a structured tag, it understands what the value represents and how it relates to the rest of the system.

If your data is structured well, it can travel from the PLC to the cloud without needing constant translation. If it is not, every integration becomes a manual mapping exercise that wastes time and introduces risk. The same principle, applied plant-wide, is what a unified namespace formalises.

PLC Scan Cycles vs SCADA Polling Rates: The Great Disconnect

There is a growing gap between what SCADA and MES systems expect and what PLCs are actually capable of delivering. This disconnect is often invisible until it creates a problem. And by the time that happens, critical data has already been lost.

To understand this issue, we need to look at how polling works and what it means in practice.

SCADA/MES Expectations vs PLC Realities

In many facilities, SCADA and historian platforms and MES are configured to poll PLCs once every 1000 milliseconds. This has long been the industry norm. It is conservative enough to reduce network traffic and storage load, while still being frequent enough for basic monitoring.

But 1000 milliseconds is an eternity for a PLC.

A typical PLC scan takes around 5 milliseconds. In that same one-second polling interval, the controller may have executed its full logic loop more than 200 times. That means 200 opportunities to read inputs, evaluate logic, and update outputs. Most of that activity is completely invisible to any system polling at the one-second level.

The result is simple but damaging. A fast-changing signal may never be seen by SCADA or MES. A motor that faults and recovers within half a second might appear to have been running the entire time. A sensor that flickers due to vibration might never register as active.

This discrepancy leads to inaccurate reports, misleading trends, and hours of wasted effort during troubleshooting.

Subscriptions do not remove the problem on their own. In OPC UA, each monitored item has a sampling interval that the specification describes as a “best effort” rate at which the server samples its source, and a queue whose size is set when the item is created. With a queue size of one, the OPC UA Part 4 services specification notes that the queue “becomes a buffer that always contains the newest Notification”: a change that comes and goes inside one sampling interval is never reported.

Practical Example: Missed Event from a Servo Drive

In 2018, a servo-driven line experienced intermittent shutdowns that no one could explain. The motor would stop suddenly, fault out, and then restart after a reset. The operators suspected a mechanical jam. The maintenance team replaced the motor. The line kept failing.

When engineering reviewed the SCADA data, there was no fault event recorded. Everything appeared normal. The system had been configured to pull data from the drive every five minutes. The only data captured was a default “over torque” code from the PLC fault register at 10:00 AM.

What no one saw was the lead-up to the fault. Current draw, speed fluctuations, and voltage spikes were all missed. By the time anyone looked at the data, the PLC had already cleared the registers. The SCADA system had already overwritten its snapshot. And the opportunity to diagnose the root cause was lost.

This scenario is not uncommon. A polling interval that works fine for a tank level or a temperature reading can be completely useless for detecting fast electrical faults, quick mechanical trips, or short-lived process conditions.

When data is missing, you cannot trust your history. And when you cannot trust your history, you cannot improve the process.

Why Engineers Need to Think Like Software Developers

As PLC applications grow more connected and data-driven, traditional control logic is no longer enough. Engineers are being asked to design systems that not only run machines but also produce clean, usable data for a variety of downstream applications.

Meeting that challenge requires a shift in mindset.

It is not just about writing logic that works. It is about writing logic that reveals what happened, when it happened, and why.

The Case for Data Queues and Buffers

Most PLC inputs are stored as single, real-time values. They are updated constantly and offer no memory of previous states. This design works fine when your only concern is to actuate outputs in the moment. But when a signal changes faster than your polling interval, that one value becomes a liability.

A data queue or buffer solves this problem by storing multiple time-stamped values in sequence. Think of it as a scrolling window of state changes that records what happened across time, not just in the current scan.

Instead of watching a digital input flip between zero and one, a queue can hold dozens or hundreds of those state changes. This allows you to replay events after they occurred, detect patterns, and align logic with what actually happened on the plant floor.

This approach becomes especially important for:

• High-speed processes with intermittent inputs
• Safety-critical systems that require event tracking
• Troubleshooting sessions where timing is unclear
• Systems with infrequent polling but tight control windows

By implementing queues and buffers inside your PLC, you create a trail of evidence that supports diagnostics, traceability, and continuous improvement.

Introducing Software Patterns into PLC Programming

In traditional PLC programming, the focus has always been on physical control. Inputs trigger logic, outputs respond. But modern applications demand more than just deterministic behavior. They require thoughtful data design.

Software developers have long used patterns to manage data flow, reduce complexity, and ensure maintainability. Control engineers can benefit from the same thinking.

Here are three important concepts that apply directly to PLC systems:

• Timestamps: If you store values in an array or buffer, also store when each value occurred. This adds traceability and enables comparisons across systems.
• Resolution control: Not every tag needs millisecond-level storage. For analog values or slow-changing states, store only when a meaningful change occurs. This reduces noise and saves resources.
• Filtering: Implement logic that discards redundant or insignificant changes. You can set thresholds or use logic to detect only rising edges, falling edges, or transitions of interest.

By borrowing these concepts, engineers can build PLC programs that are more than just reactive. They become proactive tools that deliver reliable, structured, and contextual data to SCADA, MES, and analytics platforms.

Four Ways to Get a Fast PLC Event Past a Slow Poll

The patterns above come down to four practical options. They differ in what survives between two reads, what they cost in the controller, and where they fit. Choose per signal, not per plant: a tank level does not need a queue, and a safety trip should never depend on the poll rate.

Method	What survives a 40 ms event between polls	Cost	Where it fits
Single register, polled (driver poll, Modbus read)	Only the value at the instant of each read. The event is gone	Nothing extra	Slow analog values: levels, temperatures, pressures
Latched bit, reset on acknowledgement	That the event happened at least once since the last read. Not when, not how many times	One bit and a reset handshake from SCADA	Fault and alarm flags where occurrence matters more than timing
Timestamped FIFO queue (array of UDT records)	Every transition, in order, with controller time, until the queue overflows	Array memory, index logic, an acknowledgement handshake and a synchronised controller clock	Fast faults, button presses, trips, root-cause diagnostics, traceability
Report by exception (OPC UA subscription, Sparkplug over MQTT)	Every change the publisher detects, timestamped and pushed without waiting for a poll	Configuration on the publishing side. The publisher still samples the PLC, so a pulse shorter than its sampling interval can still be lost	Plant-wide data flows, high tag counts, a unified namespace

Report by exception deserves a precise reading. The Eclipse Sparkplug specification states that after the initial birth messages “new metric values only need to be published when the values change”, and it requires every data message to carry a timestamp. That removes the fixed poll from the path to the historian, which is why it underpins most MQTT and Sparkplug B architectures. It does not change what the edge node can see: an edge gateway that reads the PLC every 250 milliseconds, for example, publishes changes at that resolution. For events shorter than that, combine exception reporting with a queue in the PLC. Our MQTT guide for manufacturing covers the broker side in detail.

Designing a Buffer That Survives Between Polls

A queue that overflows silently is worse than no queue, because it looks complete. Before you write the routine, settle these points:

1. Size for the worst burst, not the average. The queue must hold every event that can occur between two successful reads, including a missed poll or a short network outage. An illustrative example: a reject station that can fault three times per second, read once per second, needs at least three records per read; to ride through a 60-second communications outage, it needs 180 records plus margin.
2. Timestamp in the controller. Record the controller’s time when the event occurs, not the time SCADA receives it. Synchronise controller clocks to a common time source, or events from two PLCs cannot be put in order.
3. Decide the overflow behaviour and flag it. Keep the oldest or keep the newest, but set an overflow flag the historian can see. OPC UA does the same thing in its own queues: when a notification is discarded, an overflow bit is set on the next value delivered.
4. Clear on acknowledgement, not on read. SCADA reads the records, then writes back the last index it stored. The PLC frees only acknowledged records, so a dropped read never loses data.
5. Capture faster than the scan when the pulse is shorter than the scan. A queue filled by the main scan inherits the scan’s blind spot. For sub-scan pulses, use an event task or interrupt triggered by the input, or an input module that latches or timestamps changes.
6. Structure the record. A UDT with event code, value, timestamp and sequence number lets every downstream system read the same meaning without remapping.

Where these patterns meet the rest of the plant data architecture, the controller design and the integration design have to be done together. That is the work our IT/OT integration service does: from the tag structure in the controls layer to what the historian and MES finally store.

Frequently Asked Questions About PLC Scan Cycles and Polling

What is a PLC scan cycle?

A PLC scan cycle is the loop a controller repeats continuously: read the inputs, execute the program logic, then write the outputs. The time one loop takes is the scan time, commonly a few milliseconds on a modern controller. Anything that happens and clears between two reads of an input is invisible to the logic, and anything held for only one scan is invisible to any system that reads the PLC less often.

Why does SCADA miss short events from the PLC?

Most SCADA and MES systems poll the PLC on a fixed interval, often once per second, and each poll reads only the current value of a tag. A PLC scanning every few milliseconds can see a fault, act on it and clear it hundreds of scans before the next poll. Unless the PLC latches or buffers that event, the poll finds the normal value and the historian records nothing.

How fast should SCADA poll a PLC?

Poll each tag at the rate its information changes, not at one rate for everything. Tank levels and temperatures are fine at one second or slower. Fast faults, button presses and trips should not depend on the poll rate at all: latch or queue them inside the PLC so a slower poll still retrieves them. Polling everything faster mainly adds network and controller communication load.

What is the difference between polling and report by exception?

Polling asks the PLC for a value on a timer and receives whatever the value is at that moment. Report by exception sends a value only when it changes, usually with a timestamp, as in OPC UA subscriptions or Sparkplug over MQTT. Exception reporting cuts traffic and catches more changes, but the publisher still samples its source, so a pulse shorter than its sampling interval can still be lost.

How do you capture a fast PLC event so a historian can see it?

Record it inside the PLC at the moment it happens. A latched bit proves the event occurred at least once since the last read. A timestamped FIFO queue, an array of records holding the value and controller time, preserves every transition in order until SCADA reads and acknowledges it. For pulses shorter than one scan, use an event task or an input module that latches or timestamps changes.

Key Takeaways

The PLC is not just a controller that executes logic. It is also the first and most important layer in your data architecture. Every value that enters your SCADA, MES, or cloud platform starts at the PLC. If that data is not captured correctly or is structured poorly, everything that follows is built on a weak foundation.

Understanding scan time, memory behavior, and how data structures work inside a PLC is critical. It allows you to design systems that are more accurate, more resilient, and more transparent.

SCADA and MES systems cannot guess what the PLC missed. They cannot recreate fast-changing events that were never stored. They can only reflect what the PLC makes available. That is why the design choices you make at the controller level have long-lasting effects across your entire operation.

Building better systems starts by thinking carefully about how data is created, captured, and passed along from the very beginning.

What’s Next in the Series

This first article established the foundation. You now understand how PLCs handle data internally, why scan time and memory structure matter, and how poor design at the controller level can impact everything from troubleshooting to analytics.

In the next two parts of this series, we will build on this foundation to help you create more structured, reliable, and scalable data architectures.

Article 2: Designing Smarter PLC Data Models Using Arrays and UDTs

Explore how to go beyond basic tags and build structured, reusable logic inside the PLC. This includes practical approaches for using arrays, implementing user-defined types (UDTs), and organizing data in a way that supports long-term scale and clarity.

Article 3: Building a Resilient Data Pipeline from Edge to Cloud Without Losing Fidelity

Understand what it takes to move data from the PLC into SCADA, MES, or cloud platforms without losing critical information. This article will cover polling strategies, buffering, edge processing, and how to architect a data pipeline that delivers both performance and insight. Until it is published, our overview of edge and I/O covers where buffering and protocol conversion sit between the PLC and the rest of the plant.