Modbus Values: Verify Byte Order, Register Order and Scaling Separately
Modbus specifies big-endian representation and illustrates byte transmission within a sixteen-bit register. Higher-level composite values still need a device mapping contract. That register rule does not establish a universal thirty-two-bit floating-point word order for every vendor interface.
Separate byte and word order
Retain original wire bytes, individual register values and the vendor composite-field definition. Distinguish byte order inside a register from ordering across registers. Ambiguously named swap options can change more than one relationship, so record their exact effect rather than only their enabled state.
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.
Confirm type before float decoding
Check whether the field is signed integer, unsigned integer, floating point or fixed point, including scale and units. An unexpectedly large or small result is not automatically a word-order fault. Type and scaling errors can produce similar symptoms and need their own documented interpretation.
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 several distinguishing inputs
Choose reference values that distinguish candidate arrangements and retain raw registers beside conversions. Zero or repeated-byte patterns may fail to distinguish different orderings. A correct display for one such value cannot validate every composite field or establish the parser behaviour across the useful numeric range.
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.
Review composite-value consistency
Check the device contract for updating and consistency across registers forming one value. Reading several words in one request does not itself establish the vendor application update mechanism. Use the documented consistency arrangement when interpreting a changing composite measurement rather than assuming an unspecified snapshot guarantee.
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 an explicit decoding contract
Record type, byte order, word order, scale and worked references with the device-document revision. Replay the reference inputs after firmware, client-library or parser changes. Swap settings should become an explained interface contract rather than an undocumented preference remembered only by the original maintainer.
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.