Template using UDT param: Can you access UDT tag metadata?

[nminchin]

Hi all,

I’m new to Ignition and have tried searching for this already with no luck.

I have a template with a UDT as a parameter that contains some OPC tags. Can I access the metadata (e.g. Eng Units / Min/Max range, etc.) of this UDT parameter’s tags from inside the template? e.g. something like (which doesn’t work) {Tank Template.Tank::Temperature.PV.EngHigh}
Where:
Tank Template is the template
Tank is the UDT parameter
Temperature.PV is an OPC tag within the UDT
EngHigh is the metadata I want to retrieve

Cheers,

Nick

[Paul.Scott]

Greetings Nick,

I had some success using the tag() expression function along with the TagPath (located in the “Meta” folder on the UDT property). The TagPath only navigates to the root of the UDT, so you’ll have to concatenate the tag name and EngHigh. Try the following:

tag({Tank Template.UDT::Meta.TagPath} + "/Temperature.PV.EngHigh")

[nminchin]

Having more experience in using Ignition now, it’s worth noting that using UDT parameters within template symbols is not recommended. It’s much more efficient and scalable to bind the path to the UDT instance instead, and then concatenate the relative path to the tag onto that.

Using a UDT parameter has two major down sides:

• all tags within the UDT are subscribed to, meaning higher load and potentially slower client and server performance, especially if a number of the template instances are displayed on the page.
• it’s impossible to reuse the template symbol for another, similar UDT

[Caleb_Bohon]

Nick,

That sounds sensible if the template is only using part of the data.

Do you think it is better to use the parameter way if the Template is using all the data, or is the path method always better?

-Caleb

[nminchin]

I would always use the tag path way and would avoid using UDT template parameters altogether. I’ve been bitten before when a new UDT was created which was fairly similar and I wanted to reuse the same templates and detail pages, but due to the template and page using a pre-defined UDT parameter, I couldn’t. I ended up re-coding these templates and pages to instead use the tag path which allows a lot more flexibility in the future for reuse.

[scott2]

I may not be understanding you correctly, but are you saying not to use ‘drop targets’?
Whilst i’m not an expert, i’m not a beginner either.

If i have say a motor template, that has a custom property of Motor UDT type, that is also a drop target, when the template is placed on the screen all the UDT parameters are subscribed to, even if they are not animated or alarmed/historised?

[nminchin]

Correct: all tags within the UDT are subscribed to, no matter if the tags are displayed or not. Depending on the size of your UDTs and the number of templates using these UDTs that are shown on the page, this can be a significant number of tags which may cause performance issues.
And correct, not using UDT parameters also means that you’re not able to use your UDT instances as the drop targets.

[Sanderd17]

We’ve just been bitten by this too.

A touchscreen we use has a quite slow CPU, opening a motor popup took 1s to show the popup window, and another 7-8 seconds to visualise the tag data. During that time, the CPU was constantly running at 100%. I would have thought that opening a popup would be influenced mostly by network speed (getting the data from the server) or graphical power (rendering the screen itself), but it turns out to be CPU intensive.

Changing the popup to accept a tagpath parameter instead of an UDT parameter fixed the issue. It still take 1s to show the popup window, but all data is visualised immediately when the popup opens.

Strangely, it also doesn’t depend on subscribing to the UDT. When we were halfway through changing the references on that popup, we kept the UDT reference but derived it from the tagpath (which is easy enough to do via indirect tags). The popup already loaded twice as fast as before.

When you do it the other way around however, bind the tagpath to the UDT via the meta-data (and keep the UDT as parameter), the popup stays slow.

So it looks like for every lookup that needs to happen through the UDT (either directly or indirectly), a relatively large amount of CPU power is needed, while that isn’t the case when you use the tagpath without passing through the UDT meta data.

Having an unused UDT still defined as parameter on the popup doesn’t seem to make a speed difference, as long as you don’t use the UDT.

This is all very counter-intuitive to us, as we thought it would have been easier for Inductive Automation to optimise the CPU usage when using an UDT instead of referencing every tag value separately. And the issue isn’t related to subscribing to all tags, but instead related to how much you effectively read from it.

The only thing we can guess is that for every parameter read, the client will acquire the entire UDT to get the parameter from it, which sounds extremely wasteful.

[j.israelsen]

Two follow up questions:

(1) To clarify, is the method you are suggesting something like the following (reference pscott post above)? If not, please present and example of how you would use the tag reference.

tag({Tank Template.UDT::Meta.TagPath} + “/Temperature.PV.EngHigh”)

(2) Is the issue with using UDT parameters also occur with other things or is this just for templates? For example say I have a popup with a custom parameter which is a UDT. Would I experience slow downs if I use UDT parameters from my popup custom parameter?

[nminchin]

No no, in your example you are still using a UDT type parameter. You are far better off to pass in the actual tag path to the UDT instance as a string, and then do exactly the same thing in your example with that.
E.g.
Parameter: TagPath [String]
TagPath = "Tank Farm/Tanks/Tank 1"
Expression: tag({Tank Template.TagPath} + '/Temperature/PV.EngHigh)

If you can pass in a UDT type into a popup without including the UDT type in the object/template you're calling it from, then this most likely won't have any performance impacts, as it will only contain one UDT type. I'm not sure that you can actually do that though... I don't know if you can actually pass in the UDT type without have it as a parameter of the object or an object in the Window. I remember trying this and kept getting the error:
ValueError: Error setting parameter: bob. Could not convert System/PLCs/Diagnostics/Boiler into UDTProperty.

That's using the script:
window = system.nav.openWindow('Main Window (1)', {'bob' : 'System/PLCs/Diagnostics/Boiler'})

where 'System/PLCs/Diagnostics/Boiler' is the path to a UDT instance. The function is looking for a UDTProperty object type, and I'm passing in a string. I don't remember being able to find a function to effectively look up the tag path and return the object, and I certainly wouldn't try using browseTags for that due to it's own performance impacts.

Disabled tag breaking Expression tag expression

Careful with this approach. system.tag.browseTags is a performance killer and pretty much always hits the internal DB, which cannot be accessed concurrently. Too many scripts/events in the system invoking browseTags can make access to the internal DB highly contested and bring down a bunch of other parts of the system.

[j.israelsen]

Okay, got it. Thanks for the quick and clear response.

[lachguerabdallah]

And if we have many instances of the same type ?it will be difficult to position the path of each instance in the template.

[nminchin]

Compared to the limitations of using UDTType parameters, I would much prefer to have to type in the tag path.
Just FYI I don’t use tagpath (anymore?), I split these up now into:

• DeviceParentPath
• DeviceName

Then I bind an internal DeviceTagPath parameter to combine these two parameters. This makes it easier, more flexible, and much faster to populate instances with values.

[lachguerabdallah]

I’m not understanding you much…
I have a UDT and a template, so I associate the template with the udt, then in the template I have components related to the udt tags. So I understand that this is going to slow down the system. do not ?
on the other hand I have many instances of the udt

[nminchin]

I'm not entirely sure what your question is.

You can have a UDT or number of UDTs that can be represented by a Template.
I add DeviceParentPath and DeviceName string template parameters, and DeviceTagPath as a string internal parameter.
If you use a single UDTType parameter and link that to a single UDT, you will have a number of limitations:

To UDT or not to UDT. That is the question

at a glance, it’s not possible to see by looking at a component’s properties which UDT instance has been bound to a UDT type property. E.g. in the screenshot below, I have no idea which Tower UDT is bound, I have to click on the binding to find out. It’s also far slower to populate template parameters than simply modifying a parameter string value. I tend to use 2 parameters: DeviceParentPath and DeviceName, then combine these together in an internal parameter DeviceTagPath, which also aids in…

[lachguerabdallah]

my question is: if in Template Parameters do I use the UDT it affects performance? since in my project I have many instances of the same UDT, and for all the instances I must use the same template.
as I just read in your answer it doesn’t affect it using ignition 8

[nminchin]

Performance-wise, the release notes (I can’t find the reference, but remember reading it somewhere) mention that they’ve significantly increased performance for UDTType bindings compared with 7.9.
Again though, you’re still stuck with the other limitations.

[lachguerabdallah]

Thank you very much.
now how can i access a UDT tag property from the template. I have used the following but it does not work
tag({test.dt::Meta.TagPath}+ “/V_CLOR/Alarms/High.HasActive”)

in the capture, "TEST"is the name of the udt instance. the tag “V_CLOR” have an alarm called “High”

[pturmel]

Probably also want to ditch your use of the tag() expression function.

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

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…