Today is...
Monday, June 25, 2018
Welcome to, the global online
community of automation professionals.
Featured Video...
Featured Video
Wiring and programming your servos and I/O just got a lot easier...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Modbus RTU data incorrect
Modbus RTU data does not match real time data from sensor

I am using a modbus poll (master) to access the data in a modbus RTU slave. The data is not showing the real time data showing in the display on the sensor. The sensor is a vortex meter. I've tried every configuration, but it does not work.

For example:
The flowrate = 5 m3/hr
The address for flowrate is 8 = 928...

Please kindly advise !

>The address for flowrate is 8 = 928... <

What do the dots after the 928... mean?

What brand and model vortex meter?

Do any other registers provide correct information?

Which format are you using to read the value? Floating point (also called 'real')? integer?

Have you tried reading register 7 or 9, on either side of 8 to see if the register addressing starts from one or zero?


Hi Carl,

Thanks for the reply. I am using signed and float to read the register. The number is jumping all over and is not stable. Let say for example, temperature is address number 1. And is not showing the right temperature. The meter is made by sierra instruments. I am not really familiar to get the number right.



Have you got the baud rate etc. correct, sometimes if it's not quite on the data can almost look OK.
Suggest you try a really low baud rate until you get it working e.e 1200.


By Russ Bartels on 28 February, 2010 - 12:33 pm

Sorry, no answer, but a suggestion.

Check to see if either the master device or slave has an option to "swap bytes".

a) I tend to expect a flow rate that jumps around. Is the meter installed in a line with such a stable flow rate that you would not expect a variable, jumping flow rate? Having values jump around is rarely, if ever, a Modbus problem.

Having a flow rate to only one significant digit, as in 5 m3/hr, doesn't mean that the flow rate isn't varying between 4.50001 and 5.49999 m3/hr and the Modbus registers reflect such.

b) It is not likely reading in engineering units other than cubic meters, if 928 actually reflects the flow rate Modbus value. I punched in 5 cubic meters in the calculator, here:

and the closest volume in any of the dozens of units available to 928 was 1,321 US gallons, a 43% error, way too high, unless there are other factors going on.

c) FYI, Here's Dan's list of reasons why wrong values appear when reading Modbus registers. I've encountered all of these at one time or another, and it's frequently my fault as much as anything.

When it's possible to read Modbus registers (comm link is working), but the wrong values appear, here are some things to consider:

1) Modbus only gives values from the slave device, which are not necessarily your expectations.

The appropriate comparison is between the Modbus value and the value in the device's local indicator. These values should be identical (or sequential) for any point in time.

It's not a Modbus problem if you think your flow rate is X, but the meter says it's Y in both its display AND in its Modbus register.

2) The value could be in engineering units other than what you expect.

For example, the default engineering units for temperature are F and you expect to see a value in C.

3) Register addressing can be offset by one.
Modbus registers can be numbered from zero or from one. So the register address with the assigned value you are looking for could reside in an adjacent register.

For example, assume all registers are integer values where each successive register has a different value. The "first" value can be at 40000 or 40001. Or the 7th value can reside at 40006 or 40007, depending on how the registers are numbered.

4) The interpretation of the value is done using the wrong floating point format IEEE floating point (FP) value consists of four bytes which reside in two adjacent Modbus registers. There are two common FP formats in use, where each interchanges the byte order.

A floating point value interpreted by the wrong byte order will a different value than the original. Many times the value is off by many orders of magnitude, making it obvious that the wrong format is in use. The choice of byte order sometimes goes by Big Endian/Little Endian, or FP Swapped.

Most Modbus Masters have some means of selecting the alternative floating point format, but you might need to poke around to find it. I ran into an OPC server the other day where I had to call the OPC server's tech support to find it. It just wasn't obvious where the selection was made.

5) Reading only half of a floating point value
Floating point values take up 2 contiguous Modbus registers. If you think the value is an integer and read only half of a FP value, it won't be what is expected, with the possible exception of a value of zero.

6) decimal point assignation
Many Slave devices put the value with a fixed decimal point in an integer Modbus register and assume that the decimal point will be inserted by the Modbus Master device. This situation is usually recognizable as the right value, but a missing decimal point.

7) Modbus map not as advertised
a) error in documentation
b) custom mapping or interpretation of the custom map is erroroneous

8) Stale data
Communications link is not working; data in master is old, stale data.

9) raw data value vs conditioned data value
It isn't always clear whether the Modbus value is a raw data value or whether it is conditioned by the slave's system. Sometimes both are available and the distinction isn't clear

- input n is raw value.
- Process variable (PV) n has ratio and bias applied to it.

10) Right category, wrong specific value
example: certain PID controllers have multiple setpoints, a category of setpoints:
- local setpoint
- working setpoint
- remote setpoint
- 2nd setpoint
- 3rd setpoint
- communications setpoint
- math setpoint

11) Block (multiple register) read by master, misinterpretation of which value is which in the incoming data.

If you are getting data, even if it is goofy, at least you're addressing is valid, even if it isn't the proper address. else the Modbus Protocol would not return any data but only an error reply.

Even if you have a valid address, it may not be the correct one. In addition, you need to make sure that your application is getting the right amount of data. Modbus addresses data in 16 bit integer units, so if you data format is in anything but 16 bit integers, you need to make sure that it is getting the correct number of integers to compose into your final data. Usually client applications have some way of specifying the number of integers you want to retrieve from the Modbus Server (by either specifying a data format or explicitly telling it how many integers you want.) and you need to make sure this is correct.

Floats in RTU's are typically 32 bit floating point values, so you would need two Modbus Registers to get the value.

You mentioned a signed value, but you didn't say signed what...signed long integer, signed integer??? Typically a long integer is 32 bit (2 Modbus Registers) and an integer is 16 bit in an RTU. Signed or unsigned have the same length.

So, say you're addressing scheme is getting the correct number of Modbus Registers for your data, next you've got to worry about whether your addressing scheme uses 0-based or 1-based addresses. The official Modbus Protocol specifies that data addresses start at 1 if I remember correctly. But many implementations start addresses at 0. And to confuse things more, many manufacturers just map Modbus address 1 to their internal address 0. So if you think you've got everything else right, just bump up or down your address by 1 and see if it looks any better. (The datasheets for your software and hardware should specify the offsets, but I've found many of them don't.)

Next, there is the byte order of the data. First of all, there is a Modbus spec for this but many don't follow it. In an integer, for example, data can be stored low byte first in memory, followed by the high byte. Or they can be stored in opposite fashion. So you need to make sure that your software application gets the byte order right.

Finally, assuming byte orders are lined up, you need to make sure your data formats are correct. You mentioned some type of signed data. So you must need to be sure the data from the RTU is signed and not unsigned. For floats, you need to make sure your application uses the same type of floating point number format that your hardware is using.

Fortunately, many commercial software applications give you configurations to adjust for many of these parameters.

For troubleshooting, if the manufacturers of the hardware and/or software don't provide clear direction for setting up the interface, I've found that the most straight forward way of doing it is to find some integer data that I can address. Determine what it should be by some means (via a setup or what not). Then determine what that data would be if the byte order were reversed. In addition, separate the data into its individual bytes. Then try to retrieve the data.

Looking at the retrieved data, if it matches what you expect, good. If it matches the expected data with the byte order reversed, you can reverse the byte order in your software configuration and check that out.

If neither of those work, you should verify that you don't have a signed vs. unsigned integer issue. If either byte has a value over 127, you may have a signed vs. unsigned integer issue. You might try doing a two's complement (invert every bit and then add 1 to the result) of the received integer data (with both byte orders) and recheck the data.

If you still don't have it, you may have the 0-based vs 1-based addressing problem, so go through the above with the address incremented or decremented by one.

If none of this works, your addressing is likely entirely incorrect or the expected data value is not what you think it should be. If you've got the retrieved integer data, note down what its value is in both byte orders and as its twos complement. And then, given your fortunate enough to be able to find out by some other means what the other registers contain (the hardware configuration tool or on screen configuration interface, for example) see if you can find a register nearby with a value that matches the retrieved data in one of the formats you noted down. If so, it will give you an idea of how your addressing is off.

Once you know you can get integer data properly, then you can move onto trying float data, but I've already been longwinded enough and the above will give you a good start on the float data.



If the flow rate is represented as a floating point number, then you will be reading 32 bits of data, which spans two Modbus registers.

When your polling program (Modbus master) puts together the two 16 bit registers into one 32 bit register, you need to make sure that the bit order is the same as used by the flow meter instrument.

Many instruments will let you change the byte and word order, and so will many polling programs.

When the word ordering is flipped, it generally causes the results to swing wildly, which seems to be what you are seeing.

Hope this helps!