I need to has a device react to the 15th bit in the binary representation of a int.
This is what I see in Studio 5000
Here is what I see in ignition
This might be something simple. If so sorry I am new.
The getBit expression function is your friend for bitpacked booleans.
First, pull in your primary tag as an integer. Then create expression tags to pull out individual bits into booleans.
Here's an example I have for a device with lots of bit packed alarms, the {path} is to an integer tag (we call these alarm groups) and then the individual alarms with meaningful names are created with getBit.
getBit({[.]../Alarm Groups/Group 2},5)
For the logix driver, simply make an OPC tag with addressing to the bit level. Put the item path you see in the Studio 5000 tag monitor directly into an Ignition OPC item path in an OPC tag, after the bracketed device name. Like so: [SomeDevice]FV5003_HOA.HOA.HMIbits[0].15
BTW: That looks like a common PlantPax AOI. You should be aware of the performance issues you may encounter with those:
{ /shameless plug }
1 Like
So in my example would I do getBit({[Testing]PPD/Controller:Global/FV5003_HOA/HOA/HMIbits/HMIbits_0_}, 15)?
If you have access to the device via OPC UA and the tag is a tree like @pturmel suggests, then your best bet is to address items in the tree directly via OPC UA.
e.g.{[Testing]*PPD* /Controller:Global/FV5003_HOA/HOA/HMIbits/HMIbits_0_.15 for the 15th bit, and make sure the tag data type is boolean.
getBit() is more for cases where you only have access to the bitpacked integer and can't address the bit directly in OPC UA.
1 Like
Could you give me some steps to do that? are you saying to create a new tag?
Yes.
Ignition's OPC drivers are smart enough to use the request for an integer to satisfy requests for its bits without extra traffic, as long as they are at the same poll rate. The separate tag also provides a path for writing the bit, if that becomes necessary.