Does anyone know why this number, which is a 16-bit integer:
Looks like this in Groov:
Here is my tag config:
Does anyone know why this number, which is a 16-bit integer:
Looks like this in Groov:
Here is my tag config:
Because it is not a 16-bit int as 3272833 won’t fit in 16 bits. Try setting up as a 32-bit.
I don’t know what tool you’re using in the screenshot above, but I see “Decimal” in the data format up there; could that be confusing things?
The decimal thing is a drop down which gives you a choice of decimal or hex.
Here is what a 32-bit number looks like:
Once we switch into 32-bit numbers it could be a byte order thing. Modbus doesn’t specify a byte order for values larger than 16 bits, and figuring out which it should be for a particular device can be annoying. (Whether devices use 0 or 1 based register addressing is another sticky point.)
In your Modbus device config with groov View, try toggling the “Lower register contains the least significant part of 32-bit values” option here:
Is there a problem with that number? 2800812 is in the same magnitude as your original post - maybe there is more numbers there - resizing the field will be helpful.
Tried all of the above. No luck. I think the problem may be the device. I’m going to try a different register that I’m sure is a 32-bit unsigned integer.
I’ll let you know.
As I suspected, the problem seems to be reading our Modbus device:
I will have to talk to the manufacturer.
A little more investigation revealed that Node-Red will only read five digits correctly. If I change my register to a six digit number it fails.
For you guys that understand all this 16,32,64 bit stuff, does that mean anything to you?
Second question: My Groov still has a number from an hour ago in that tag. How often does Groov read a Modbus device and update those fields?
Thanks
16 bit uint range is 0 to 65535
Sounds like this is a 32 bit (u)int and you are reading the lower 16bit of a little endian device.
By fail - do you mean you get a different # than expected?
Can you give us the value you expect, the value you get from Node-Red and the value of the very next 16 bit register?
I suspect your number is in 32bit modbus little endian (16 bit registers are big endian, then two 16bit registers are stored little endian style - bit more unusual, but not unheard of).
I can give you the first two, the Banner device doesn’t give me that option for the third. The next register is separate and has a value from a different input;
The number I expect: 3319537
The number I get from NR: 42737
From the manufacturer’s literature:
“Local registers 1-845 are 32-bit unsigned integer based registers.”
42737 is the least significant 16 bits of 3319537, so that makes sense.
Modbus registers are only 16 bits, since they are storing 32 bits, the next register is used as well and will have the most significant 16 bits of your 32 bit number. If you have the Banner device writing something else to that register, then your number is getting clobbered.
Register 400860 - contains the LSB - bits 15 through 0
Register 400861 - should contain the MSB bits 31 through 16
If you configure the Banner device mapping to place data in particular register, then you can’t be writing something else to 400861 since the 32 bit value needs that register too. Make sense?
That’s not true when it comes to the way Banner has set up their registers. We write consecutive registers on a regular basis. Our application wouldn’t work if that were the case.
These are registers we read and write to turn on valves and read pressure switches. I don’t know what goes on behind the scenes but it works the way I’ve described it.
From the behavior I’m seeing I have to think these are 16-bit registers and the docs are wrong. Banner has a series of floating-point registers which are 32-bit and they don’t have consecutive registers, they’re numbered every other one.
It does beg the question, however, how the Banner device can display a 7 digit number.
The valves and pressure switches are most likely modbus coils and discretes - they are in a different part of the address map so there is not conflict with them having the same register number as a holding or input register.
The consecutive registers from 859 on up can’t be modbus registers - they just don’t work like that. Those registers are storing 32 bits, but a modbus register can only store 16. Maybe “local register” means something in Banner speak - is there a place to map those to modbus registers?
From the Banner DXM docs:
The processor’s local registers are divided into three different types: integer, floating point, and non-volatile. When using local registers internally, the user can store 32-bit numbers. Using local registers with external Modbus devices follows the Modbus standard of a 16-bit holding register. Local registers are accessible as Modbus ID 199
Looks like they may only give you access to the lower 16 bits. That’s pretty bad IMHO. Do you have something setup that is specifically writing this value there? Could you spread it into two registers? I also noticed that the register you are using is a flash register that has limited writes - just FYI.
Where did you find that? You put me to shame as the supposed Banner expert in our group. 
Banner does have it’s shortcomings, that’s for sure.
We could probably spread it into two registers but that might be difficult. I think what we may end up doing is convert that large number (those are gallons) into acre/feet.
I appreciate everyone’s help as it’s made very clear how Banner implements their Modbus “registers”
Here is what they look like to Modbus Poll:
I found that in this manual → ValinOnline.com: Process Control, Filtration, Motion Control & Automation Products on Page 4
If you convert the signed int16 -22799 to hex, you will get 0xA6F1 which is the same as 42737 if unsigned.
What you are wanting is 0x0032A6F1, so the 0032 part it is not getting to you.
