Concurrency Control in PLC Data Acquisition: Moving from Asynchronous Reads to Atomic Staging
Non-atomic reads across volatile PLC memory produce incoherent data snapshots that pass all integrity checks yet represent states that never existed. The fix is architectural, not configurational.
The primary weakness in many industrial data acquisition schemes is the reliance on non-atomic reads across volatile memory areas. When a Modbus client requests a block of contiguous data using Function Code 03, the assumption of temporal consistency within that payload is routinely violated by the underlying execution environment of the Programmable Logic Controller.
This is a concurrency management issue, not a protocol failure. The data received passes all integrity checks — CRC, protocol conformance, register bounds — yet represents a state snapshot taken across multiple distinct moments within the PLC's scan cycle.
The Silent Corruption
Incoherent reads produce no error codes, no CRC failures, and no exception responses. Standard diagnostics give a clean bill of health on data that is physically impossible.
The Split Read Phenomenon
The standard PLC scan cycle involves reading inputs, executing control logic, and then writing outputs. When the Modbus server task begins servicing a multi-register request, its progress can be arbitrarily interrupted by the application logic completing its own cycle:
The Modbus handler begins servicing a read request for Registers R1 through R10.
The handler reads R1–R5, which correspond to values at the start of the current cycle.
The PLC completes its main execution scan, updating the underlying variables that map to R6–R8.
The handler resumes, reading the new values for R6–R8 and then R9–R10, which correspond to the end of the previous cycle.
// Resulting payload:
(R1–R5 OLD) + (R6–R8 NEW) + (R9–R10 OLD)
// An incoherent aggregate — this physical state never existed
If R1 and R6 represent related physical quantities — motor current and valve position, for example — their simultaneous use in downstream analysis yields results based on a non-existent physical transition. No alarm fires. No checksum fails. The data is simply wrong.
Ineffective Mitigation Strategies
Attempts to bypass this issue through network or polling adjustments fail because the root cause is internal to the PLC execution environment, not the network layer.
Increased Block Size
Utilizing larger contiguous reads (FC 03/04) merely increases the probability that the PLC scan cycle will complete mid-transfer, amplifying the inconsistency window rather than eliminating it.
Increased Polling Frequency
Aggressively reducing the read interval does not eliminate the timing conflict. It increases the statistical probability of sampling during the critical update window, potentially worsening the situation.
Timestamp Validation
Timestamps confirm when the packet left the network interface. They offer no guarantee about the temporal alignment of the data payload collected internally by the Modbus server task.
All three strategies share the same fatal assumption: that the coherence problem can be solved from outside the PLC. It cannot. The solution must be implemented in the PLC program itself.
The Engineering Solution: Atomic Data Staging
To guarantee the temporal coherence of logically related data sets during external acquisition, the PLC application must explicitly manage data exposure. This requires separating the volatile working memory from a stable acquisition memory — a pattern known as shadow registers.
Working Registers (RLive)
The active memory space used by primary control logic. Subject to constant, asynchronous updates within every scan cycle. Never exposed directly to the Modbus server.
Acquisition Registers (RModbus)
A designated, contiguous memory block reserved exclusively for servicing external reads. Values here are frozen between atomic copy operations.
The Synchronous Copy Routine
A high-priority, time-critical task dedicated to executing a direct, single-step memory copy from RLive to RModbus.
Critical Constraint: This copy must execute entirely within a single, non-preemptible PLC scan or high-priority executive task. The goal is an instantaneous freeze-frame copy of the related data.
// Atomic copy routine (conceptual, executes in one scan)
R_Modbus[1..10] := R_Live[1..10];
// Modbus server reads only from R_Modbus — never R_Live
The Modbus server configuration must then be directed only to serve data requests from the RModbus shadow area. This staging isolates the volatile application state from the static snapshot presented to the client, ensuring all values in the received block correspond to the precise moment the atomic copy completed.
Granularity and Application Grouping
Staging should not be applied indiscriminately across the entire data map. Engineering effort should focus on identifying logically coupled variables whose asynchronous reading would lead to computational errors or safety ambiguities.
Examples of Required Coherent Groups
A position read against a stale setpoint produces an error signal that never existed in reality.
Split reads produce a control residual that triggers false efficiency alarms or incorrect PID tuning decisions.
An interlock status without its contemporaneous trigger count is forensically inadmissible and operationally misleading.
Variables that are genuinely independent — an ambient temperature sensor alongside a conveyor speed — do not require coherent grouping and can be read in separate, unsynchronized requests.
From Probabilistic to Deterministic
By implementing explicit memory staging, the responsibility for data integrity shifts from hoping the network timing aligns, to architecturally enforcing a coherent snapshot available upon request.
This transitions data acquisition from a probabilistic activity — where correctness depends on the accident of favorable scan timing — to a deterministic engineering control where every Modbus read is guaranteed to reflect a single, coherent moment in process history.
The implementation cost is minimal: a contiguous memory block and one atomic copy routine per logical group. The engineering benefit is permanent: every downstream analysis operates on physically valid data.
Modbus Connect is built for engineers who need to see what the PLC is actually sending. Explore our features to inspect raw register traffic and validate your staging implementation before it reaches production.
Verify Your Staging Implementation with Live Traffic
Once you have implemented shadow register staging, you need to confirm that the Modbus server is actually serving from the acquisition registers — not the live working area. Modbus Connect lets you inspect every read response in real time, compare register values across poll cycles, and confirm coherence before the system goes live.
Get Started with Modbus Connect
- •Poll individual register groups to confirm snapshot consistency across back-to-back reads
- •Log raw responses to file and diff adjacent cycles for unexpected mid-read value changes
- •Chart coupled registers simultaneously to visualise coherence violations before staging is in place
- •Stress-test the staging boundary under high scan-cycle load to confirm atomicity holds
Recent Blog Posts
How to Guarantee Transaction Integrity When Writing Critical Data to Modbus PLCs
Learn the Dirty Bit Handshake pattern and FC 23 to prevent data tearing when writing critical values to PLCs.
The IP Address: The Ghost in the Machine and the Fatal Flaw of Modbus TCP Abstraction
NAT/PAT strips the Layer 3 identity that Modbus TCP depends on, causing identity collisions, audit failures, and security policy collapse.
The PLC's Socket and CPU Ceiling: Why Simultaneous Modbus Connections Kill Determinism
Every industrial controller operates under a hard Modbus TCP Resource Ceiling. Understand socket limits, scan cycle contention, and buffer overruns.