Sign in to follow this  
Followers 0
Nova5

ModbusRTU fun...

8 posts in this topic

System: EasTech Flowcontrols : Vantage 2220 (RS485 ModbusRTU http://www.eastechflow.com/Vantage2200.asp) Windows 7 USB-RS485 comms device. (http://www.amazon.com/GearMo%C2%AE-RS485-RS422-Converter-Terminals/dp/B005CPI0JQ/) PeakHMI for the HMI. Connected by CAT5E wiring. Used wires from 3 separate pairs negate crosstalk/communication corruption. Wire length is about 60ft. EasTech tells me their device is Big Endian 4321, IEEE Single Precision Floating Point. PeakHMI is configured to match what I have been told by EasTech. Now about the images.. Meter Disp.. is the Physical Meter's Display according to the Vantage DDS software reading. Meter DIsp.png was taken before starting the HMI and setting up the data screen. Meter Disp 2.png was after Capture 3. Capture's 1-3 are the data read by the HMI from the meter. 3 ranges are being read 400011-400012 (S1UINT11) 400016-400017 (S1UINT16) (EasTech wanted me to try this one, the data moves around radically, so its probably not useful other than its already there in the image for them) 400017-400018 (S1UINT) Order of screens from left to right.. Data Table. Unsigned Integer, Integer, Float. What I am trying to determine is if the data is being read right and it doesn't seem to be as no number remotely matches the meter disp numbers.. EasTech's folks are looking over the images as well, just them them these today.. Figured there would be a good chance here some would have a bright idea.. From what I've read 5 vs 6 digit Modbus Addressing is no different until you cross the 9999 number for the lead register set your accessing. 49999 and 409999 is the same, is my understanding of that correct? HMI uses 6 Digit, the memory map EasTech sent me uses 5 Digit. Part of the Memory Map for the FlowMeter.., I've tried to rebuild the table somewhat. "Modbus Address" "Hex Modbus Address" "Variables" "# Bytes" "Description" -----------------------------------------"Format" 40011 ----------------------#NAME? -----------------Flow1 -------- 4 -------Flow Channel1 --------------------------------------- IEEE 40012 ----------------------#NAME? 40013 ----------------------#NAME? -----------------Flow2 -------- 4 ------- Flow Channel2--------------------------------------- IEEE 40014 ----------------------#NAME? 40015 ----------------------#NAME? -----------------FlowSum ---- 4 ------- Flow1 + Flow2 -------------------------------------- IEEE 40016 ----------------------#NAME? 40017 ----------------------#NAME? -----------------TotalCnt1---- 4 ------- Totalizer #1 Count (Most Sign.) --------------- HEX 40018 ----------------------#NAME? -----------------(Least Sign.) 40019 ----------------------#NAME? -----------------TotalCnt2 --- 4 ------- Totalizer #2 Count --------------------------------- HEX 40020 ----------------------#NAME?

Share this post


Link to post
Share on other sites
Okay... this makes no sense... EasTech claims their datatype is IEEE 754 (Single Precision Float, which is 32bits). But in the email from the guy i've been talking with to figure out what is being read and how I get this... I don't see how thats a float datatype... I'm kinda new to this so maybe it is but I doubt it. If it is, is there a standard data range that float is interpreted to be to lose the Exponent?

Share this post


Link to post
Share on other sites
Figuring I'll have to program a math function to run that calculation of (65535* (Value of 400017))+(Value of 400018)

Share this post


Link to post
Share on other sites
The Eastech web page says, "Logging with IEEE 754 precision accuracy". IEEE754 floating point is the format for most, if not all, Modbus floating point. The guy who is using decimal values from the different registers and attempting to shoehorn them into a floating point value is blowing smoke. The format of registers 40001-40002, 40011-40012 and 40009-40010 is clearly IEEE-754 Big Endian, byte format 4321: (attempts to change font to place the hex characters at the appropriate byte fail miserably, so you'll just have to work around the lack of formatting) registers 40011-40012 byte 4 byte 3 40011 0011 1110 0001 1010 (decimal 15898) hex 3 E 1 A byte 2 byte 1 40012 1000 1101 0001 0100 (decimal 36116) hex 8 D 1 4 Big Endian 4321 0x3E1A8D14 = 0.1509288 Byte swap 2143 0x8D143E1A = -4.5680773 E-31 Little Endian 2143 0x8D143E1A = -4.5680773E-31 Little Endian swap 1234 0x148D1A3E = 1.4247712E-26 --------------------------------------- registers 40009-10010 0100 0000 0011 1011 (decimal 16443) hex 4 0 3 B 1111 1110 0001 0000 (decimal 65040) hex F E 1 0 Big Endian 4321 = 403BFE10 = 2.9373817 ---------------------------------------- registers 40001-40002 byte 4 byte 3 0100 0001 1101 0010 (decimal 16850) hex 4 1 D 2 byte 2 byte 1 1000 0000 0011 1110 (decimal 32830) hex 8 0 3 E 0x41D2803E = 2.9373817 -------------------------------------------- There's a floating point converter (Big Endian only) at Schmidt floating point converter if you want to try yourself. I don't know what the values represent because the Eastech site does not post a Modbus manual that can be readily found. Most Modbus masters allow a choice of one of two floating point formats. Whatever you have selected to interpret floating point in your HMI master is not using the 4321 Big Endian format, since it interprets the value with a result nowhere near the correct value. I showed all four format possibilities for the 40011-40012 registers, and only the Big Endian 4321 format makes sense. I'm sure it's that way for all the other floating point registers. Poke around PeakHMI until you find the alternative floating point format selection. Edited by DanW

Share this post


Link to post
Share on other sites
I have found that the data I need is in Totalizer 1(T2 is unused at this location), which claims to be a HEX data format. It looks like its just a decimal number stored in 32bits, so Unsigned Integer SHOULD be what I use, however that doesn't come through right. Floating point is going to eventually fail as a flow totalizer.. larger the number, lower the resolution. Try to add 100 Gallons to a value that will only notice 1000, it won't change. I have attached the Modbus info I got from them. none of the Modbus data that has come through to PeakHMI has made much sense, I could never make anything match up. PeakHMI has these options for the data type.. Float Integer Unsigned Integer Small BCD Default Small = Signed Short Integer Default = Unsigned Short Integer Under its port settings I can set BE 4321 BE 3412 LE 1234 LE 2143 I have it set as BE 4321 according the settings in peakhmi. I'm going to experiment with setting it to other byte orders to see what results I get. 2200 series modbus.pdf 2200modbus.pdf

Share this post


Link to post
Share on other sites
Set it to BE3412 and reads the Unsigned Int correctly. so either that data field is stored as BE3412(wouldn't be sensible to mix Endian types) or the HMI has a problem reading the incoming data from that device properly.

Share this post


Link to post
Share on other sites
The two most common Modbus formats are 4321 and 2134. I don't think I've ever run into the other two. My comment about the BigEndian only refers to the on-line calculator that I was using, I didn't intend to infer that PeakHMI was using BigEndian format, in fact, it isn't, since the values shown in the screen shots made made no sense, whereas the BigEndian format in the on-line calculator did make sense. I misunderstood the totalizer format. I thought that the technique Reg 40017 = 0002 Reg 40018 = 38,799 Totalizer value (2 x 65536) + 38,799 = 169871 was claimed to be IEEE754, which it isn't. But it seems to be a very reasonable method using a count of the number of auto-resets of the totalizer and the current totalizer value to get a grand total. Floating point does bear the burden of the machine epsilon effect as you described, Add 100 when only 1000 is noticeable.

Share this post


Link to post
Share on other sites
Looking at it and working the numbers.. the 2 16bit binary numbers can be used in the way EasTech showed..or just use the full 32bit number. Since a single 16bit binary number has a total value of 65535 the number stored in the lead 16bits of a 32bit number CAN be used as a multiplier of 65536(Maximum value of a 16 bit binary number +1 ). Although that is a bit silly once I looked at it.. thats the normal action of a 32bit binary number isn't it? every time the lead 16 increases by 1 65536 counts have gone through the tail 16bits, "resetting" all bits to 0's and incrementing the lead 16 by 1. reading it as a 32bit unsigned integer will always result in the same number as doing the math they showed.. Since I got proper data I don't need to pull any trickery, simpler is better.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0