Have you used ModPoll etc to verify the data? If all 0's, it is likely one based (zero based) address setting or reverse word order in the advanced settings of the Modbus device driver (edited in the gateway).
Then try the ones you get non-zero for in Igntion, with a combination of the settings I suggested
Your ModPoll screen shot shows you using unit #1 (Device ID, aka slave #, et cetera). With Ignition's driver, if the unit number is not specified, the driver uses unit #0.
Try [CLM Powder Booth]1.IR3
1 Like
mine must default to 1. if I put a 1.IR3, it's the exact same data.
EDIT: It doesn't seem to matter if a put a 0.IR3 or a 3.IR3, it's exactly the same
So, it seems they are using the high byte of each register, with trash in the low byte. You will need different shifts, and probably should mask each value. Something like this:
toInt(({CS1} & 0xff00) >> 8 + ({CS2} & 0xff00) + ({CS3} & 0xff00) << 8 + ({CS4} & 0xff00) << 16)
1 Like
Thank you you for that.
So far, so good.
didn;t work. 
thank you for the try though!
You're really going to need them to get more involved for this to get figured out. The only other thing I am thinking is there's a piece count coming from the device. If this count increases slowly enough for you to grab a few screenshots and note down the expected value vs what data you're getting, we may be able to find the bits changing (especially if incrementing by 1 each screenshot) where we can track down how the bits are laid out.
Edit: You may also want to switch from using IR3 for example to IRUS3 as I suspect these numbers could be coming across unsigned, and if not, at least we'll be able to see if modpoll and Ignition are matching up.
Edit 2: Here's another tool I've used in the past to allow me to poll registers and log them to screen so I can see the changes. You'd probably want a command line similar to: modpoll -m tcp -r 1 -c 10 -t 3 <IP Address>
2 Likes
D
What specifically didn't work? Is it an error or something else?
I notice you'll have to adjust the tag paths from pturmel's suggestion so they match your actual tag folders, in case that was the issue.
When the conveyor was runnimng the speed went to the billions
I am communicating with them also.. I have asked that they correct the registers to 16bit each to make this actually work correctly.
It might actually be correct now? I dunno. Its not running. My calibration count could be off a little.
I don't think just adding the values with no bit shift is going to give you the right data.
From the recent screenshots you posted it would seem that IR4 and IR6 are not actually related to conveyor speed since they didn't change at all between not running and running. That said, IR6 is different in
this image but I'll ignore it for now.
Furthermore, comparing the first and third screenshots, while running, the low byte of IR3 is always 0000 1010.
In the second and third screenshots, IR5's low byte is 1110 0001 while the high byte changes.
The above seem to match with Phil's idea.
Anyway, that's all the pattern I can spot so far. Maybe try just the high bytes of IR3 and IR5 while completely ignoring the other values.
Here's the boolean, hex, and decimal of the values you would have for IR3-IR6.
Stopped:
0000 0000 0000 0000 = 0000 = 0
0010 1000 0000 0000 = 2800 = 10240
1000 1100 1110 0001 = BCE1 = -29471 (Unsigned = 48,353)
0110 0101 0000 0000 = 6500 = 25856
Running #1:
1011 0011 0000 1010 = B30A = -19702 (Unsigned = 45834)
0010 1000 0000 0000 = 2800 = 10240
1001 0010 1110 0001 = 92E1 = -27935 (Unsigned = 37601)
0110 0101 0000 0000 = 6500 = 25856
Running #2:
1010 0110 0000 1010 = A60A = -23030 (Unsigned = 42506)
0010 1000 0000 0000 = 2800 = 10240
1001 0010 1110 0001 = 92E1 = -27935 (Unsigned = 37601)
0110 0101 0000 0000 = 6500 = 25856
I've been plugging in hex codes in various combinations on this site, but without seeing that the unit is reading, I have no way of knowing if any of the values it's spitting out are valid. Edit: Forgot to post the site: Online Hex Converter - Bytes, Ints, Floats, Significance, Endians - SCADACore
I also noticed that you're dividing by 8464. Was this dictated by the vendor, or were you trying to get your math to work out?
As others have mentioned, you won't be able to just add the values together without bit-shifting them as that's not how this works.
1 Like
I also noticed that you're dividing by 8464. Was this dictated by the vendor, or were you trying to get your math to work out?
This is the calibration count for the encoder this data is coming from
I've been assuming they are sending the raw counts, and not the calculated speed. I could be wrong on that assumptions though