# UDT Binding Reference to Other Member or Custom Prop

**URL:** <https://forum.inductiveautomation.com/t/udt-binding-reference-to-other-member-or-custom-prop/69007>\
**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:** 1\
**Showing post:** 2

<div class="post-metadata">

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

</div>

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.

---

_[View the full topic](https://forum.inductiveautomation.com/t/udt-binding-reference-to-other-member-or-custom-prop/69007)._