This is the fault where everything looks healthy except the number itself. The device answers, there is no timeout, no exception, the tag shows good quality, and yet the value is nonsense: negative when it should be positive, wildly too large, or off by a neat factor of ten or a hundred. When comms are clean but the reading is garbled, the raw bits are arriving correctly and the problem is in how your driver is decoding them. This guide walks the decode fixes in order, from byte and word order to floats split across two registers, signed versus unsigned interpretation, and plain scaling errors, so you can turn the garbage back into the value the device meant to send.
Fix a Modbus wrong register value in one line: A wrong or garbled Modbus value when comms are fine means the bytes are arriving correctly but the driver is decoding them wrong. The usual causes are byte or word order that does not match the device, a 32-bit float or integer split across two registers reassembled in the wrong order, a signed value read as unsigned or vice versa, and a missing or wrong scaling factor. Diagnose by comparing the decoded number against a known reference reading and adjusting the data type, word order, sign, and scale until it matches.
The defining symptom is that the transport is healthy but the value is wrong. You are getting a response every poll, the tag quality is good, and no exception is coming back, so the request reached the right register and the device returned data. That immediately rules out the whole family of addressing and timeout faults and confines the problem to interpretation. The bits in the register are almost certainly correct; what is wrong is the recipe your driver uses to turn those sixteen or thirty-two bits into a number.
The specific way the value is wrong is a strong clue to which decode is off. A reading that is close to right but shifted by exactly a factor of ten, a hundred, or a thousand points at a scaling error rather than a byte-level problem. A value that is negative when the process cannot be negative, or that jumps to a huge number near the top of the range, points at signed versus unsigned confusion. A number that is complete gibberish, changes wildly for a small real change, or shows up as NaN points at word or byte order, especially on a value that spans two registers. Reading the flavour of wrongness narrows which fix to try first.
The single most useful diagnostic move is to establish a reference. Read the same value on the device's own local display, or command the device to a known state, so you have a true number to decode toward. With a reference in hand the whole exercise becomes deterministic: you adjust the decode and see whether the number converges on the truth, rather than guessing in the dark. Note the raw register contents your driver received, because the same raw bits decoded four different ways is exactly how you distinguish a word-order problem from a sign problem from a scaling problem.
Any value larger than sixteen bits spans two registers, and how those pieces are ordered is the most common cause of garbage. There are two independent questions. The byte order is which of the two bytes comes first inside a single sixteen-bit register, and the word order is which of the two registers comes first when they are joined into a thirty-two-bit value. Because these are independent, the four bytes of a thirty-two-bit value can be assembled in one of four permutations, and only one matches how the device laid them out. Pick the wrong permutation and you get a wildly wrong number or, for a float, a NaN. The byte-order and word-swap concept pages describe the mechanism; the fix in practice is to try the permutations against your reference value.
For a 32-bit float split across two registers, this is unavoidable because there is no universal ordering convention across vendors, so a float that reads perfectly on one device may need the words swapped on another. The tell is a float that is nonsense or NaN despite good comms; the fix is to flip the word order in the driver, and if still wrong, the byte order, until the reference value appears. Many drivers expose this directly as a data-type choice such as float with word swap versus float without, and choosing the right variant is usually the entire fix. The dedicated float-across-two-registers concept page covers this case in depth.
The same ordering problem applies to 32-bit integers, but the symptom looks different because an integer decodes to a plausible-looking wrong number rather than NaN. A run-hours counter or a totalizer that spans two registers with the words swapped can read as a huge or negative total that is not obviously garbage, so it is easy to miss. Treat any two-register integer the same way: confirm the word order against a known count, and only trust the total once the decode matches the device's own displayed value. Getting a totalizer word order wrong silently corrupts cumulative data, which is far more damaging than an obviously broken reading.
Signed versus unsigned interpretation is a subtle decode fault because both readings look like real numbers. A single sixteen-bit register can represent a signed value, running into negatives, or an unsigned value that only goes positive, and the same bits mean two different numbers depending on which you choose. The classic symptom is a value that reads correctly across most of its range but flips to a large positive number, or to a negative number, at one end. A temperature that should read a small negative in winter but instead reads a huge positive is a signed value being decoded as unsigned. Match the driver's data type to whatever the vendor map specifies, and verify at a point where the sign actually matters.
Scaling errors are the easiest to spot and to fix once you have a reference. Many devices send an integer that represents a scaled value, so a pressure of 12.34 might arrive as the integer 1234 with an implied divide-by-one-hundred, or a value might carry an engineering-unit multiplier the vendor documents. If your reading is a clean factor of ten, a hundred, or a thousand away from the truth, the scaling factor is missing or wrong, not the byte order. Apply the multiplier or divisor the vendor map specifies, and confirm the value lands on the reference. Because scaling errors produce a plausible-looking number, they can sit undetected until someone compares against a local gauge, which is another reason a reference reading is the anchor for the whole procedure.
For SCADA and cloud monitoring, a wrong-value fault is more dangerous than an obvious comms failure precisely because the tag looks good. A garbled number with good quality flows straight into trends, alarms, reports, and any control that consumes it, and a silently swapped totalizer can corrupt cumulative volumes that feed billing or reconciliation. A cloud SCADA platform such as Merobix will faithfully store whatever the decode produces, so the safeguard is to validate every scaled or multi-register tag against the device's own display at commissioning and to sanity-check ranges afterward. Locking down data type, word order, sign, and scale before a site goes live is what keeps the remote numbers trustworthy, since no operator can eyeball a gauge at a site they never visit.
Good comms with a wrong value means the bits are arriving correctly but the driver is decoding them wrong. The usual culprits are byte or word order for values that span two registers, a float or integer split across two registers reassembled in the wrong order, a signed value read as unsigned, or a missing scaling factor. Compare the decoded number against a known reference and adjust the data type, word order, sign, and scale until it matches.
A float spans two registers and there is no universal word order across vendors, so a float that reads fine on one device may need the words swapped on another. Flip the word order in the driver, often exposed as a float-with-word-swap data type, and if it is still wrong, try the byte order too, checking against a known reference value each time until the correct number appears.
That is usually signed versus unsigned confusion. The same register bits mean different numbers depending on whether the driver treats them as signed, which allows negatives, or unsigned, which only goes positive. A value that reads correctly through most of its range but flips to a large positive or a negative at one end is being decoded with the wrong sign; match the driver's data type to what the vendor register map specifies.
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.