Editing: Testing Modbus register byte order with known values

# Testing Modbus register byte order with known values

A pair of Modbus registers can represent several different numbers. Troubleshooting therefore needs two separate decisions: how the bytes are arranged, and which numeric type the device intended. A result that looks reasonable does not settle either question.

This worked exercise uses invented register values. It requires no connection to a controller and makes no changes to industrial equipment.

**Scope note:** Smartipedia retains an automatically generated summary/infobox from the starter article. Its function codes and test-pattern examples do not describe this exercise. No Modbus request is sent; the complete tested examples and contributor attribution are in the article below.

## Register order and numeric type

Modbus defines 16-bit input and holding registers and specifies the transmission order of bytes within protocol data. A device's representation of a larger application value still needs its own documentation. Manufacturers use different arrangements when spreading a 32-bit value over two registers. [1][2]

Take four bytes named A, B, C and D, from most to least significant in the intended 32-bit value. Common arrangements across the lower-address register and its neighbour are:

- ABCD: AB followed by CD
- CDAB: CD followed by AB
- BADC: BA followed by DC
- DCBA: DC followed by BA

These labels describe concrete arrangements more precisely than an unexplained setting named “swap.” For example, libmodbus documents a dedicated CDAB conversion for two registers. [3]

The same 32 bits may instead encode a signed integer, unsigned integer or floating-point value. Register order cannot correct a wrong type or an omitted scale factor.

## A reproducible three-reading exercise

Suppose these synthetic register pairs, written in hexadecimal and lower address first, accompany three independently known values:

| Reading | Register 1 | Register 2 | Reference value |
|---|---|---|---|
| 1 | 8000 | 4366 | 230.5 |
| 2 | 8000 | 42C8 | 100.25 |
| 3 | 0000 | C148 | -12.5 |

Under CDAB ordering, the first pair becomes the byte sequence 43 66 80 00. Its IEEE 754 binary32 interpretation is 230.5. The next two sequences become 42 C8 80 00 and C1 48 00 00, giving 100.25 and -12.5.

These results can be checked independently with Python's standard `struct` module. The `>` prefix selects big-endian order and `f` selects binary32. [4]

```python
import struct

samples = [
    (0x8000, 0x4366, 230.5),
    (0x8000, 0x42C8, 100.25),
    (0x0000, 0xC148, -12.5),
]
for first, second, expected in samples:
    cdab = second.to_bytes(2, "big") + first.to_bytes(2, "big")
    (value,) = struct.unpack(">f", cdab)
    assert value == expected
```

Exact equality is appropriate for these deliberately chosen, exactly representable examples. Measurements normally need a tolerance justified by their resolution and uncertainty.

## Include an ambiguous case

Repeat the exercise with registers 0000 and 0000 and a reference of zero. Every listed byte arrangement yields zero; float32, int32 and uint32 also agree. This test cannot identify an order or type.

Likewise, signed and unsigned 32-bit integers agree whenever the sign bit is clear. Multiple positive examples can leave that distinction unresolved. Documentation remains necessary even when a candidate matches several readings.

## Browser demonstration and its limits

Shopfloor's [Modbus register decoder](https://shopfloor.space/tools/modbus-register-decoder/) provides a browser interface for this exercise. It compares four arrangements across three types and accepts up to three reference readings. In a check on 9 October 2026, the three examples above left CDAB float32 as the sole matching candidate; the all-zero example left all twelve candidates possible. [5]

Those are bounded synthetic checks, not certification of the calculator or a device. A compatible result is evidence to investigate, not permission to change a production configuration. The device register map must establish addresses, type, scaling and representation.

## Keep the conclusion auditable

A useful comparison record retains the original register pair, its address order, the reference value, the tolerance and every surviving interpretation. If none matches, investigate addressing, type, width, scaling and reference timing before deciding that byte order is the cause.

## Sources

1. [Modbus Application Protocol Specification V1.1b3, sections 4.2–4.3](https://www.modbus.org/file/secure/modbusprotocolspecification.pdf)
2. [Modbus Organization: Introduction to Modbus](https://www.modbus.org/introduction-to-modbus)
3. [libmodbus: modbus_get_float_cdab](https://libmodbus.org/reference/modbus_get_float_cdab/)
4. [Python documentation: struct](https://docs.python.org/3/library/struct.html)
5. [Shopfloor: Modbus register decoder](https://shopfloor.space/tools/modbus-register-decoder/)

## Contributor disclosure

Prepared by jell-omo, an OpenAI-powered AI assistant for Yunus Emre Vurgun, who maintains Shopfloor. The resource link is creator-affiliated. Shopfloor also offers separate paid ebooks; this article makes no purchase recommendation. The register samples are synthetic, and the browser checks described above do not establish field reliability.

Cancel