Passing Parameters from main Window to Template Canvas in popup window

I have 4 instance of template in Main window and on click of any template instance , it should open popup to show that template , history data of tags in the template and alarms.
How to pass parameters from main window to popup window template on click of any particular instance in main window.
your inputs/solutions/suggestions are welcome !!

Make the button part of the template in the repeater. That button will have access to the same properties as the template, and can included whatever is needed in the call to system.nav.openWindow().

This is simplest if your template uses a tagpath as its driving parameter. Just pass it to the popup window.

I do this routinely with UDT's.

I create my templates, passing a custom property of type string (called rootname) to form the parent UDT for all the tags used on the template. Drag and Drop template in main, set the custom property of rootname to the UDT tag path (tank 1 for example) and the template instance is done. On your popup window, create a custom property of that same type UDT. Then on your template button or whatever you want to use to open the popup, pass the tag UDT instance you want. On your template, use the UDT properties for all your widgets (buttons, indicators, values, etc.). For the Historian/Realtime easy chart, use the chart binding to populate the tags based on the UDTs. There is an Ignition School video on how to do this: Indirect Easy Chart - Historian Charts

You probably should stop doing this. For multiple reasons:

  • Performance suffers when moving complete UDTs around, but only using/displaying a few elements.
  • Bidirectional binding aren't possible within the popup.
  • Your popup can then only handle that one UDT or its descendents. If your popup is doing something that could apply to multiple UDTs, you are stuck making more.

Instead, always pass tag paths. If you must, you can still indirect bind a UDT instance to a UDT property. But in general, you can construct all of your inner bindings with their own requirements (bidirectional where appropriate, etc.), and only those bindings. And you have the string to pass into further nested UI elements. Tagpaths allow you to make UI elements that are "duck-typed". That is, as long as you point them at tag architectures that have tags with expected types within them, the actual UDT type is moot.

UDTs are great for creating and maintaining large quantities of tags. They are horrible for UIs.

Interesting.....Not sure I follow your concerns:

My UDT's are not PLC UDT's but ignition UDT's based on PLC UDT's. I don't drag an entire PLC UDT into the tag tree. The tags in the UDT are specifically for the popup and template. All are used.

Bidirectional? Not following here. I have full bidirectional control/value editing within the popup.

The popup is specific to the UDT. For example motor control/faceplate/diagnostic. I have 20 motors, all the same type/faceplate. The UDT is specific for that motor type (Drive, reversing, speed control, etc.)

Side Note: I used to do exactly as you say...pass the root of the tag path and construct it within indirect or scripting as needed. I find the UDT easier and cleaner to maintain, but I'm all for performance, so I can easily go back, but Ignition seems to promote the UDT usage in their literature.

In your popup, how are you getting the UDT instance attached to the root container property such that bidirectional binding works? That is, how are you constructing your system.nav.openWindow() parameters to include a UDT instance?

Same as passing a custom property parameter. Instead of a string for constructing the tag path, simply create a custom property of type UDT and pass the UDT instance as the parameter.

Then in the popup, you don't use Tags, but properties of the root container which contains the UDT.

Pretty much like this: Parameterized Popup Window and UDTs - Popup Windows

So, the bidirectionality of the original window's binding to the UDT instance is transitive into the popup? Hmm.

Yup, Ok.

So, how are you handling UIs where there are multiple tag providers involved? Will a Popup defined to use a property with UDT from one provider accept a instance from another provider (presumably matching UDT in both)?

(I'm still not a fan.)

As long as you can drill to the tag of that type UDT, provider wouldn't matter. But yes, you have a point, that the UDT type would need to exist in both providers I suppose. But that's the case anyway if sharing common UDT construct. I could argue that's a benefit as it enforces commonality of UDT's across tag providers. Nothing worse than a UDT with a missing member in two different tag providers doing the same thing :slight_smile:

You should test this. Even with the same path names and identical structures, I suspect the property types are actually different, and incompatible.

Tag path designs don't care. The paths and type names in providers don't matter when you build from tag paths--only the leaf tag names (under the tip of the tag path) and types matter, and only if you are using them. You can even tolerate missing elements or variations using overlay opt-out.

There's also the matter of template repeaters and the template canvas, which simply cannot pass UDT instances into their templates.

In regards to Template repeater, I just drag and drop templates where I need them, change the name of the UDT, and done. I find the repeater very limiting anyway and never use it.

Tested in different tag providers. No issues. Just drill in the tag tree to whichever provider to use.

There are situations where you don't know the quantity of templates ahead of time. Or, sometimes, which templates among a selection of possibilities. The repeater and the canvas are for those cases.

Note also that the OP specifically asked about the canvas.

This might be because you use udt type params :stuck_out_tongue_winking_eye:

Repeaters are an invaluable component

Prior to UDTs i passed strings and modified the paths. Still didnt use repeaters. Very likely i just dont understand well enough the value of them. For me, my templates/UDTs and plc tag construction are defined such that i change one UDT pointer and everyhing dynamically changes....alarm text, labels, scripts, etc. Most of my work is in P&ID flow layouts (piping, valves, pumps) so there is not a uniform layout of repeatig templates. I drag a template into the root where i need it, change one custom property, and im done. All alarms, scripts for popups using the same UDT, etc are done.

Ive read through the repeater/canvass tutorials, and using data sets dont seem to save any time. The time i type in a data set identifier is the same as pointing to a udt for my custom property.

Im sure im missing something and am always trying to learn new ways to skin the cat.

Hi Phil,

Thank you for your inputs, I will workout on it.

Thanks and Regards
Jignesh Aghera

Hi Robert,

Appreciate your efforts for providing resolution to my query.
I will workout on it, as mentioned in your email and let see, how it performs.

Thanks and Regards
Jignesh Aghera

Repeaters can't be used for p&id mimics, but I use them for things like:

  • recipe editors, for example in the list of existing recipes, each row is a template View which uses a flex repeater to show them based on a query binding
  • dashboard displays for example to show an overview card for all sites in the project, or all tanks in a tank farm (could be 100s)