Tag Provider Inheritance

Ignition
,
1

I’m working on a project to establish templates for various ‘canned’ AB AOI’s that cover a number of sensors and actuators that are repeated across various pieces of equipment. The goal is to have versioned AOI’s → version matched Ignition UDT types → version matched vision/perspective templates. I am attempting to utilize project inheritance to serve the templates in a version controlled manner and all seems successful so far. But here’s the rub…

I have set up Ignition UDT’s that dynamically point to all the tags I need in the AOI’s UDT in the controller. Two issues present themselves. One being that parameters in UDT’s cannot be set to tag values. This makes it so that for each UDT created from a type must have a device path typed manually, which creates a maintenance burden. Secondly, I cannot inherit these UDT types across tag providers. The intent would be to set up the types in the parent group, then have them inherited to the various projects, where the types would be used. The current path forward on this is unfortunately copy/pasting all the UDT types I need from one provider to another, or utilizing a single provider across all pieces of equipment. Neither seem like a particularly satisfying answer.

I haven’t seen anyone doing this, but I can’t help but feel like it is basically a necessity for inherited projects as any templates are likely to work off similar/same UDT types.

Am I missing something where I can accomplish my goals much easier?

2

You could use system.tag.configure to create them dynamically. Then nothing's stopping you from reading a device path from a tag and using this as a parameter.

1 Like
3

So, if I am getting this right, I can’t link tags to parameters, but can write a script to change all the parameters to match a tag.

So maybe…
Periodic gateway script or manual update script
Get tag types from the parent tag provider (matched to parent project)
Modify default parameter values in tag types to new default equipment path (based on a tag)
Send to inherited project tag provider

Is this what you were implying?

This seems like a somewhat sustainable way forward… It still creates quite a burden if a machine name ever changes, not that this burden doesn’t already exist system wide for minor changes. I’ve run into a number of issues like this where a lot of manual updating needs to be done when minor changes are made, which really ingrains bad naming conventions and the like because they are so difficult to change.

Thanks, I think this may work! If you think there is a better way to implement this, I’m curious to hear your thoughts.