I have an existing dial gauge template that receives a tagpath to form indirect bindings within the template. Works great for years.
Today, I created a new template for an energy meter that's a cluster of these dial gauge templates. The master template receives the root tagpath, each dial gauge template forms its tag path with the next level down tag folder.
Example master template = [Building]Energy Meters/Meter 1
Dial template = {1}/V_AB with the master template rootpath as it's property.
I have buttons with scripting that sets the tag path root for each meter instance.
Works great, except the momentary red boxes around the dial gauges as the tagpath reconciles. I opted out of the overlay, and the box is now gray with a tag/clock icon.
Not a deal breaker, but just curious if I'm doing something inherently wrong or if there is a better way. I could just create the master template with the base components of the dial template, but wanted to utilize what I had already built.
Incidentally, I tried it as a group instead of master template, and same behaviour. Maybe a container?
Try using an expression binding to concatenate the root tag path with the suffix, right at the inner template instance.
Not sure I fully understand, but as a test…
I created a sub template that has a direct numeric float as a custom property. That custom property on the template has an indirect binding to a value directly using the master templates tag path.
Without using any button or script, in designer, if I change the masters root path property in the window, I see the overlay tag/timer icon. If I open up that instance of the template, and change the rootpath property within the master template, it updates immediately and I see no overlays.
According to Ignition reference, the tag/clock overlay is an OPC_Waiting indication, but all the tags have good quality.
Further test. I created a new master template with just a single label on it. The labels text binding is an indirect to the master tagpath and a memory tag.
Same behavior. The label briefly shows the timer/tag overlay. And that’s just a single level template with an indirect formed…a methodology I've used everywhere and never seen this behaviour.
Now that I think about it, in all my template instances, they have static tag paths to define a permanent instance of the template.
In this case, I'm dynamically changing the tag path to the template in real time. Maybe that’s just a poor application technique? I could probably just create it as a group or container and not have this issue.
No, as long as you are passing the dynamic tagpath to the inner template. (Each inner instance of the one template should have its own expression binding that constructs that template’s tagpath by concatenation with the outer tagpath.
I am…but in my follow up example, I eliminated the inner template. I created one template with a label on it, memory tag string. The label text is bound to {1}\memorytag. On the template, I have a custom property rootpath. I put the template on a window, and change the rootpath string manually in the custom property, and the label still shows an overlay of clock/tag. If I open up the template itself, and change the rootpath string inside the template, no such overlay.
Unless you share code/project or window & template XML, we are just guessing. You have described your examples, but not provided them.
On an airplane, but will provide such later….thanks
1 Like
Solved and as usual, something stupid I overlooked. So, I originally set all the sub template overlay options disable to get rid of the red overlay. That turned them to the tag/clock gray overlay. What I omitted was one value binding I was passing to the template, that did not have its overlay opt disabled. It was odd that it cause all the overlays to show on individual widgets within the template that did not even use that value, and so sent me on a wild goose chase. But, seems to be working as intended now. Thanks as always for the support.
1 Like