Above the tool
Two holding registers come back as 17142 and 58982. The vendor manual says the value is a float. It does not say in which order the two registers go.
That is the whole problem. The Modbus specification defines a 16-bit register and nothing larger, so every device that reports a 32-bit float had to invent its own way of splitting it across two registers. Four combinations are in the field. Three of them will give you a number that is obviously wrong. One will give you 123.45.
This converter shows all four at once. Paste the registers, read down the column, and take the value that looks like a real measurement.
The four word orders
| Code | Name | Byte sequence |
|---|---|---|
| ABCD | Big-endian | First register high byte first. What the Modbus specification implies |
| CDAB | Big-endian, word swapped | Second register first, bytes in order. Very common on PLCs and drives |
| BADC | Little-endian, byte swapped | First register first, bytes reversed inside each register |
| DCBA | Little-endian | Full reverse. Common on devices with a little-endian CPU and a thin protocol stack |
You will also see these written as “big-endian byte swap” or “float inverse” or “word order: high-low” in vendor documentation. The letters are less ambiguous, which is why the tool uses them.
For 64-bit values across four registers the same logic gives ABCDEFGH, GHEFCDAB, BADCFEHG, and HGFEDCBA.
How to read the result
The tool marks any word order whose float lands in a plausible engineering range. That is a hint, not a verdict — occasionally two orders both produce a believable number.
When that happens, change the process value and read again. The correct order tracks the change smoothly. The wrong one jumps around, because you are watching the exponent bits of one register move independently of the mantissa bits in the other.
That trick works on any device and takes thirty seconds. It is faster than reading the manual.
Reading the tables
Each register on its own shows the 16-bit view: unsigned, signed, hex, and binary. Use this when the value is a plain integer, a status word, or a set of packed bits. Enter a single register and the tool also draws the bit strip, numbered from bit 0 as the least significant bit. Vendor documents that number bits 1 to 16 are offset by one from this — a mismatch that costs people an afternoon at least once in a career.
32-bit value gives FLOAT32, INT32, and UINT32 for all four orders, with the assembled bytes shown so you can check them against a capture. Enter more than two registers and you get one table per consecutive pair.
64-bit value appears once you enter four or more registers, covering FLOAT64, INT64, and UINT64.
As text interprets the bytes as ASCII in both byte orders. Device name and firmware version registers are usually strings, and the byte order there is often different from the numeric order on the same device.
Scaling
Many devices do not send floats at all. They send an integer and expect you to apply a multiplier: a temperature transmitter that reports 1234 for 83.4 °C, or a power meter that reports current in tenths of an amp.
Set the scale and offset fields and the tool adds a scaled column. The math is value × scale + offset. For the transmitter above, scale 0.1 and offset −40.
Get this from the register map, not from guessing. A scale that looks right across the normal operating range can be wrong at the extremes if there is an offset you missed.
Writing a value back
The second tab runs the other way. Enter the number you want in the device, pick the data type, and the tool gives you the register values to write in every word order — decimal, hex, and the raw payload bytes.
Write them with function code 16 rather than two separate function code 6 writes. A 32-bit value split across two single-register writes is briefly half-updated, and a device that acts on the value immediately can do something surprising in that window.
The tool also warns when a FLOAT32 cannot hold the precision you typed. Single precision carries about seven significant digits. Ask for 123.456789012 and the device stores 123.456787, which matters for a totalizer and does not matter for a temperature.
Common mistakes
| Symptom | Cause |
|---|---|
| Value reads 0 or a huge exponent like 1e-41 | Wrong word order |
| Value is close but not exact | FLOAT32 rounding, or a scale factor not applied |
| Value is exactly 65536 times too large or small | Registers read in the wrong order, or an off-by-one in the start address |
| Reading works, writing does not | Device expects function code 16 for the pair, not two function code 6 writes |
| Value jumps between two readings | Reading across the device’s own update boundary — read both registers in one transaction |
| Negative numbers read as very large positives | Interpreting a signed register as unsigned |
That last one is worth a second look. A single register holding −1 reads as 65535 if you treat it as unsigned. The tool shows both columns so the difference is visible.
Frequently asked questions
Why doesn’t Modbus define a float type?
The protocol dates from 1979 and was built around 16-bit registers and single-bit coils. Anything wider is a convention layered on top by the device manufacturer, which is why there is no single answer to how a float is stored.
Which word order is most common?
CDAB — big-endian with the words swapped — turns up most often on PLCs and drives, because it matches how many CPUs store a 32-bit value in two consecutive memory words. But there is no majority large enough to guess with. Check.
Does the register address tell me anything about the order?
No. Word order is a device property, not an address property. The same device usually uses one order for every 32-bit value it exposes, so once you have worked it out for one register you can apply it to the rest.
Can a device use one order for floats and another for integers?
It happens, though it is rare. Strings are the common exception — a device with CDAB floats often stores text high byte first. If the numbers decode and the device name comes out scrambled, that is what you are seeing.
What about 32-bit values that are not aligned to even addresses?
Nothing in Modbus requires alignment. A 32-bit value can start at any register. The pair is whatever the register map says it is, so read the map rather than assuming even boundaries.
Do I need to worry about byte order on Modbus TCP as well?
The MBAP header and the register data itself are big-endian on the wire, and that part is fixed by the specification. Word order is about how the device splits a wide value across two registers, which is a layer above the transport. It is the same problem on RTU, ASCII, and TCP.