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

I am creating a Light Template to be used in possibly in another template. We have several Production Lines (8) that have several feeders (12) that can pull material from several bins (17). I am trying to use indirect bindings to save a lot of data input. I am trying to use “lineName” and "binNum in an expression but always get a Nesting error. Can you provide assistance?


I’ve retracted the original post as the solution was not ideal. See below for a better solution using indirect tag bindings.

Or create 2 custom properties and use indirect tag bindings.

1 Like

jPark, I created 2 Template Properties as shown in my original post. Is that similar to what you are suggesting?
That is when I get the nesting error.

WillMT10, I will try the tag function. I found that in the manual but needed to see it used in my application like you are showing. Very helpful the way you did that for me. Thank you…

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…