Does anyone know if there is a template out there that would let me drag a tag value onto a display for a numeric input component and have it automatically populate a label next to it with the .name parameter of the same tag?
I was able to figure out how to do this for tags in the same folder…I had to hardcode the folder path into the template…I set the template custom property to a string “NameOfTag” and have that be the drop target, then for the value I have an indirect tag reference of folder/{1}.Value where {1} is the NameofTag custom property. Works fine for all tags in the folder, but I’m using an AB PLC with Add-on’s and UDTs, so most of the tags I’m interested in are in their own sub-folders dynamically generated when I populate the tag list from the OPC.
What I’d like to know, is there anyway to get something like this to work independent of where the tag is in the tag hierarchy? I’m still fairly new to Ignition, haven’t learned the scripting engine yet, so I was wondering if someone else was able to do something like this with scripting, ie have the template determine the full tag path using scripting and then dynamically link the label and the data entry component in the template to the full path.
There’s no direct support for this, but it is possible to examine bindings from scripting via the undocumented InteractionController object on each window. There’s some nuances to doing it from within a template – these are the sorts of problems that caused me to create the objectScript() function. Ignition v7.8 now has similar functionality in runScript().
Basically, from a function in an expression binding on your label, you’d use binding.target.parent.getComponent() to get the numeric display, look up the binding in the window’s interactionController, then get the tag path from that binding.
I’m struggling with the same question. So often you just want to drop a bunch of analog values on a screen, get their value displayed and have a description/name next to it.
All I could find, other than what’s described here, is the example given in the video for Vision Templates with UDT. That way, a template will be able to pick up meta data of the UDT. If only this worked for meta data for a single tag.
It’s definitely doable, but only with undocumented features of Ignition. { Interaction Controllers and Property Adapters } No time right now to play with it myself, but if you experiment with objectScript() and shared.inspect.introspect(), you’ll probably figure it out.
I’m not sure if I am misunderstanding the question but…
If you use a Tag UDT and then attach the UDT to a template the Meta data for the tag is available to the template.
Link the tag UDT to the template.
[attachment=2]UDTLink.PNG[/attachment]
Link the text of the label to the UDT meta property.
[attachment=1]UDTTextLink.PNG[/attachment]
And here it is on a window after adding the template to the vision window.
[attachment=0]UDTshowingMeta.PNG[/attachment]
Yes, I saw the solution for UDT. However, I don’t have UDTs… Too complicated for me
No, in all seriousness, the PLC I’m looking at just has a whole bunch of variables that represent a lot of different analog inputs. For troubleshooting, all I want to do is dump them straight from the tag browser on a page, select a template that has both the value (in a label) and the name (in an editable text string).
Compare it to a checkbox: If you drop a discrete input tag on that, it picks up the value and puts the tag name in the text property. Perfect for quick page setups.
Honestly though, if you get the UDTs setup, then when you drag and drop tags it will prompt you which template do you want to use to display the tag. They aren’t that complicated to setup and will save you hours and hours of development time in the future.
The University is free and comprehensive, and will walk you through the setup of the tags and templates tied to the tags.
Thanks again. I had a look at the UDT again and really can’t figure out how I would save any time here.
I’ve added a screenshot of my TagBrowser. You’ll see that it’s a bunch of analog signals, all part of a single machine. There is no structure in the PLC naming, and therefore no folders in the TagBrowser. It wouldn’t make much sense anyway, I don’t have a number of objects that keep coming back… like the motors in the example. My application is not some large process facility with multiple instances of similar objects. On the contrary, I’m typically looking at a single, complex piece of machinery - in this case a hydro turbine.
The only way I can see UDT work here, is if I made some kind of a ‘generic instrument’. I would have to give it a property like ‘DeviceName’ and it would contain a single tag - the Device (currently a tag as imported from the PLC).
Then I would have to create each UDT manually, by entering the DeviceName manually and setting the OPCPath for the Device. Then finally, I would be able to drop that UDT on a template that picks up the DeviceName and the value from the device… I have about 50 tags to create like that, and since there is no structure… there is no wizard that will help me. That’s a lot of work, compared to simply dropping the tags on the container and then add a bunch of labels that I edit manually.
Anyway, maybe I’m missing something here… in which case I would value your further input!
The real strength of using UDT tag templates is the ability to then use XML to create your tags.
We have an actual database that contains all of our I/O with the corresponding .Field names.
This could just as easily be done using Excel, CSV, etc.
You can then create the requisite XML tag file that contains all of your tags and the settings required, go into Designer, tags, right click and import from XML file. The XML tag entries will contain the pointer to the UDT for that particular type of tag.
You can also do the same thing to actually create the UDT tags, they are all just XML at heart.
Now I don’t know how often you generate tags or do completely new Ignition applications, but by using XML, UDTs and templates it does save a ton of time, even for simple tags like the code above.
It is just a simple UDT to display a timer .PRE from the PLC.
