Many terms are frequently used when discussing UDTs:
A Definition represents the structure of a UDT. Definitions don't run, so Tags inside of a Definition won't poll or subscribe to anything. Rather they represent a Tag structure which Instances will inherit from. Changes made to a Definition are automatically applied to any Instances of that Definition.
In the Tag Browser, UDT Definitions are always located under the UDT Definitions tab.
Instances are running copies of a Definition. All Instances have a "Parent Type", which is the definition that the Instance is inheriting from. The structure of an Instance is defined by it's parent Definition, so you can not add new Members to an Instance. However, you can override the values on properties in any Member.
In the Tag Browser, UDT Instances can be found under the Tags tab, and are signified by either a plain white Tagicon, or a Tag icon with a vertical stripe. Furthermore, you can expand the UDT Instance and find the members (other Tags) in the UDT.
Parameters are user created properties that can be used to create parameterized data templates. Parameters are configured on Definitions, and their values can be overridden on individual Instances. You can replace values on a member in a UDT with a reference to a parameter, allowing for For example, if a data type consists of three OPC Tags that only differ by a number in the path, you can use a parameter for the "base address", allowing instances to be created with only one setting.
The top level item in a UDT.
Members are the Tags inside of a data type or instance. Members are always under a Root Node. Members can be standard Tag types or an instance of another UDT.
Instances are copies of a Definition, but in some cases you may wish to change the value of a property on a particular member (Tag) in a UDT instance. This is called Overriding the property, allowing the property to have a value that deviates from the Definition.
UDT Root Node Properties
While editing a UDT Definition or Instance, the Tag Editor will show some unique properties on the Root Node.
|The name of the UDT Definition.|
|Parent Data Type|
Both Instances and Definitions have this property, but the implications of the property are different.
On a Definition - The name of the UDT Definition that this Definition is inheriting from. If blank, then the UDT being edited does not inherit from another UDT.
On an Instance - The name of the UDT Definition this UDT is an instance of. Changing the Parent Data Type of an instance is not supported.
|A collection of parameters configured on the Definition. Note that you can only add or remove parameters on Definitions.|
A color that will be applied to the Definition and any Instances. This property is only cosmetic, but can be useful to have certain UDTs stand out from others in the Tag Browser.
Assigning Colors to UDTs
UDTs can be color coded, which applies a color to the Root Node. This is purely a cosmetic change, but can be helpful in systems with a large number of instances, as the colors can make certain UDTs stand out from one another.
Color is applied to the Definition, via the Type Color property.
Any instances of that type will apply the color to the Root Node.
Binding to UDTs
Both Perspective and Vision feature a "binding" system, that allows components in those modules to display live values on Tags. In regards to UDT instances, component bindings can bind to members just like any standard Tag, but they can also bind directly to the UDT instance, which results in the binding receiving live live values from all members of the UDT.
In the image below, a Perspective Markdown component has a Tag binding on its source property. The binding is leading to the root of a UDT instance. As a result, the member values are shown on the component. They're also live values, so any value changes on any member will appear on the Markdown component.
In Vision, this is also possible, but you'll want to point the Tag binding at the .jsonValues attribute on the Tag, which involves manually typing it out in the binding window as follows: