Modbus Addressing: Reconcile Register Labels With Protocol Offsets
The Modbus application protocol defines zero-based PDU addressing, while mapping the device application to the data model is vendor-specific. Interpret manual labels using the device documentation rather than subtracting one indiscriminately from every number presented as an address.
Identify the table and function
Record coils, discrete inputs, input registers and holding registers separately, with access capability. The same number in different tables can refer to different objects. An address without function, device identity and table context is insufficient to reconstruct the intended request.
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 labels from wire offsets
Keep the original manual label, its documented meaning and the resulting PDU start address. Record any client option for one-based or zero-based entry. Otherwise a manual conversion followed by another tool conversion can introduce a subtle offset while the displayed configuration still looks reasonable.
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.
Use distinguishable reference fields
Choose known information that distinguishes neighbouring registers and retain raw responses. Similar values in adjacent fields cannot establish correct addressing. Use several identified values with units, rather than accepting one plausible display that could also be produced by the wrong neighbouring register.
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.
Check the complete requested range
For a block read, verify that the complete address-and-quantity combination is allowed. Checking only the first register is incomplete. Review reserved gaps and field boundaries against the device contract and retain quantity in exception records so that a range error is not misdiagnosed as a device failure.
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 a traceable address map
Include document location, label, function, wire address, quantity, type and units. Review after device-firmware or client-addressing changes. A receiver should be able to trace a business variable to actual request fields without guessing which numbering convention the original integrator intended.
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.