Modbus data not accurate

Hello all,
I am working with a Red Lion G306 and I am reading data from a Batch Controller via Modbus TCP/IP.
The data I am getting is "close" to the data in the controller but not 100% accurate. (See the Snips) I remember reading something about this on the Forum before but cant find that thread.

Let me know your thoughts about this and if there is anything I can do to get the accuracy much closer to the data in the controller.

Thanks!!

Does not look like floating point rounding error to me because it's far too great an error, for all the points. Looks more like data from a previous data run, close, but the same.

Does the batch controller save more than the current run's data?

The Data in the Modbus Map are preset values that I put into the UserFloats. Normally those are set = to internal data registers. I did that just to see if I am getting data as I set up the communications.

The Batch Controller is a demo unit that I built with the same parts as the field unit less the housing. I reinitialize the memory before I programmed it so there are no previous transaction data in memory to come out.

What does Wireshark say when you read the values? That cuts your problem in half - if they are what you set in the batch controller, the problem is in the HMI. If they are different, then the batch controller is not providing correct data.

Floats can be tough to decipher - could take some work to extract the values and convert as they will just be hex numbers in Wireshark - you will have to format/transform properly.

Floats consist of four different words and between platforms they can be in different order. Anyway, this dont look little endian /big endian problem, values would be a lot away of each other.

You need to look values with bit fields. Then you see if some bit is on different place. Put communication speed lower, that way you see if error still exist.

When I've had to sort out this kind of Modbus data encoding, I've turned to the IEEE 754 decoder on this website:

http://babbage.cs.qc.cuny.edu/IEEE-754/

If you've got a generic Modbus Master (Modscan/ Modpoll, ChipKin, Simply Modbus, etc) and fire it up and poll the same registers and see whether the values match Red Lion or the controller.

Easier than decoding Wireshark hex.

Standard single precision floats are 32 bit so 4 bytes or 2 words in modbus. Floating point is not a part of the official modbus standard but a couple of different ways are common:
http://www.digi.com/wiki/developer/index.php/Modbus_Floating_Points

But it a 32 bit float can be represented in different ways as well. Here is one: https://en.wikipedia.org/wiki/IEEE_754-1985

I seconds the suggestion to read them as word using any regular modbus testing software. Check what the float is suppose to be and check what words you are reading (convert into binary).

Thanks for the advice everyone,
I have used 2 different Modbus software tools and get some strange results.

ModScan 64 gives me the data that looks exactly like the Red Lion Data.

Then I used Modbus Poll and the data it gives me matches up exactly with the data in the controller.

See the attached images.

I will do the same test and see what the word data looks like and post that here.

Well I found the problem,
I had the first register in the Tag expecting Crimson to read the first and the second for a float. I had the byte order low to high.
When I put the second word address in the Tag and swapped the Byte order everything started to work great.

For example I was reading 2560 and 2561 for my first float. I put 2560 into the tag and told it that it was a float. I figured it would read 2561 on its own. But to make Crimson work I needed to put address 2561 into the tag and it will read 2560 on its own.

Live and learn. Thanks everyone for your help.

which format is selected in modbus poll for your word order? does it match what is selected in the modscan or red lion?

It wasn't the format as much as what the software expected to see for the first register. I swapped the format a bunch of times in the Red Lion and would either get garbage or the number that was close to the actual data. I even changed the starting register up and down with no luck.

It was looking at the data in word format that made me think that I was starting at the wrong register. So I moved my staring point and swapped the byte order and what do you know, it works

Here is the snip with the word data just incase you are interested.

For those who find this thread and wonder what happened here, I have written out the how first three floating point values were read incorrectly and incorrectly. The problem was reading one word (16bits) from one floating point value and the 2nd word (16 bits) from another floating point value.

The issue is that this could happen to anyone who wasn't sure what the exact value should be because all the values are 'close enough', but 'close' isn't Modbus.

Typically the word and byte swap that are used results in values that are so bizarre that it's an instant flag that something's wrong. But given the range of values, the results here are so 'close' it's scary.

I know if I thought that the flow rate was about 7100 lpm and got 7070, I 'd figure that the flow rate had changed, not that I was reading the wrong registers and making a fake value.

Unfortunately these Modscan screen shot with correct values shows integers in each register, not a floating point that skips each alternate register. So this explanation starts with the FP words as integers, converts to Hex and shows the FP when different registers are combined.

This screen shot shows the intended, correct values:


This screen shot shows the incorrect floating point values:


This screen shot shows the integer values for each register, which I've used to show how reading one word from one FP value and the other word from the next FP value can create his situation:


By reading from (4)2561, the correct values are read:

(4)2560 0 = 0000(h) No read

(4)2561 18026 = 466A(h) 466A 6000h = 15000.0 decimal
(4)2562 24576 = 6000(h)

(4)2563 17696 = 4520(h) 4520 4000h = 2564.0 decimal
(4)2564 16384 = 4000(h)

(4)2565 17999 = 464F(h) 464F 0800h = 13250 decimal
(4)2566 2048 = 0800(h)

When read from (4)2560 (word swapped) the incorrect values are read because one word comes from one FP, the other word comes from the next FP:

(4)2560 0 = 0000(h)
(4)2561 18026 = 466A(h) 466A 0000h = 14976 decimal (incorrect, should be 15000)

(4)2562 24576 = 6000(h)
(4)2563 17696 = 4520(h) 4520 6000h = 2566 decimal (incorrect, should be 2564)

(4)2564 16384 = 4000(h)
(4)2565 17999 = 464F(h) 464F 4000h = 13264.0 decimal(incorrect, should be 13250)

(4)2566 2048 = 0800(h)
(4)2567 17885 = 45DD(h) 45DD 0800h = 7073.0 decimal (incorrect, should be 7100)

Reading this data stream with Wireshark would not reveal a problem because the problem is interpretation of the received data. There was nothing wrong with the received data, the problem is its interpretation. The interpretation of the same, identical data set produces different values depending on the word order and starting register.

Dan,
Thank you for the very detailed explanation!! How do you get the screenshots to actually get into the body of the post??

Here are some more screenshots from my testing using the program Modbus Poll that might help any future members that look this thread.

The question I have about all this is why does one program start reading from 2561 and the other start at 2560 when I selected the start register as 2560 for both programs??

Bullzi said:

The question I have about all this is why does one program start reading from 2561 and the other start at 2560 when I selected the start register as 2560 for both programs??

Click to expand...

That's because modbus PLC addresses start at 1. Some software uses the address while others use an offset. The offset (starting at 0) is what is used inside the modbus protocol. There it's called the starting address. See where the confusion starts?

There are more tricky stuff than this when it comes to modbus though.

Best thing is to put something known on a couple consecutive addresses and then read them. A serial sniffer for serial comms and wireshark and a switch with port mirroring for TCP/IP is what you need for more advanced troubleshooting.