How to Guarantee Transaction Integrity When Writing Critical Data to Modbus PLCs

The Atomic Problem

This is the dirty secret of industrial integration: Modbus TCP has no native mechanism to ensure that a multi-register update is treated as a single, indivisible transaction.

If you are writing a set of coordinates, a recipe, or a safety setpoint, you are at the mercy of the PLC's internal task scheduler and the Ethernet stack's buffer.

Critical insight: If your system isn't architected for atomicity, you aren't just sending data — you're sending poison.

1. The “Tearing” Effect: When One Scan Becomes Two

The most common failure occurs when a Modbus Write Multiple Registers (FC 16) operation spans across a PLC scan cycle transition.

Imagine you are writing a 32-bit float (two 16-bit registers) to a PLC:

The Modbus stack receives the first 16 bits and writes them to the memory address.
The PLC's Logic Engine interrupts the communication task to run the main scan.
The logic reads a “Frankenstein” value: the first half of the new value and the second half of the old value.
The Logic Engine calculates a motor speed based on this corrupted number.

Reality check: In high-speed 2026-era production environments, where scan cycles are sub-millisecond, the probability of “tearing” data increases exponentially with the number of registers you send.

2. The FC 16 Fallacy

Many engineers assume that using Function Code 16 (Write Multiple Registers) provides atomicity because all the data is in one TCP packet. This is a dangerous misunderstanding of how PLC firmware works.

Just because the data arrived in one packet doesn't mean the PLC's backplane or its internal memory-mapping routine moves that data into the “Logic Tags” in a single atomic operation.

The truth: On many mid-range PLCs, the Modbus server is a background task that “trickles” data into the registers as it receives it. One TCP packet does not equal one atomic operation.

3. Engineering the Solution: The “Dirty Bit” Handshake

Since the protocol won't save you, your Logic Architecture must. To guarantee that the PLC only acts on complete, verified data, you must implement an Application-Layer Handshake.

The Protocol

Step 1: The Data Block

Pack your critical data into registers 1 through N.

Step 2: The Sequence/Trigger Register

Assign register N+1 as the “Commit” or “Dirty Bit” register.

The Client Side

Write the entire block (Registers 1 to N+1) in a single FC 16 call.
The “Commit” value should be a unique incrementing integer (a heartbeat or sequence ID).

The PLC Side

Do not map your logic directly to the Modbus registers.
Create a “Shadow Buffer” in the PLC.
Monitor the “Commit” register. When it changes, copy the Modbus registers into your “Active Logic” tags in one single BLKMOV (Block Move) or COP instruction during the logic execution phase.
Clear or acknowledge the “Commit” register.

Why this works: The BLKMOV/COP instruction executes within a single scan cycle, guaranteeing that all values are copied atomically from the communication buffer to the active logic memory.

4. The “Master” Write: Using FC 23

For the highest integrity requirements, the “Deconstructed” approach suggests moving toward Function Code 23 (Read/Write Multiple Registers).

FC 23 is the most underutilized tool in the Modbus toolkit. It allows you to write a new set of data and receive the current state of the PLC in a single request-response cycle.

This provides immediate verification:

If the Read portion of the FC 23 response doesn't match the state you expected after the Write, you know the transaction failed instantly.
It reduces the “blind period” between a command and an acknowledgement by 50%.

Caveat: Not all PLCs support FC 23. Verify your device's capabilities before designing around this function code.

5. Summary: Stop Trusting the Wire

Determinism in Modbus TCP is an illusion provided by fast hardware, but Integrity is a deliberate engineering choice.

If your data is critical, you must treat the Modbus register map as a volatile “Arrival Hall” — not the final destination.

The Golden Rule:

Never let your PLC logic “look” at a Modbus register while it's being written to. Buffer it, verify it, and move it only when the transaction is complete.

Implementation Checklist

Reserve a “Commit” or “Sequence ID” register at the end of every critical data block.

Implement shadow buffers in your PLC logic — never read directly from Modbus communication registers.

Use BLKMOV/COP instructions to atomically transfer data within a single scan cycle.

Consider FC 23 for immediate write verification on supported devices.

Document your handshake protocol as part of your register map specification.

Test Your Integrity

Understanding transaction integrity is critical, but you need the right tools to verify your implementation. Modbus Connect lets you monitor register values in real-time, log all communications, and verify that your handshake patterns are working correctly.

Debug your Modbus writes with confidence

Download Modbus Connect Free

Real-time register monitoring, protocol analysis, and comprehensive logging for Windows, macOS, and Linux.