# UDT Binding Reference to Other Member or Custom Prop **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [January 25, 2023, 3:01pm UTC](https://forum.inductiveautomation.com/t/udt-binding-reference-to-other-member-or-custom-prop/69007 "2023-01-25T15:01:32Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [January 25, 2023, 3:01pm UTC](https://forum.inductiveautomation.com/t/udt-binding-reference-to-other-member-or-custom-prop/69007/1 "2023-01-25T15:01:32Z")
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: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/6/e69eeb891865ec58eac8fca047f71201c467493e.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/3/53ca564a3fb3c84af90eb86400dd6e5541a0e4a0.png) The OPC path builds as expected: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/8/c8631d76d0187e61f8999b257bbc5c2d7ae07f93.png) 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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 25, 2023, 3:45pm UTC](https://forum.inductiveautomation.com/t/udt-binding-reference-to-other-member-or-custom-prop/69007/2 "2023-01-25T15:45:53Z")
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](https://forum.inductiveautomation.com/t/automation-professionals-ethernet-ip-communication-suite-v2/68190)--it's JSON UDT definitions exported from the PLC use this scheme. ---
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [January 25, 2023, 3:58pm UTC](https://forum.inductiveautomation.com/t/udt-binding-reference-to-other-member-or-custom-prop/69007/3 "2023-01-25T15:58:09Z")
Noted, thanks for the tip. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [January 27, 2023, 11:27am UTC](https://forum.inductiveautomation.com/t/udt-binding-reference-to-other-member-or-custom-prop/69007/4 "2023-01-27T11:27:55Z")
This is where it would be _awesome_ to be able to use relative referencing such as `{../param1}` to go up nest levels ---
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [January 27, 2023, 2:10pm UTC](https://forum.inductiveautomation.com/t/udt-binding-reference-to-other-member-or-custom-prop/69007/5 "2023-01-27T14:10:21Z")
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. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [January 27, 2023, 3:56pm UTC](https://forum.inductiveautomation.com/t/udt-binding-reference-to-other-member-or-custom-prop/69007/6 "2023-01-27T15:56:08Z")
> [@nminchin](#): > > This is where it would be _awesome_ to be able to use relative referencing such as `{../param1}` to go up nest levels Agreed! I would also 'settle' for the ability to bind a UDT parameter to the **value** of a UDT tag. > [@amarks](#): > > So, it seems not possible at the current moment in time. 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): ```auto 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]...