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.
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.
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:
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):
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.