Not really relevant to this post since not in 8 yet, but 8.0.5 introduces wildcards in the tag change event script area, so now may not have to add paths to this, assuming you can wildcard all your paths, present and future
2 Likes
This is what you need to do for literally any template or popup window that needs indirection, and is something most Ignition projects would be using. It's not some uncommon beast, and as @witman said, you should make this process easier by defining a custom property on the root container that defines the path to your UDT instance.
Personally, I would normally define 3 custom properties on the window root container:
_deviceName, _deviceParentPath, and deviceTagPath
The latter is bound to the former 2 combined together (see reply below). The underscores for me define properties I need to pass into a Window; no underscores means they may be bound. Using these 3 tags simply makes it easier to change the device without having to try to get to the end of a potentially long full path. It also means you have access to the device's name without having to script it out of the full path.
Please bear with me on this. I have gone down the path of creating a UDT with all the PLC tags in it. Then created an instance for each Device I have. More instances will be added as more devices are brought online. On each window, I have the custom property of rootTagPath that is used for Indirect tag binding. I have a pretty good handle on how this works now.
When you say "define 3 tags", are those Client tags, or Gateway tags outside of my UDT instances, or UDT parameters, or custom properties, and after you have the tags created, how do you use them? Sounds like they must be two String tags which get concatenated into the third string tag.
Sorry, poor choice of words (I was on my phone). That should have read âdefine 3 custom propertiesâ. These are on the root container of the Window. Updated my OP.
The binding on the deviceTagPath is this expression (donât use an Indirect Binding!):
{Root Container._deviceParentPath} + '/' + {Root Container._deviceName}
Then to use it in another component binding to read a tag from the UDT, you would use for example the expression:
tag({Root Container.deviceTagPath} + '/Status')
You can also use an Indirect Binding for setpoints that need bidirectional read/write:
{1}/Position SP
where {1} = {Root Container._deviceParentPath}
This is all good for getting indirect bindings on window components and I appreciate the help everyone has given.
As I discovered with trying to trigger a Client Event Script (Tag Change) you cannot use an indirect tag in the Tags List for the Client Event Script.
Now I would also like to use a transaction group to write DB values to the same indirect OPC tags based on a trigger. I think it requires using Triggered Expression Items with the tag() expression using the indirect pointer.
Does anyone know if its possible to use expression items in a Transaction Group using the above described indirect pointer using the client tag for rootTagPath in the expression? I have it set up but havenât tested yet. I am starting to think that it might work for one system, but as soon as there are multiple systems the indirect expression tag scheme might get confused with multiple Client/PLC systems trying to access the same Transaction Group indirectly. I am starting to think I may need a dedicated transaction group for each system with basic OPC Items instead of Expression Items. Any ideas are welcome.
In this scenario if I will eventually have thousands of tools is this going to cause performance issues? Has there been any new developments since this post?
What do you mean? Thousands of devices will certainly make more load than one device, but your only other option would be to make many gateways. Try.