Lets say I want to make an indicator for a boolean tag that uses the tag's name as the text in the indicator, and I want this to be a template so that I can make a page that is all the statuses of all of the booleans that I am interested in monitoring.
What I thought I could do was make a template that is just contains a slightly dressed Multi State Indicator: slimming the style to take just 0 or 1 as values and binding text in the indicator to be the Name property of the dropped-in tag. I thought I'd just need a single Template Parameter of type boolean with drop target enabled. When I do this I seem to only have access to the actual value of the boolean tag, rather than all of the properties that the tag contains such as its name / quality / etc. Without that, I can't link the name as I planned. For UDT type tags, it has metadata available, like TagName and TagPath, but for standard tags it doesn't seem to have these.
Is there a way to do what I am trying to do? I am trying to avoid something as cumbersome as making a UDT that is just a heavily decorated normal tag, especially when that tag already has some kind of access to the data I want already.
This workaround is very cumbersome and fragile -- if the folder structure isn't exactly 1 deep this won't work since I can't -1 index the split. It seems difficult to access sibling tag data in a UDT for dynamic behavior.
1 Like
Just the one bump, I promise
Not as a drop target (in Vision). Perspective's drop config has better support for tag path parameters, which is what you should be working from anyways.
Do you mean I should be working from perspective or working from tag path parameters?
Perspective versus Vision is very much an application-dependent question. You should be using tag path parameters with indirect binding everywhere.
As in I should be using parameters on the UDTs and accessing those parameters as fields in the indirect tag configuration? I don't seem to have access to UDT properties inside of the template editor.
For example, I have a UDT as the drop target of a template, it is called valve_udt of type pal_valve with a single property called "index", yet I can not see it within the Property Binding / Property / valve_udt -- how would I be able to access it within the template?
Please do not mind the chaos, I am still trying to understand how to attach everything together.
You wouldn't bind as a properties, but as tags. (Properties of tags can be bound by including the .propName at the end of the tagpath.)
UDT properties in windows and templates and views are wonderful when you don't know what you want from an instance, but are horrible in all other ways.
Consider this segment from Inductive University:
{This video show a numeric value as an indirection key, but the most flexible is to use a string that represents the path to a UDT instance, or to a folder with tags of the same predictable names.}
Once you acclimate to this, you will realize that you aren't bound by UDT data types at all. Any UDT or folder that has the nested tag names it needs will Just Work™.
{Have you completed IU, BTW? It answers this kind of beginner question, among many others.}
1 Like
Thank you that is very useful, I will go through it. I seem to be getting the feeling that to use Ignition with as much introspection as I would like, I will be using the GUI less than I would hope.
I did complete IU, although I did it before actually working on a real system. IU was great for knowing of the different features, but there is no substitute for actually starting to build one. I am definitely using Ignition for a system that will be operating on the limits/fringe of its capabilities, which complicates all of my use cases.
In this case I wasn't even getting heavily into what I thought were use cases for indirect bindings, I was trying to better understand where I can use introspection more heavily to build more dynamic templates. The impetus for this particular issue is that my tags are imported via script from the export of a document generated by our PLC software, which allows a single source of truth for the naming and description of most of the variables of interest. By having a template that can read directly from the tag information itself, I could bypass a lot of customization inside of ignition itself. I realize I can dynamically create UDTs via script, and that was one of my next avenues to investigate, but I was hoping that I would not need to by creating a few self-referential templates.
1 Like
So I rewatched all four videos on that page, and while useful, they unfortunately don't actually solve the problem that I am focused on.
I am trying to introspect a boolean standard tag in order to access the name of the tag, from within a template. When I add a boolean drop target to the template, I have access to the value, but not the metadata, of the tag. UDTs sort of improve this by having a TagPath and TagName variable available here (although still not having the actual tag reference, I presume it could be fetched with the TagPath and the tag() function.
What I need is some kind of hook to the tag itself. I tried expressions like the following, to no avail. I obviously do not have a perfect handle on the expression language yet, but I expected this to work.
This also didn't work:
This returned a gibberish string that was "[TagProvider]false", clearly not what I was hoping for:
Would you have some advice about how to introspect an arbitrary drop-target for a template? My next plan is to just autogenerate generic UDTs that duplicate information, something I am generally opposed to from an architectural standpoint.
When you use tag paths, the name is part of that string. No introspection required. All other are retrievable via scripting or indirect binding.
Also, for a system that will be highly stressed, introspection at runtime is a huge burden. Do your introspection at design time.
When you use tag paths, the name is part of that string. No introspection required. All other are retrievable via scripting or indirect binding.
I understand that -- is there a way to make a drop target expose the tag path? These are the options offered to me:
Also, for a system that will be highly stressed, introspection at runtime is a huge burden. Do your introspection at design time.
That is good to know, but the current version of the system is designed to be highly modular, designed for R&D. A final state to-be-duplicated-ad-infinitem production system would have everything tuned up and hardcoded for maximum performance.
Not in Vision. Sounds like a great feature to post on the ideas site.
1 Like
Ah darn. I will add it there, thanks! I can't believe nobody has tried to make an indicator that has its own name on it as a template before...
That's not what I had in mind. But whatever. You haven't absorbed the paradigm shift I'm suggesting. ==> If you are given a root tagpath as a template parameter, all other tag paths below that are simply constants tacked on. Which is precisely what indirect tag binding does. And for the tag name, it is right there in the string the template is given. 
I was suggesting that Perspective's tag drop config functionality (which supplies the tag path to view property) be implemented for Vision drop targets.
I was suggesting that Perspective's tag drop config functionality (which supplies the tag path to view property) be implemented for Vision drop targets.
See this is something I did not know about, and consequentially didn't understand the reference -- I have not used Perspective at all. It would be substantially better to have this than the drop target linking only the value. It would solve all my problems.
I am more than happy to do everything by tag path -- if it were up to me every function in ignition would operate by reference so that tags can be updated/renamed/moved without breaking everything -- but since I didn't have the option I can't embody the paradigm shift. I am trying to make it work with what I have available in front of me. I can't use indirect tag paths in combination with Template Parameters because it doesn't give me the full path.
See, this is where you are stuck. The string tag path IS the template parameter instead of a UDT parameter. Then, in the template, wherever you bound to a property of the UDT parameter, replace that binding with an indirect tag binding, using the path with the UDT to that property as the trailing constant in the indirect binding. (The dynamic {1} substitution is the tagpath.)
Yes, you give up having any drop target functionality in Vision. But Vision drop targets only work if you use UDT parameters in your templates, which is a bad thing. Abandon those entirely.
When instantiating a template based on tag paths in a Vision main window, you drag the template to the window before you go to the tag browser. Instead of dragging the UDT instance to the template holder's UDT parameter, you locate the UDT (or tag folder) in the tag browser, right click, and copy path. Then you go to the template holder's tagpath parameter and paste that string value (not a binding).
When nesting a template based on tag paths in another template, you drag the inner template to the outer template to make a holder. Then, on the inner template's tag path parameter, you make an expression binding that produces the right nested tag path (usually by simple concatenation with a constant). (Or perhaps a simple property binding if the nested template is expected to work at the same "level" as the outer template.)
Edit for completeness/clarity:
When nesting a template based on tag paths in parameterized Vision window (perhaps a popup), you drag the inner template to the window to make a holder. Then, on the template holder's tag path parameter, you make an expression binding that produces the right nested tag path (usually by simple concatenation with a constant) from the window's tagpath root parameter.
When calling parameterized popup windows, you supply the tagpath parameter in the navigation script like any other parameter, constructing it from the calling component's dynamic and constant tagpath parts.
2 Likes
Yes, you give up having any drop target functionality in Vision
It was previously unclear that this was fully incompatible with drop target functionality, thank you for clarifying.
if you use UDT parameters in your templates, which is a bad thing . Abandon those entirely .
That sounds like a major feature to abandon -- why do I not want to use these? I was planning to generate UDTs for all of the major device categories that I would be dealing with and attaching them to corresponding widgets to generate a templatized HMI.
I understand the programmatic virtue of using heavily parameterized paths for variables so that they can be referenced indirectly, I was hoping that would be compatible with both UDTs and templates that take advantage of them.
UDTs are wonderful for creating, managing, and modifying complex tag hierarchies. On the UI side they are resource hogs and are shackles for creating flexible UI implementations. Think of UDTs in UIs as the strict data type rules of C++, where tag path-based UI's are the flexible "duck-typing" of all modern scripting languages.
You really, really want to be using the latter. If you want polymorphic templates and windows, and it sounds like you do, you definitely do not want to be using UDTs in the UI.
So do you instead build pseudo-UDT tag structures? How do you create your "objects" if not by using UDTs?
