Modbus Write Responses: Distinguish Register Acceptance From Completed Work
A normal Modbus function 16 response contains the function, starting address and quantity written. It is not a complete echo of all submitted values and does not define physical-action completion for the application. The device contract must provide the relevant business-state evidence.
Associate request and response
Keep device, function, start address, quantity and original values, and match the response range. State what the normal response establishes. A response that does not return every submitted value should not be described as a complete value-by-value echo of the intended business semantics.
For this review, identify the delivered device, software and configuration revisions first. Record unsupported, disabled and untested capabilities separately. Evidence from another model is useful context, but cannot establish what the delivered combination actually provides. Keep the original input beside the settings used to interpret it.
Separate storage from adoption
Use the device interface to determine whether readback, commit or status confirmation is required. Equal readback can establish a stored value without proving that control logic has adopted it. Record the operating mode and activation conditions needed to interpret that distinction.
Retain the original input and the reason for the decision, rather than a successful screenshot alone. Change only the variables agreed for the comparison, and keep the before-and-after configuration. List conditions that were not exercised explicitly; they should not silently become part of the accepted operating range.
Define physical completion evidence
If a write requests an action, define device completion state, application identity and deadline separately. Protocol round-trip completion is not the physical completion time. Use approved isolated observation rather than requiring a hazardous real action to demonstrate that communication and business-state evidence are distinct.
Use the three illustrated observations as starting questions, rather than as diagnoses of an installation that has not been inspected. Check record completeness, units and identity before selecting the next observation. An unresolved result is more informative than a confident explanation assembled from missing fields or unrelated test runs.
Handle uncertainty after a timeout
A missing response after transmission does not prove that the write was not executed. Blindly repeating a command can be inappropriate for an action-triggering interface. Resolve uncertainty using documented identity, state or idempotency behaviour, and retain an explicit unresolved state when execution cannot be confirmed.
Let the site owner choose an approved isolated way to exercise relevant exceptions. Record normal operation, the exceptional condition and recovery separately. The purpose is to establish how the application recognises and explains untrustworthy input, without requiring production equipment to act on deliberately invalid results.
Deliver layered success criteria
Report protocol success, correct parameter representation, device adoption and business completion separately. Retain supporting evidence and exception branches for each. Review device-logic and client-retry changes so that the final interface does not reduce several different conditions to one unexplained success indication.
Deliver the configuration, representative samples, result table and unresolved questions together. Agree who reviews subsequent changes. The receiving team should be able to select one conclusion and trace it back to its input and decision path without relying on the original author to reconstruct the missing steps.
Original documentation and further reading
Continue with related articles in this section, or use selection guides to prepare the next review. Apply the device-specific documentation and agreed operating conditions when implementing a test.