UDT Binding Reference to Other Member or Custom Prop

I'm wondering if it's possible to pull in the value of one member in the UDT into the definition of another member. Or, use the value of a custom property in the definition of a member.

For example, UDT Pump has a base member Pump.Base_Path that holds the "base" OPC path, created based on supplied parameters. Then, sub-member Pump.Status.Run_IND would append to that base OPC path to get the desired OPC tag.

UDT Defnition:

The OPC path builds as expected:

I would've thought this would be possible using either a memory string member within the UDT, or a custom property at the root of the UDT, but I don't see any option to reference either of these when adding the binding to the OPC path.

Using the same parameter names in multiple UDT definitions means those types cannot be conveniently nested inside each other, due to the clashing parameter names. I recommend using a parameter naming scheme where the UDT's own name is part of each nestable parameter's name. So for a UDT named SomePLCtype1, I make it's base OPC item path parameter opc_SomePLCtype1. That way a nested type can construct its parameter value from an outer type's parameter.

For examples, consider playing with my EtherNet/IP v2 beta module--it's JSON UDT definitions exported from the PLC use this scheme.

Noted, thanks for the tip.

This is where it would be awesome to be able to use relative referencing such as {../param1} to go up nest levels

So, it seems not possible at the current moment in time. I'll just have to use the parameters individually in every OPC path binding.

Agreed! I would also 'settle' for the ability to bind a UDT parameter to the value of a UDT tag.

Perhaps not. But, here are some options that might involve rethinking of your approach:

  1. Use a Tag Event Value Changed script (ex below) to write to UDT parameters from UDT tags. We use this for conditionally placing several tags on-scan only if the value of another tag is 'True'. I adopted (from a forum recommendation) a naming scheme that clearly identifies the parameter as 'externally written'. Perhaps an 's' (for script) prefix is enough? This option, of course, requires that the (Edge) gateway is licensed for scripting (+Edge Compute module):
system.tag.writeBlocking(["[.]Parameters.sDevice"], [currentValue.value])
  1. Use nested UDTs to pass parameters of parents UDTs to children UDTs.
    For example:
  • UDT_Pump: Parameters: pNum, pDevice
    • UDT_PumpStatus: Parameters: pNum={pNum}, pOPCPath="ns=1;s={pDevice}{InstanceName}"
  1. Use UDT inheritance. If you have 3 devices throughout your facility, each with pumps that have identical logic for status / control therein, and you want to utilize a common UDT, you 'could' generate a Pump UDT which is inherited by 3 additional UDTs, each with unique parameters for 'pDevice'. Then, while building out instances of each pump, grab the appropriate UDT child.
  • UDT_Pump: Parameters: pNum, pDevice, pName={InstanceName}
    • UDT_Pump_DEV1: Parent Data Type=UDT_Pump, Parameters: (Override params as necessary) pDevice=[Device1]...
1 Like