Counters, run-hours, and totalizers do not fit in a single Modbus register, so they are carried as 32-bit integers spanning two consecutive registers, and the order in which those two halves are joined is not standardised across vendors. Get the word order wrong and the total comes out as garbage or, for a signed value, as an implausible negative number, even though the communication is perfectly healthy. This page focuses specifically on 32-bit integers rather than floats: what high word and low word mean, the four decode permutations that arise, and how to pick the right one using a known reference value.
Modbus swapped 32-bit integer in one line: A Modbus 32-bit integer is a counter or totalizer value too large for one register, so it is split across two registers as a high word and a low word, and there is no universal rule for which comes first. If the driver joins the words in the wrong order, or swaps the bytes inside them, the decoded integer is wrong, often a huge or negative total rather than an obvious error. Because byte order and word order are independent, there are four possible arrangements, and you select the correct one by decoding a known reference value until it matches.
A single Modbus register holds sixteen bits, which can only count up to 65535 as an unsigned value. That is far too small for the numbers many devices need to report: a totalizer accumulating flow, a counter of pulses or events, an equipment run-hours meter, or an energy total will all exceed sixteen bits quickly. To carry them, the device uses a 32-bit integer, which spans two consecutive registers and can represent values into the billions. This lets a counter keep climbing for a long time before it rolls over, which is exactly what totalizers and run-hour meters need.
When a value is split this way, one register carries the more significant half and the other carries the less significant half, usually described as the high word and the low word. The high word holds the larger place values and the low word the smaller ones, and the true 32-bit number is reconstructed by combining them in the correct order. This is the same splitting used for 32-bit floats, but the interpretation differs: an integer is decoded as a whole number rather than as a floating-point value, so the failure mode looks different when the order is wrong.
The catch is that Modbus never fixed a universal rule for which register carries the high word and which carries the low word. Some devices place the high word in the first register and the low word in the second, and others do the reverse, and both are common. This means a driver has to be told, per device, how that particular device orders its words, because there is no way to infer it from the protocol alone. That freedom is the root of the swapped-integer problem: a perfectly transmitted pair of registers can still decode to the wrong number if the driver assumes the wrong order.
Two independent choices determine how the four bytes of a 32-bit integer are assembled, and together they produce four possible arrangements. The first choice is word order: which of the two registers is the high word and which is the low word. The second choice is byte order: within each sixteen-bit register, which of its two bytes is the more significant. Because these two questions are independent, combining the two word orders with the two byte orders gives four distinct permutations, and only one of them reconstructs the number the device actually intended. The word-swap and byte-order concept pages describe these two axes; for integers the point is that all four combinations can occur across different equipment.
The symptom of the wrong permutation depends on the kind of integer. For an unsigned 32-bit value, a swapped word order typically produces a number that is wildly too large or too small compared to the real total, because the significant and insignificant halves have traded places. For a signed 32-bit value the effect can be more deceptive: a wrong order can flip the value into a large negative number, so a run-hours meter or a totalizer that should only ever climb suddenly reports a negative total, which is a strong hint of a word or byte order fault rather than a genuine reading. Byte swaps within the words cause similar corruption on a finer scale.
What makes swapped integers particularly dangerous compared with swapped floats is that the wrong answer often looks like a plausible number rather than an obvious NaN. A float decoded with the wrong word order frequently comes out as not-a-number, which is easy to spot, but an integer always decodes to some whole number, so a badly ordered totalizer can quietly report a believable-looking but wrong cumulative value. That is why totalizers and counters demand extra care: a silent word-order error corrupts cumulative data that may feed volume tracking or reconciliation, and it will not announce itself the way a broken float does.
The reliable way to choose among the four permutations is to decode a known reference value rather than to guess. Read the same total on the device's own display, or use a point where the counter is at a value you can verify, and try each of the four arrangements in the driver until the decoded number matches the reference. Because only one permutation reconstructs the true value, matching a known number confirms the order unambiguously, and once you have found it for a device you can apply it to every 32-bit integer that device reports. This is far more dependable than assuming an order and hoping the numbers look right.
It is also worth checking the value at a moment when the counter is changing, because a static match can occasionally be a coincidence. Watching the total increment by the amount you expect, rather than merely matching once, proves that both the word order and the byte order are correct and that the low word is rolling into the high word properly. For a totalizer this is the real test: the number should climb smoothly and by sensible increments, not jump erratically or run backwards, and a permutation that produces smooth, correct increments is the right one.
In SCADA and cloud monitoring, getting integer word order right is a data-integrity issue with lasting consequences, because totalizers and run-hours feed things people rely on: cumulative volumes, energy totals, maintenance intervals, and sometimes reconciliation between sites. A cloud SCADA platform such as Merobix will faithfully store whatever the driver decodes, so a silently swapped totalizer corrupts the historized totals from the moment it is configured, and because the wrong value looks plausible it can go undetected for a long time. The safeguard is to validate every 32-bit integer tag against a known reference at commissioning and to sanity-check that totals only ever climb, so the cumulative data a remote site reports can actually be trusted.
A 32-bit integer spans two registers as a high word and a low word, and Modbus does not fix which register carries which, so if the driver joins them in the wrong order the decoded number is wrong. For an unsigned value that usually means a wildly too-large total, and for a signed value it can flip to a large negative number, which is why a totalizer that should only climb suddenly reads negative. Try the correct word order against a known reference value.
Four. Two independent choices produce the permutations: the word order, meaning which register is the high word, and the byte order within each register. Combining the two word orders with the two byte orders gives four arrangements, and only one reconstructs the number the device intended. You find the right one by decoding a value you can independently verify until it matches.
A float decoded with the wrong word order often comes out as not-a-number, which is obvious and easy to catch. An integer always decodes to some whole number, so a badly ordered totalizer can quietly report a believable-looking but wrong cumulative value that no one notices. Because totalizers and run-hours feed volume tracking and reconciliation, that silent error corrupts cumulative data, so integer tags deserve extra validation against a known reference.
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.