Passing varying parameters from a generic template to windows?

Ignition
1

Hi,

I’d like to know if there is a smart way of passing varying parameters from a generic template to different windows.

Say I have a template representing a valve. I would like to use that template everywhere regardless of which tags/UDT’s provide data to it.

I’ve come pretty far with the concept, but have come to a halt when it comes to passing parameters.

At the moment I have a custom parameter in the template called ‘Faceplate_Path’. There I can set the path to the window I would like to open when I press the template. All good so far.

The problem is that different types af valves have different types of faceplates/windows and those windows have different custom parameters that need to be passed data to from the template.

Some parameters are just paths for tags or UDT’s.

Other parameter might be a value attained by bound logic - i.e. a template that gets the value of one of its own custom parameters and passes it to the window.

Is there a graceful way of handling this?

Thanks.

2

Why do you need to pass a varying set of parameters to your popups? Like you, I have several different types of valve udts etc, and only have 1 or 2 different popups that cover them all. And for both popups (and in fact all of my device popups) all have exactly the same set of parameters, some of which are the parentDevicePath, deviceName which are both passed, then a deviceTagPath which is derived.

I would recommend doing all your smarts in the popup and not before the popup. Eg checking if a particular tag exists and hiding its graphic of not

I have a function to open any device popup that first checks the UDT that it’s using and then opens the correct popup based on a tag dataset that holds udt type and corresponding popup window

3

@nminchin

Thanks for your reply.

I don’t fully understand your examples, but you say do you smarts in the window popup and I believe we already do that.

As an example, in our project we have UDT’s representing valves.
These UDT’s contain tags like open, closed, torqe fault, position and so forth.

Then we have a tempalte which displays a green valve if it’s open, red if closed, blink if faulted and so forth.
The template needs to know which UDT instance to represent so it has a custom property where you type in the repative path of the UDT instance.

Now when you press the template valve symbol you get a popup window. In the window you can also see the same info as in the template (open/cloesd/fault/…), but you also have commands like open, close, stop or a position input.
The popup is meant to be used on all the valve UDT instances and not hard coded to one instance, so we pass the path of the UDT instance in the template to the popup when it is opened.

The popup handles anomalies in the UDT. In some cases there is no closed signal. It’s disabled in the UDT structure. So we need to make logic that checks for that. And some UDT’s have a different tag name for the position so the window need to check which one to use, if any. Just a few examples.

The thing is we have about 5 different valve UDT types and now each has it’s own template valve symbol and popup windows.

I’d like to make a generic valve symbol which just has custom parameters like ‘Open’, ‘Closed’, ‘Position’ and so forth. You can then bind whatever logic to the custom property of the valve instance to make it display properly. In that way the graphics are detached from you tags/signals (which is pretty much my ultimate goal with this).

The problem comes when you press the generic valve template and need to open a popup window for the valve. At the moment the generic template has a custom parameter where you type in the relative path to the popup window you want it to open on press. There are about 5 differnet popup windows it can open and each as varying custom parameters that need to be passed to them. One of them has 11 strings, a bool and an integer that needs to be passed.

I can’t seem to come up with a simple solution to pass varying parameters from a generic template.
I’d very much like to avoid making whole bunch of ekstra custom properties in the generic valve template (like 15 string names, 15 string values, 15 bool names, 15 bool values, 15 int names, 15 int values) to be able to handle the custom property requirements of the popups, but it’s where I am at the moment.

I’ve tried to make a dataset custom property, but it doenn’t seem like a good solution either.

Thanks

4

You should consider changing to grey for closed :slight_smile: it will keep ASM guidelines, HPHMI, and HMI ISO standards (forget the number) far happier.

When you say you have 5 different valve UDTs, do each of these UDTs not use the same tag naming conventions? E.g. do they all have "Open", "Closed", "Position" tags? Or otherwise, how do they differ? (examples would help).
Can you be more specific when you say "You can then bind whatever logic to the custom property of the valve instance to make it display properly"?

If it helps, I usually have a Status and Mode tag from our PLCs, where both of their values represent named values, e.g. Status: 0=Closed, 1=Closing, 2=Opened, 3=Opening, 5=Faulted. For these tags, I create an additional descrpition tag which is an expression tag. This uses the integer tag value and translates it into the description (the 'Closed', 'Opened', etc.). Then I use this description tag everywhere that I want to display its state. This way, this is defined within the UDT rather than needing to copy the same expression everywhere you want to use it. It also helps when you have multiple UDTs that use different integer-description pairs.