.png)
Modbus Read/Write in One Transaction: A Reply Is Not Proof the Process Has Settled
A combined Modbus write/read can confirm a communications sequence while the physical process is still changing. Define whether acceptance concerns a stored command, controller state or settled equipment response.
Original conceptual illustration; not a live software screen, specific product or customer installation.
Key takeaways
Define the register meaning and write authority.
Separate stored command from measured feedback.
Accept the process using its own criteria.
1. Separate protocol order from process behaviour
Modbus function 23 combines writing and reading holding registers in one transaction, with the write performed before the read. That ordering does not establish that a motor, valve, thermal system or application task has reached its final operating state.
A BG200 industrial IIoT gateway enquiry should therefore include the exact supported function and the required acceptance evidence. Confirm the complete client, gateway and device path rather than assuming every Modbus-capable product implements a combined operation.
2. Name what the returned value proves
A command register may echo a requested target while an independent status register still indicates transition. Write the test objective using the actual supplier map. Distinguish requested setting, accepted setting, measured feedback and quality or fault indication.
Avoid a single green success indicator that combines all four meanings. A communications reply, device acknowledgement and physical acceptance may occur at different stages. Define the required evidence for each stage before deciding which values an operator can rely on.
3. Use a safe hypothetical sequence
Imagine an isolated controller simulator with a target of 50 and feedback initially at 20. A combined operation writes the target and reads the feedback. Returning 20 is not by itself a protocol failure: the simulated process has not yet moved.
A useful test records target 50, the immediate feedback and subsequent feedback under the documented application cycle. Define the allowed settling condition in the engineering requirement. Do not infer a universal delay or tolerance from this hypothetical example.
Original explanatory infographic. Values and test cases are hypothetical; equipment selection and implementation require project-specific verification.
Diagnostic comparison
Observation | Check next |
Command echoes but feedback differs | Check application response and settling criteria. |
Reply lost after request | Resolve outcome through authorised read-back. |
Combined function rejected | Verify end-to-end function support. |
4. Handle uncertain outcomes deliberately
If the connection fails after a write may have reached the device, classify the outcome as uncertain until an authorised read-back resolves it. Blindly resending a state-changing operation can have consequences where the destination triggers actions rather than stores an ordinary setting.
Use an approved simulator to test normal replies, application rejection, communication loss and delayed process feedback. Record whether retries are safe for the exact register semantics. A general communications library cannot decide the process consequences of a repeated command.
Define the register meaning and write authority.
Separate stored command from measured feedback.
Test the combined operation in isolation.
Resolve uncertain writes before retrying.
Accept the process using its own criteria.
5. Build a commissioning acceptance record
Retain the controlled equipment model, firmware, register map, command authorisation and accepted test procedure. Show which condition marks communications success and which condition marks application success. Include the response to a fault or an unmet acceptance condition.
Production control changes require competent people and application-specific validation. Do not use this guide for live commissioning, bypassing interlocks or claiming a generic protocol transaction is a certified safety function. For monitoring-only projects, keep writes disabled unless a separate approved requirement needs them.
Recommended equipment / related solutions
For a Modbus integration enquiry, assess the BG200 industrial IIoT gateway. Its catalogue lists Modbus TCP and RTU support; confirm the exact firmware, device map and required acceptance tests.
For a broader remote-asset monitoring scope, review the ProSense RTU Monitoring Kit. Confirm the supplied interfaces and whether a kit is appropriate; it is not a substitute for checking the connected device or an authorisation for control writes.
Related practical guide: Modbus Gateway Timeouts: Build a Request Budget Before Adding Retries
Frequently asked question
Will a longer communications timeout prove that equipment has settled?
No. A timeout controls waiting for communications. Physical acceptance needs the documented status, feedback and process criteria, with application-specific limits.
Technical references
Need help with your application?
Send the equipment models, current documentation and a sanitised test example. Discuss this integration and equipment requirement with ProSense; confirm the actual functions, interfaces and acceptance scope before purchase or deployment.
