Atomicity: The Myth That's Slowing Down Your SCADA System
Data tearing is real. But it's almost never the root cause of your SCADA data quality problems — and the popular "fixes" are often worse than the disease.
Let's cut the noise. We are professionals dealing with real-time physics, not abstract data models. If you think the Modbus protocol is the primary source of your data acquisition headaches, you're looking in the wrong place.
The recent hand-wringing over Data Tearing — the idea that a 125-word Modbus block read delivers a Frankenstein's monster of data points from different moments in time — is largely a distraction manufactured by those who haven't spent enough time debugging ladder logic.
Yes, technically, if a PLC logic scan interrupts the Modbus stack's memory copy, you get a mixed state. We have known this since Function Code 03 was deployed. The question isn't if it can happen, but how often it matters — and more importantly, who is responsible for mitigating it.
Stop Blaming the Protocol, Check the Code
The foundational failure in data tearing is almost always on the PLC programming side. If your SCADA client is reading directly from the registers being actively manipulated by the main control logic, you have designed a brittle system. Period.
The Fundamental Mismatch
The Modbus slave is a memory mirror, not a transactional database. Expecting atomic reads from a concurrently executing system is naive. The fix is not to invent complex application-layer protocols on top of Modbus — the fix is good PLC design.
// The Rule of Thumb for Field Engineers:
If a register is actively changing during the scan cycle,
it should NEVER be the primary Modbus mapping.
The professional standard — taught in every competent controls training course — is the Static Communication Array. The main control logic copies the critical setpoints, status flags, and calculated variables into a dedicated block of memory (the "Shadow Buffer") once per scan, usually at the end. The Modbus server then reads only from this static array.
If your PLC programmer isn't using a BLKMOV to dump live data into a read-only buffer before serving Modbus requests, then your problem isn't Modbus tearing — it's poor engineering discipline.
The Throughput vs. Coherence Trade-Off: A False Dilemma
The argument that larger block reads exponentially increase tearing risk is fundamentally flawed, and frankly, insulting to anyone who understands CPU architecture.
The window of vulnerability is the time it takes the PLC's onboard stack to copy the data from RAM to the TCP buffer. This operation occurs in microseconds. A full 125-word transfer, even on older hardware, finishes well before the next major scan cycle trigger, which runs in the millisecond range.
If your system is exhibiting tearing at this scale…
The bottleneck isn't the size of the packet — it's network latency and PLC CPU cycle time. If your system is so underpowered that copying 125 words causes an observable system state, you don't have a polling protocol problem. You have a CPU saturation problem. Buy better hardware.
The Inefficiency of Over-Engineering a Solution
The proposed "fixes" based on application-layer orchestration are performance killers. Here's an honest assessment:
The Handshake Protocol (Polling for a Flag)
This mandates that every read requires a write. You've just doubled the network load and forced the PLC to manage synchronization state, adding latency and increasing the chance of an actual handshake failure. This is an anti-pattern for high-speed polling.
The Sequence Counter
This is the only suggestion worth keeping. If you are reading discontinuous data across a long block, verifying the counter parity between the start and end registers is a reliable, low-overhead way to flag a torn read. A simple retry is cheaper than a handshake and has no side-effects on the PLC.
Application-Layer "Data Ready" Flag
This is the hallmark of an IT architect trying to force database semantics onto process control. We don't need transaction logs; we need deterministic cycles. The "Data Ready" pattern belongs in an MES, not in your Modbus polling loop.
Conclusion: Stick to the Basics
Stop worrying about the ghost of data tearing when your system is fundamentally slow or badly programmed. Modbus TCP is efficient because it is simple and relies on the deterministic nature of the PLC control loop — a nature that you must enforce through proper code structure.
If you are getting incoherent data from a block read, work through this checklist in order:
Verify the PLC programmer is using a Static Buffer (BLKMOV into a dedicated Modbus-facing memory area).
If a static buffer exists, add a Sequence/CRC Check on the block to validate integrity and trigger a retry on mismatch.
If the integrity check fails repeatedly, your CPU is overworked. Fix the processor load.
The industrial network needs reliable plumbing, not complex, software-defined, transactional guarantees. Save the architectural wizardry for the MES layer, and let the PLC focus on controlling the machine.
Modbus Connect gives you a direct window into what your PLC is actually sending. Use it to verify your static buffer is wired correctly before data quality problems make it into your historian. See what Modbus Connect can do →
Validate Your PLC Buffer with Live Traffic
Once you've implemented a Static Communication Array, confirm it's actually serving stable data. Modbus Connect lets you inspect every read response in real time, compare register values across poll cycles, and spot coherence violations before they reach your historian.
Get Started with Modbus Connect
- •Poll the static buffer and the live registers side-by-side to confirm the staging boundary is working
- •Log raw responses and diff adjacent cycles to detect unexpected mid-scan changes
- •Chart related registers simultaneously to visualise coherence violations before the buffer is in place
- •Stress-test under load to confirm your sequence counter detects torn reads correctly
Recent Blog Posts
Concurrency Control in PLC Data Acquisition: Moving from Asynchronous Reads to Atomic Staging
Non-atomic reads produce incoherent data snapshots that pass all integrity checks yet represent states that never existed.
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.
Modbus TCP Performance: Maximising Throughput with Block Transfer Efficiency
Why large contiguous reads outperform scattered single-register polls — and how to design your register map for maximum throughput.