Nesting Not Allowed while using Properties in a Template to turn on a Light

Use of the tag() function is almost always a mistake. Use indirect bindings to extra custom properties, and use those properties in the final expression.

1 Like

Hi pturmel. Thank you for commenting. Could you clarify Extra Custom Properties? Are you talking abour the snip below?

Yes, internal properties. Or custom properties on components in the template.

I have not used this function before. Do you have an example?
The Internal Properties are used in the Template or in the Instance?
Sorry that I don’t completely understand.

Custom properties are used throughout Ignition. Here’s the Inductive University training sections for the relevant topics. Consider using IU to get up to speed:

{ Do the whole category of that last link. Do all of IU when you can. }

1 Like

Interesting, I didn’t know that. Just curious, what’s issue with using the tag function? Is it just a maintainability issue or is there a drawback in performance? Thanks in advance!

pturmel, I have made it 50% through the IU. Havent made it to these sections yet.

The main reason I use this method is for bidirectional binding that’s not possible with a tag() expression.

Oh very true. I was completely omitting - from my head - the possibility of needing to write to the tag and just thinking of the read only uses. I definitely agree that this simple comparison should be done with custom properties (and I am a little embarrassed I went straight to the tag() function…). I tend to use the tag function in more complex bindings where it would be a pain to create a custom property - and binding - for every tag used in the expression. I just want to make sure that the tag() function doesn’t have a performance issue/impact that I’m not aware of, and the only real issues are maintainability and, like you said, bidirectional capabilities. Thanks!

Yes, there is. If the items that comprise your tagpath are updated, even if yielding the same result path, the entire expression containing the tag() function will have to execute. With indirect binding, this doesn’t happen. The strings themselves have to be reconstructed every time, even if not changing, slowing down the final expression execution.

There are a few cases with computed gateway tags where the tag() expression is the only good way to do indirection, and the dynamic stuff above doesn’t happen anyways. Anywhere else is a mistake, IMNSHO.


WillMT10 and pturmel - I got the tag() function to work (I am only reading to make comparisons) but I am interested in the Custom Properties and Internal Properties. I viewed the information that pturmel provided but didn’t see where the Internal properties were used.

Oh wow, I never thought of that. Thank you!

Hopefully these screenshots help:


Almost all components and containers in Vision can have custom properties. Add them as needed to support your application.

Templates are layered components. They have two types of custom properties: template parameters and internal properties. The parameters are readable inside the template, and writeable in the template with scripting, but not bindable in the template. Instead, they are bindable in the instance placed in a window or nested inside another template.

Internal properties are completely usable and bindable within a template, but hidden from the containing window (or outer template).

WillMT10. Thank you for the screen shots. They look like they will help considerably. I will let you know how it turns out…
Thanks again, i really appreciate the help and time you took to create the screen shots…

Hi WillMT10,
I got to where I needed to be using the below Expressions. My Lights are working well.

Thank you for your help Maybe when I get a bit more comfortable, I will use the Internal Properties on another project. It is great to add to my Ignition toolbox

Glad you got it working, but I will say it is probably worth the effort to get the indirect tag binding method working. When I offered up the tag() function I didn’t realize the performance hit it could have on the system. I am going to delete my post in the hopes of not steering others in the wrong direction.

Sounds good. I am trying to work on that at the moment. Trying to wrap my head around the hierarchy between the Template Properties and the Internal Properties.

If I have a template inside of a template, is that where you would use the Internal properties?

@pturmel’s last post above gives a good overview of the difference between them but I’ll try to clarify a bit (pturmel - please correct me if you see anything wrong).

You can use the Internal Properties for really anything you want inside the template (including linking them to an embedded template). Think of them similar to custom properties on a root container in a window. When you create a template instance inside of a window, these Internal Properties are not exposed/accessible within that window. You will only see the Template Parameters listed. So these Internal Properties, among other things, are a good way to add bindings that transform or run calculations using the values passed in through Template Parameters.

Nothing wrong, but I would emphasize that template parameters are intended to interact with the window containing the template, or the canvas/repeater containing the template. Template parameters come from “outside”. You cannot attach bindings to template parameters inside the template–only in the instance in the window. When used In the repeater or canvas, template parameters should follow the rules for that container. Template parameters are also the only direct way to expose data in the template to its container, and only in single instances. However, the assignment inside the template to do so must be scripted.

Internal properties are not visible outside, but can have internal bindings. These are suitable for intermediate calculations, like the indirect tag bindings we’ve been harping on. These internal properties can be used anywhere on the inside of the template. A nested template could bind its template parameters to the outer template’s internal properties (or anything else visible to bindings inside the template).

1 Like