Modbus moves data in 16-bit registers, but the values engineers care about - flow rates, temperatures, totalizers - are usually 32-bit floats or long integers that span two registers. The moment a value is larger than one register, you have to agree on the order those bytes and words arrive in, and there is no single universal convention. Get the order wrong and a perfectly good measurement decodes into a wildly wrong number, or NaN. This page explains why the same float can read as garbage until byte and word order are set correctly, and how to line them up.
Register Byte Order (Endianness) in one line: Register byte order, or endianness, is the sequence in which the bytes and 16-bit words of a multi-register Modbus value are arranged on the wire. The Modbus specification defines big-endian byte order within a single register, but it says nothing about the order of registers for a 32-bit value, so devices differ in whether the high word comes first or second and whether bytes are swapped. Until the receiving software applies the matching byte and word order, a two-register float or long integer decodes into an incorrect or nonsensical value.
A Modbus register holds exactly 16 bits, which is enough for a plain unsigned integer from 0 to 65535 but not for the floating-point numbers most process values need. A single-precision float and a 32-bit integer each occupy four bytes, so they are transmitted across two consecutive registers. That split is where the trouble starts. The four bytes have a defined meaning only when both ends agree on which register carries the most significant half and, within each register, which byte comes first.
The Modbus standard does specify big-endian order for the two bytes inside one register - the high byte is sent before the low byte. What it never standardized is the order of the two registers that make up a 32-bit value. One device puts the high-order word in the first register and the low-order word in the second, which is often called big-endian word order. Another device reverses that and sends the low word first, commonly labeled word-swapped or little-endian word order. Some devices further swap the bytes inside each register, giving four possible combinations for the same four bytes.
Because the protocol leaves this open, vendors made different choices and there is no way to infer the correct one from the raw bytes alone. Two registers reading, say, 0x42C8 and 0x0000 could represent 100.0 or a totally different number depending on which arrangement the sender used. The receiving side has to be told, explicitly, how to reassemble the four bytes before it interprets them as a float or long integer.
In practice there are four byte-order arrangements people describe with shorthand like ABCD, CDAB, BADC, and DCBA, where each letter is one byte of the four-byte value in the order it arrives. ABCD is straight big-endian: high word first, high byte first, and it decodes directly. CDAB keeps each register's bytes intact but swaps the two registers, which is the classic word swap seen on many PLCs and flow computers. BADC swaps the bytes within each register but keeps the register order, and DCBA reverses everything into full little-endian. A totalizer or flow value that looks correct in magnitude but off by orders of magnitude, or that appears as NaN, is almost always one of these permutations away from right.
Decoding is a two-step reassembly. First you read the two registers as raw 16-bit words without interpreting them. Then you place their four bytes into a four-byte buffer in the order the device uses, and only then cast that buffer to a float or 32-bit integer. Most SCADA and gateway software exposes this as a per-point setting - a dropdown for word order and byte order, or a single data-type entry like float-CDAB - so you pick the arrangement rather than writing code. The key discipline is choosing that setting per device family, because two devices on the same serial line can legitimately use different orders.
The reliable way to find the right combination is to force a known value. Ask the device to report something you can predict - a fixed engineering value, a totalizer you can read from its local display, or a test register the manual documents - then try the four orderings until the decoded number matches. Vendor documentation usually states the order, but it is common for a manual to be ambiguous or for a firmware revision to differ, so a live confirmation against a known reading is the trustworthy check.
When a flow computer, RTU, or PLC is brought onto a cloud SCADA platform, byte order is one of the first things that has to be pinned down for every multi-register point. A pressure that reads plausibly but a flow rate that decodes as a random large number is the signature of a word-order mismatch on the 32-bit values, not a sensor fault. Because the integer status bits often use single registers and look fine, the error hides specifically in the floats and totalizers that matter most for production accounting.
In a Merobix-style deployment the fix lives in the point configuration, not in the field wiring. Each Modbus point is mapped with an explicit data type and word or byte order, so a device that uses word-swapped floats is decoded correctly at the platform without touching the device. Getting this right once, per device profile, means every value from that device family lands correctly and stays correct as more identical sites are added.
The stakes rise with custody transfer and allocation measurement, where a mis-decoded totalizer is not a cosmetic glitch but a wrong volume on a report. That is why commissioning a new device involves reading a known total from its local display and confirming the cloud value matches before the point goes into service. Confirming byte order up front turns an entire class of silent data-quality problems into a one-time setup step rather than a recurring mystery in the trends.
A 32-bit float spans two registers, and the sending device may order those two words - or the bytes inside them - differently from what your software expects. When the four bytes are reassembled in the wrong order, they no longer form the intended number and can decode as a huge value or as NaN. The fix is to select the matching word and byte order for that point, then confirm it against a value you already know.
A word swap means the two 16-bit registers that make up a 32-bit value are in the opposite order from the default big-endian arrangement - the low-order word arrives first instead of the high-order word. Many PLCs and flow computers transmit floats this way, often described as CDAB order. You handle it by telling the receiving software to swap the words before it interprets the value, without changing anything on the device.
It defines the byte order within a single register as big-endian, so the high byte precedes the low byte. It does not define the order of registers for a value that spans two or more registers, which is why 32-bit floats and long integers vary between devices. That gap is the reason you must configure word order explicitly for every multi-register point.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.