How to Fix a Modbus Value Off by a Factor of Ten

Back to Blog

Confirm the Error Is a Clean Power of Ten

First make sure the factor really is a tidy power of ten, because that is what points at an implied decimal rather than something messier. Compare your SCADA value to a trusted reference - the field gauge, the device display, a calibrated reading - and divide one by the other. If the ratio is almost exactly ten, a hundred, or a thousand, you have an implied-decimal problem. If the ratio is some odd number like 1.8 or 6.9, you are looking at a different scaling issue, likely a unit conversion or a wrong span, handled under fixing a Modbus scaling mismatch rather than here.

The reason a power of ten is diagnostic is that devices routinely avoid sending fractional values over Modbus, which carries only integers, by scaling the reading up by ten or a hundred so the fraction survives as whole counts. A device measuring 34.5 degrees sends 345 and expects the master to divide by ten. When that division is missing, the error is exactly the factor the device multiplied by, which is always a clean power of ten. Confirming the ratio is that clean rules out the harder faults and points straight at the decimal.

Read the Device's Implied Resolution

Find how many decimal places the device implies, which its register map states as a resolution, scale, or units-per-count figure. A map entry saying the value is in tenths of a degree, or that resolution is 0.1, means divide by ten. Tenths of a psi or a scale of 0.01 means divide by a hundred. Some maps show it as an explicit multiplier of ten or a hundred that you must invert. Locating and reading these columns is the register-map skill described under verifying a Modbus register map against device docs.

If the map is silent on resolution, recover the divisor empirically. Take the raw integer your tag reads and the true value from a reference, and divide the raw by the true value: a raw 345 against a true 34.5 gives ten, so divide by ten. This works precisely because implied decimals are always clean powers of ten, so the recovered divisor lands on 10, 100, or 1000 with no ambiguity. Note that figure as the device's resolution so it is documented for the next tag from the same device.

Apply the Divisor and Check for Double Division

Set the recovered divisor as the tag's scale factor - a gain of one tenth to divide by ten, one hundredth for a hundred. Before you accept it, make sure you are not now dividing twice. If a gateway or a calculated tag already applied part of the decimal correction, adding another divisor overshoots and the value swings to the opposite error - now a hundred times too small instead of ten times too big. Check the whole path from register to display for any existing multiplier before adding yours, the double-scaling caution that also applies under engineering units scaling in SCADA.

Keep the divisor in one place, the tag's scaling settings, rather than splitting it between the driver and a display format string. A display that shows one decimal place is only formatting the number, not scaling it, so formatting a 345 to show 345.0 does not fix anything - the underlying value is still ten times too big. The real fix is the arithmetic divisor on the value itself, applied once, in the scaling layer where the next engineer will look for it.

Verify With Two Points

Confirm the fix at more than one value, because a pure factor-of-ten error corrects with a gain alone and a single matching point can look right for the wrong reason. If the device display reads 34.5 and your tag now reads 34.5, check a second value - drive the process to a different point, or find another reading, and confirm it also matches after the divide. Two matching points across the range prove the divisor is right and that there is no residual offset masquerading as a scale error.

Then watch the tag live. A value that tracks the field reading up and down, staying a factor of one - not ten - away throughout, is a fixed decimal. If it drifts back to a factor at the extremes of the range, the problem was never a simple implied decimal but a full span mismatch, and you should return to the broader Modbus scaling mismatch procedure to reset the endpoints. A clean power-of-ten fix holds across the whole range or it was not the right diagnosis.

Frequently Asked Questions