No you can't just invent syntax you hope works.
DWORD is a 32-bit integer, not a double.
You'll have to just bring all 4 registers in (leave off the :8 suffix on the address) and then smash them together in an expression or scripting function.
Heh. That syntax works in my module. 
Well, close. It would be [DeviceName]IR3.0:8 for low bit and width.
1 Like
Modbus Addressing - Ignition User Manual 8.1 - Ignition Documentation (inductiveautomation.com)
I guess I am reading this wrong, because it they are only using the first 8 bits of a 16 bit register, would that not throw off the integer I am actually getting?
That's why you need to bring in the 4 registers as they exist, then create a 5th expression tag that combines them all.
2 Likes
You can make use of the left bit shift << operator and addition to put the parts together.
Something like:
{tag1} + ({tag2} << 8) + ({tag3} << 16) + ({tag4} << 24)
Which tag is tag 1, 2, etc., depends on if they decided to put the least significant byte in the lowest address or not, might have to try different orders and see which one gives you correct numbers.
1 Like
Yeah, I was thinking something like this:
{[~]IR6} << 24 | {[~]IR5} << 16 | {[~]IR4} << 8 | {[~]IR3}
but like you mentioned... they have not specified whether the byte order is little-endian or big-endian.
1 Like
This was their latest response. I guess I am buying an AB PLC
TJ,
I was able to confirm with the software engineer that my table is correct; they have structured things this way so that the data is used consistently regardless if it is converted to Modbus, Profibus, etc. Unfortunately structuring the data this way means that a PLC of some kind will need to sit in-between the Hilscher module and Ignition to concatenate each BYTE into a DWORD. Doing this through bit-indexing is pretty straightforward, but it does require a program running on a PLC to read our Modbus data, concatenate the data into a DWORD, and re-export that to Ignition.
I’ve reached back out to see how difficult it would be for them to modify the current structures in our code to use the full registers, at least for the two DWORDS where it would make sense. I will let you know when I hear a response.
You definitely don't need to buy a whole PLC just for this - some expression tags would handle the byte juggling just fine. You can even set up a UDT if you need it to be reusable.
Now, if you already happened to have a PLC laying around and everyone on premises is more familiar with PLC programming than with Ignition and planned to remain that way for the foreseeable future, maybe there would be something for maintainability there.
This is just bogus. Any competent programmer could lay that buffer into the contiguous bytes that make up 16-bit registers for Modbus. At worst, they might need to perform byte swapping as they copy.
Utterly incompetent.
1 Like
They are still giving me some wrong information somewhere.
2, 3,and 4 never changes, 1 sometimes shows negative numbers like now
When converting to binary, your data becomes:
CS1 (1010 0111 0000 1010)
CS2 (0010 1000 0000 0000)
CS3 (1000 0100 1101 1000)
CS4 (0110 1010 0000 0000)
So, they're using more than just 8 bits per word, but where are those bits coming from?
Edit: Fixed CS3 binary value
1 Like
I got CS3 as 1000 0100 1101 1000 (I'm not sure why this one is unsigned when CS1 is treated as signed, maybe using a 32 bit instead of 16 bit type in tag configuration) but it doesn't change the conclusion. Something is going on.
@Thomas_Salisbury can you show us the tag configuration for these tags?
You're right....I'll update my post too. I must have typo'd something. (Looks like I missed the 8 at the end)
Do you have expected value for these when you took your screenshot of the CS1-4? We might be able to decode the binary to get the expected value to determine byte/word ordering and maybe get some answers.
One other suggestion I have is if it's a Hilscher netTap device, maybe try downloading the software and see if you can extract the configuration off of the device. I don't even know if it's possible, but it looks like their configuration software is downloadable here:
https://hilscher.atlassian.net/wiki/spaces/NETTAP/pages/103777832/Version+history
1 Like
I am expecting somewhere betwwen 8-10 on the cal number. But when it shuts off, its showing 4 still with how I currently have it
What are the OPC Item Paths you ended up using for your CS1-CS4 tags? What expression did you use?
[DeviceName]IR3
[DeviceName]IR4
[DeviceName]IR5
[DeviceName]IR6
({[.]CS1.value}+{[.]CS2.value}+{[.]CS3.value}+{[.]CS4.value})/8464.00
I was able to finally confirm this is supposed to be input registers.. Almost everything is showing 0 though, so obviously they got something wrong.