“In order to do this, you MUST specify a SQLTag in Ignition for each BIT you wish to reference You cannot do a bit reference like this on the Ignition SQLTag name, it as to be done at on the tag OPC path.”
I found the above post from 2014 in searching the forum. Is this still the case? I have existing PLC programs that extensively use Arrays of DINTs (v32) for all HMI comms. So a conveyor will have a tag:
HMI[0].0 start pb
HMI[0].1 stop pb
HMI[0].2 running status
etc
HMI[1] will contain the same format for the next conveyor
I can drag the HMI DINT[100] from the OPC browser to a tag folder and it creates 100 tags in the format
HMI_0_ (linked to HMI[0])
HMI_1_ (linked to HMI[1])
HMI_2_ (linked to HMI[2])
etc.
all of type INT4. However in any animation/control, referencing the tag HMI_0_.x doesn’t work. The only method I’ve found that works is the above initial statement…manually creating Boolean tags such as:
HMI_0_0 (linked to HMI[0].0), etc.
So now I’m faced with converting 100 DINTs to 3100 Booleans, which not only makes the Tag browser large to browse, but I would assume puts 3100 items instead of 100 on the comm stack. I was excited to start using Ignition, but this seems a large failing if this is the only way. I don’t understand that if the value of a DINT is already updated in an SQL tag, why it’s not available to access the .0 to .31 bits of that value, instead of creating 31 individual SQL tags.
If I have to bite the bullet and do this, what’s the best JSON editor to maintain the format that Ignition expects? Using Wordpad opens it fine, but no matter what format I chose to save an update to, Ignition doesn’t like the format and errors out.
I’m really new to Ignition as well, but your data type might be the trick. Can you change the data type from int4 to a bool? I think there’s a way to specify different data types in the sql table.
You’ll set this parameter to OPC address up to “HMI[0]” for each instance. Put all the bool tags for that device under it (with names like “startPb”, “stopPb”, etc.). In the bool members’ OPC address, put {rootAddress}.# (substituting bit number for “#”).
Now to setup the next instance, all you need to enter is a name for the UDT instance (device, like “Conveyor1”) and set the rootAddress parameter. The rest takes care of itself. For a large number of tags, scripting the tag creation is the quickest way.
Robb, thanks for the response. I can change the datatype through the tag editor, but that’s simply changing one DINT tag to one BOOLEAN tag, not creating the 32 tags I need to reference the 32 bit locations on the DINT.
Witman, I think I’m following you. Pretty ingenious. Similar to how I dynamically create indirects by passing a ‘word address’. I had googled a bit about UDT’s, but since that terminology is also used in ControlLogix, I mistakenly assumed the UDT had to be created on the PLC side. I have that option of rewriting the PLC code, replacing all the DINT elements with a UDT type and pulling that into Ignition, which if I were starting from scratch would be the preferred method I think. But your method is pretty slick as a workaround.
Yes, we don’t pack DINTs anymore in PLCs but there’s plenty of old stuff around we still have to work with that does–as well as good old SLC code. At this point we use the same Ignition UDTs for the same type of devices regardless of what the PLC code and tags look like, utilizing tag property overrides in Ignition and scripted tag creation.
Our UDTs in Ignition reflect our current PLC UDTs, however we can override and disable parts of the UDTs as needed (via scripted tag creation) to shoehorn SLC tags into the same UDTs. This makes reusing templates in Ignition really easy–our front-end looks nearly the same regardless of what PLC code/tags are behind it–we just have some features disabled in the old stuff via disabling those UDT members and the components are setup to adapt as necessary. This is one of my favorite things about Ignition.
Actually, you'll get one item on the wire that gets all of those DINTs, as long as they are all subscribed at the same pace. Having two or more tags in Ignition that read from the same underlying OPC item will be optimized into a single read. Similarly, adjacent and near-adjacent elements of PLC structures and arrays will be read as a unit and the data passed out to all subscribers.
There’s also the getBit() expression function you can use to read the but from an integer value. Better in my opinion to have actual tags with proper descriptive names though. Also good to use symbolic named plc addresses as well, for ease of dev at least and maintenance. Using arrays however will certainly hell with performance though
So, I took everyone’s advice and went a couple of combined routes. I ended up just rewriting a bulk of the code in the two PLCs and just added my HMI bit control/status to the existing Motor UDTs in CLX. So, now I can just drag over the motor tag from the OPC into the browser and have everything I need. I still kept about 10 general purpose HMI_Bits in an array of 10 DINTs and created an Ignition side UDT and used the multiple instance wizard to create 10 tags with 16 bits as a defined data type. That works really well too.
What I have now noticed is that the OPC browser for both PLCs is still showing HMI_Bits as an array of 100 DINTs instead of the truncated 10 DINTs that I reduced the tag to in CLX. The OPC browser is showing the new .members in the updated UDTs, so the OPC has refreshed. I’ve also noticed that there are some random tags appearing in the OPC that used to exist but have long been deleted from CLX. Thinking it might be a residual memory issue with CLX, I went ahead and did L5K imports to clean up the DB and download. But the DINT array still shows as 100 elements and the unknown tags are still present in the OPC browser. Doing some forum searching, I tried going into the OPC device for each PLC and doing a SAVE and then OPC refresh, but these tags persist. I assume this is an UA OPC Driver issue or maybe even a CLX issue, but short of deleting the OPC Device and recreating, is there anything else to try?
Just a followup, not sure what changed or was the actual refresh event, but the plant had a planned outage for maintenance, and on reboot of the Ignition server, the OPC databases sync’d up and were correct now with the long deleted tags gone, and the DINT array the correct size.
