Data Precisiom

[pyredex]

So what I have is a pressure gauage that logs its own data. I have Daq polling the gauge as well to bring it all in to a central location for easy viewing. When I download the guage directly and compare it to Daq data.. I get very "jagged" data from Daq. Is there something that I am missing? I am using modbus read input float (4).

Is this a precision issue with Daq?

Do I need some type of conversion?

I have attached a plot to help visualize the problem.

EBOT_Vs_Real_Time_Data.pdf

[AzeoTech]

No, DAQFactory records everything as double precision float, which is 15 to 16 significant figures. The difference is in the hardware. I'm guessing the logged data is oversampled (averaged) and thus a lot quieter, while the DF data you are reading raw. You might try enabling averaging on the DAQFactory channel, perhaps with an average count of say, 10. Also, look at the data spacing in time between the DF data and the logged data. I'll bet the DF data interval is a lot smaller.

[pyredex]

The gauge data is most definately not averaged in any way. The manufacturer has also stated that what is seen on the LCD is actually the same nuber sent via the modbus register i am polling. I can watch DAQ poll and get a different number. It just makes no sense to me. I poll this device with 2 diff. peices af hardware and do not see the same response. They match the gauge perfectly 100 percent of the time.

[AzeoTech]

You may have the wrong I/O type. Try one of the reverse float types.

[AzeoTech]

You also may be off by one on your register. Try reading +1 or -1 for the channel #.

[pyredex]

I sure hate to say it, but I am sure I have the correct register. It's device id 1 register 110 for pressure channel 1. And like I said, it works with other modbus RTU's. I can sit and watch the output proportionally off. the higher the pressure the higher it swings up and down. I don't have a lot of hair left I tell ya . This really makes no sense. Is it possible that I may have to use a conversion? Also on all the other RTU devices I use I/O type "Swapped floating point" This is not an option with DAQ. If I try the other input register io types I get garbage. Oh and sorry for all the typo's folks...

Thanks!

[AzeoTech]

Swapped floating point is the same as Float Reverse Words in DAQFactory, however, what a particular software considers "swapped" is largely based on the CPU and whether its big or little endian, so the fact that other software uses swapped float, doesn't mean DF does. Floating point values aren't in the Modbus standard so neither system is wrong, its just different. Its also possible you need reverse bytes, but this is very rare.

My guess is one of two things:

1) you are, in fact, off by one in your registers and so while you are getting most of the floating point value (the exponent part, plus much of the sig figs), you are picking up a little from a neighboring register. You see this more often with integer types, but it can, sometimes, happen with float.

2) there is a difference in the sampling rate of DAQFactory that is causing hardware issues. If, for example, you were querying your device a lot faster from DAQFactory, its possible that internal circuitry, say from a Mux, can't keep up and you are picking up slewing.

The quickest and easiest way to find out is to look at what the other software is sending as a query to the device and compare to DF. Its easy to see what DF is outputting, just have it only read the one channel, maybe every 10 seconds, then look at the Tx: line in the monitor (with Display all ASCII chars as codes enabled). To view the data from the other RTU's, plug them into the serial port on the PC and have DF watch the serial port. The RTU's won't get a response, but you should be able to see the Rx: line with the query from the device. Post both if you want help comparing.

[pyredex]

First, Thanks for the suggestions!

Here is the code that is sent from one of my RTU's that gets a good data reading

Rx: 010400m0002\22422

Here is what DAQ sends that gets a "close" reading

Tx: 010400n00021622

FYI: I am polling Device ID 1 address 110 (pressure @ Transducer1) RS 485 38400 8,n,1

Thanks for any help!

[AzeoTech]

I'm sorry, but the web (or maybe its just the forum software) doesn't like backslashes. Also, when viewing a binary protocol like Modbus, please select the "Display all ASCII chars as codes" in the monitor. Can you please post a screenshot of the monitor with this selected?

[pyredex]

I have attached a text file with the test repeated. Thanks again for all of your help.

Modbus_log_test.txt

[AzeoTech]

Thanks, that clears it up. It is as I expected, you are off by one. The address is 30,110, not 110. 110 for an input register implies a zero indexed or PDU address, so when you put 110 into DAQFactory, it puts 110 directly into the PDU (the modbus query). If you were to specify 30,110, than DAQFactory would recoginize it as the +1 indexing and strip the 30,000 and subtract one, putting 109 in the PDU as your other logger does.

This is, unfortunately a common point of confusion with Modbus that many manufacturers make worse. The original Modbus spec was designed for non-computer people, and apparently they thought that non-computer people wouldn't like things numbered from 0. So, they came up with this scheme where holding registers all are in the 40,001 - 49,999 range, input registers in the 30,001 - 39,999 range, etc. The thing is, in the actual query to the device, the 10,000 digit is stripped, and 1 is subtracted from the address, so 40,001 ends up as 0 in the query (worse, 40,000 corresponds to command 3, and 30,000 corresponds to command 4, but that's another issue).

This limits a system to 9,999 registers of a particular type (input, holding, etc), even though the query itself is two bytes for address and so can handle 65536 addresses. Some manufacturers that need more than 9,999 registers will put the 4 and 3 in the 100,000's place, so 400,001, just to make things even more confusing.

Over time, many manufacturers recognized this silliness, and would simply document their registers using what I call zero indexed or PDU indexed registers. So, 0 instead of 40,001, 1 instead of 40,002, etc. This is the exact value that is put in the Modbus query and is, in my, and many other's opinion, much less confusing.

Alas, because DAQFactory is used with a wide variety of devices and we want to keep you from having to think about it too much, we generally handle both types. If you tell DAQFactory to read a holding register 40,001 it will recognize it and strip the 4 and subtract 1. It would be the same as telling DF to read holding register 0. In almost all cases, this works fine, and there's a work around if you have zero indexed registers that are actually in the 30,000 or 40,000 range (simply ask DF to read a random register in the 50,000 range), but having this many registers is rare.

OK, that all said, your other logging program is especially silly that it took the input register address 110 and translated it to 109. It should have left it alone at 110 because using the Modbus standard notation (the 40,001 notation), 110 doesn't exist for an input register because all input registers must be between 30,001 and 39,999 using this notation. 110 is only valid for an input register if you are using zero / PDU indexed numbers.

That all said, the reason you almost correct values is that floats are actually two consecutive registers and you are getting the correct register for 2 bytes of the reading (110), but the wrong register for the other 2 (111 instead of 109). This causes the number to be off just slightly because of the way floats are formatted in binary (I refer you to the web for that one).

So, to fix, just tell DF to read register 109 instead of 110 (or 30,110), and then flip the words (or don't if you have it flipped now).

[pyredex]

Thank you very much for the detailed reply. I am now able to better understand what was happening. I do see your point on how some consistancy between manufacturers could definitely help...

Alas, I was able to get it working properly. This will help me alot. The level of service here is wonderful and a big thanks to Azeotech!