Accessing UDT tag attributes in from a template

[jacques_za]

Hi all,

I’d like to change the background of my tag value based on the current alarm status of the tag, as is fairly common. The problem is that I’m trying to do this for a tag contained inside a UDT, for a linked template drop target.

Accessing the tag value is simple enough {Root Container.KPI.data::tag}, but I have no idea of how to reference the properties associated with that tag (AlertCurrentSeverity, in this case).

Any ideas?

Kind regards,
J

[nminchin]

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

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")

You need to use the tag function to read it.

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

[jacques_za]

Ah, thanks for that. I was hoping that I could read the drop target datastructure in the template directly, but of course I can use the meta tags to reconstruct the path to the original UDT tag as you describe.

Thanks!

[nminchin]

Just FYI, it sounds like you've got an analogue display template of some form that has a UDTType parameter. In general, I wouldn't recommend using UDTType parameters. They have their benefits, but potentially significant consequences. I have experienced two major downfalls:

• they can kill client performance. under a certain number (10-15?) of template instances are unnoticeable, but when you get more than a certain number, the Window load time is significant.
• they restrict a template to a specific UDT. Sometimes this is ok, but if in the future a new, similar UDT needs to be created that should use the same template, you're out of luck; you have to create a new template as well.

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

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 …

[jacques_za]

Hi @nminchin

Thanks for that pointer. Just to make sure I understand what you're suggesting, you're saying that it's OK to use UDTs, and to map UDTs to templates, but that instead of using the tags from the UDT dataset directly, that you should rather reference the tagPath contained in the UDT meta property, and rebuild the original tag reference from there?

Like so:

runScript("project.tagHistory.tagBarChart", 0, {KPI Bars.data::Meta.TagPath} ), 'day' )

Am I understanding you correctly? Or are you saying that I should define a string in the template, that isn't a drop target, and just populate the tag path in there, instead of using the UDT drop feature at all.

Thanks for the info!

[nminchin]

Sorry I wasn’t that clear. I was suggesting avoiding using UDTType parameters altogether, and instead passing in the UDT instance’s tag path as a string into the template; this unfortunately means that you can’t use the UDT drag/drop feature. It really depends though how many of the templates you foresee you’ll be adding to a window, now and in the future. If it’s going to be max 10-15, it’s probably not going to be an issue using UDTType parameters. However you also need to consider if you’ll ever need to use the template for another UDT definition, in which case it’s far easier to use the tag path instead.

[jacques_za]

Thanks for the clarification!

I’ll definitely be keeping that in mind when making template decisions in the future.

Kind regards,
Jacques Rossouw