[FEATURE] UDT Definition Parameters: Add relative referencing to parameter addressing

When you have multiple UDT definitions with the same parameter set, and nest UDT instances within other definitions, there are always times when I want to reference the parameter of a parent UDT instance, but I can’t because the instance itself has the same parameter and hence this is prioritised instead.

I would like to be able to use similar relative referencing as you can do when referring to tags:

{Description} # refers to this UDT instance's 'Description' parameter, or upstream if it doesn't exist (this is the current behaviour)
{../Description} # refers to the parent/containing UDT instance's 'Description' parameter.
{../../Description} # refers to the parent of the parent's UDT instance's 'Description' parameter.. 

For all of my device UDT definitions, I have common parameters:

  • Alarm_Area
  • Alarm_ParentDevice
  • Description
  • DeviceName
  • PLCName

For devices that are embedded into other devices, such as a tank for example that may have a valve and an agitator, I would like to use Description or DeviceName of the tank inside of the Alarm_ParentDevice for the attached devices, however I can’t as these instead reference the device’s own parameter :frowning:

Please vote for this here:


I’ve always wondered what the use case is for referencing a parameter in the same UDT. If you’re defining the parameters, why do you need to reference another parameter that you already need to define?

A good example of that is for the format string or the units of tags, where you can define these in parameters and then reference them for numerous tags for example in a UDT for an analogue instrument.

Referencing parameters within other parameter values within the same UDT though, I’m not sure… If someone is doing that, they’re probably doing it wrong

I’m just spitballing, but would something like {super(NameOfParent).Parameter} be better, so you don’t need to worry about the explicit ordering and can instead just find by name?

That would be handy for one-off references, but relative referencing would allow for “cascading” of parameters using default values (you could have a UDT that by default references a parent parameter, no matter what the name of the parent is).

AlarmArea is a good example of a parameter that might be desired to cascade by default.

1 Like

Yep to what Ben said. I typically don’t care and don’t want to care about what the name of the parent is, I want it to be generic for ease of roll out which means needing relative referencing. Otherwise it becomes more of an absolute reference