SQLTags - Call out BITS within an integer SQLtag please :)

In order to reduce tags that are on scan to a PLC, I would like to see the ability to be able to call out individual bits within an integer SQLtag. Using an DINT as an example, this would mean I could use 32 bools from a single DINT SQLtag.

SQLTag_Status.01
SQLTag_Status.02
SQLTag_Status.03
.
.
.
SQLTag_Status.31

We do this a lot with competitors software because they license by tag counts. By packing 32 bools within the single DINT tag, we gain 31 “tags” without taking a hit on the tag license and it reduces the communications overhead to the PLC.

Currently, I have two DINT tags for each field device in my control systems. 1 tag is a STATUS DINT tag and another is a CONFG DINT tag. Between these two tags, I have 64 bools that I can use for device status and configuration.

With Ignition I have to create each boolean SQLtag to get the same 64 bools. Instead of 2 tags on scan for each device in the PLC, I now have 64 tags on scan. Larger systems this overhead grows exponentially.

If I have 1000 devices, 2000 DINT tags can provide me all the information I need, but because with Ignition I have to define each boolean I have 64,000 SQLtags on scan to get the same information!

Please consider this, thank you!

You can do this using the getbit function in a expression tag

getbit({[.]alarmint1},0)

where alarmint1 is the integer tag that I poll from the plc and 0 is the bit location.

Thank you Diat150, unfortunately it’s my understanding that the getBit method is only good for reading the value not writing to it. So I’ll keep my individual bit tags as I have them, but thank you for the suggestion.

Did you happen to see this thread?

Jordan -

That is essentially what I have created in my UDT. And everything works as I expect it to. But as I understand it, each bit within that UDT is scanned as an individual SQLTag per the configured scan class. It’s just an efficiency consideration that is all. Why scan 32 tags when you can scan a single tag and get the same information?

I’m new to Ignition, so I’m just correlating past experience with new technology. Scan classes provide a lot of flexibility which ease my concerns, but experience tells me if you can find ways to be efficient, travel that path.

It’s similar to Boolean tags in a ControlLogix. Boolean tags are inefficient as it uses 32bits of memory just like a DINT tag, so I never use boolean tags in my PLC.

Thanks for the thread reference!

[quote=“Paullys50”]But as I understand it, each bit within that UDT is scanned as an individual SQLTag per the configured scan class. It’s just an efficiency consideration that is all. Why scan 32 tags when you can scan a single tag and get the same information?[/quote] I think this is actually dependent on the OPC server and driver, not Ignition. I’ve had some conversations with Kepware on their AutomationDirect OPC server. When Ignition asks for a bit of word, Kepware grabs the entire word and parses out the bit and sends it back to Ignition. So if all the bits are in the same word, then Kepware only has to grab that word, it doesn’t make multiple calls to the PLC for each bit of word.

Pat, you bring up a valid point. I am using the Igntiion OPC-UA server communicate with a ControlLogix, and based on the status information of the Ignition driver, it does show each bit as a separate item in the log, so it does appear that the Ignition driver is treating each bit as an individual tag, but I’m not sure if that reflects the functional operation of the Ignition driver or not.

Interesting about Kewpare though.