UDT Definitions

Creating the UDT from OPC Browser

In the following example, we used a Dairy Simulator which supports UDTs. We will use the second method from above, that is, creating the UDT from OPC. In our Dairy PLC, let's say we already have a motor UDT setup, and now we will create the UDT in Ignition.

1. From Tag Browser, click the OPC Browse icon.
    
2. Under the Dairy folder, go to the Overview folder and find the Motor 1 folder.
   Motor 1  has two Tags: AMPS and HOA.
   
   
3. Drag the Motor 1 folder from the OPC Browser to the Data Types folder in Tag Browser.
   A window prompts you asking if you want to Create Type or Create Tags. Click on Create Type.
   
   
    

4. The Tag Editor window will open showing you the Tag structure of your UDT. Notice the two Tags; Amps and HOA are automatically part of the UDT structure. 
   
   

   Tag Editor Structure and Details Icons

   There are two icons on the top right side of the Tag Editor. The Tag icon displays the Tag structure of the UDT. The Information icon contains an area to add notes and check diagnostics. You can toggle these icons to switch back and forth between the Tag Structure and the Details.

   

   
   

5. In the Tag Editor, change the Name from Motor 1 to Motor to make the type name more of a generic name.

6. Right now, each Tag is pointing to a specific address in the PLC. Select the Amps Tag to see that it is pointing to Motor 1 in the PLC.
   
   

   

   
   

   Because we are creating a UDT, we don't want to point to one specific set of Tags. We want each instance of the UDT to reference a different set of Tags. To do that, we need to add a parameter to the UDT.  Parameters are custom properties on data types. You can use the parameters inside the type or instance definition to create parameterized data templates.
   
   For example, if a data type consists of two 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.
    

7. In the Tag Editor, with the Motor data type selected, click the Edit  icon next to Parameters property to add a new parameter.

8. Click the Add  icon, and enter the name for your new parameter (i.e., 'MotorNumber'). 
   
   

   The following feature is new in Ignition version 8.0.15
   Click here to check out the other new features

   
   As of release 8.0.15, you can also specify a data type for the parameter.
   
   
   

9. Click Commit to save the parameter.  To cancel the entry and go back to the previous window, click Revert.
   
   
   
   

10. For each Tag, we can substitute the Motor number with the 'MotorNumber' parameter we just created. With the Tag Editor still open, select the Amps Tag. 

    1. In the OPC Item Path field, click the binding  icon, select Edit, and the Amps > OPC Item Path window will open. 

    2. Place your cursor at the end of 'Motor1', delete the '1', add a space, and enter '{MotorNumber}'.  Don't forget the curly braces. In the OPC Item Path it will look like the following, then click Commit to save your updates and go back to the previous window. 
       
       

       

       
       

11. Repeat Step 8 for the HOA Tag. The OPC Item Path will then show the 'MotorNumber' parameter for each of the Tags. 

12. Click Apply.  
    

13. Click OK to save the UDT. You will then see the Motor UDT in the Data Types folder. If you expand the Motor UDT, you will also see the Amps and HOA Tags. Don't panic if you see the exclamation point  next to any Tags. This is normal! The Tags are defined, but they don't have any values which is the reason for the Bad_Stale warning. They are not suppose to have values. The UDT instances you create from the UDTs will contain the values.  

    

1. Select the Tags folder in the Tag Browser.
   
   
2. Click the Tag icon on the Tag Browser toolbar, and select Select New Data Type.
   
   
    

3. When editing complex Tags, the Tag Editor window appears a bit differently then the Tag Editor for a standard Tag. The member tree structure is presented on the left. By selecting a member (i.e., Sensor) and clicking the Tag  icon, you can add different Tag types, and the properties for the selected Tag appears on the right. 
   
   

   

UDT Features

There are many features of UDTs that allow more control over the definition and instances

Extending Other Types

User Defined Types can extend other UDTs to add additional members, or override default values. The Parent Type property (with the main/top UDT member selected) can be modified by selecting another UDT from the dropdown. This will add all members of the selected UDT to this UDT, and you can add additional Tags or change default properties. 

Adding Members to a Data Type

Simply click the Tag  icon on right side of the Type Structure. Data types can contain standard Tags like OPC and DB Tags, as well as folders and instances of other complex types.

Adding Parameters

Parameters, which can be used for property expansion in member Tags, can be added by selecting the data type in the member tree. If a data type contains other complex types in it, there may be various points in the tree with custom parameters. While a data type can override the parameter values inherited from a parent, new parameters can only be added to the root node of the new data type. 

Configuring Member Properties

The Tags inside of data types are configured much like normal Tags. However, in this case, the values can be thought of more as "default values", which will be used unless other values are specified when the instance is created. Most of the values configured in the data type can be modified later in subtypes or instances. Furthermore, unlike normal Tags, in the context of a data type many properties (generaly the string based properties) can reference the custom attributes of the type in order to build parameterized Tags.

Attribute Referencing and Parameterized Types

As mentioned above, many properties in the member Tag configuration can reference the parameters available in the data type. When instances are created, these references are replaced with the values defined for the type. Parameter references also support basic offsets and numerical formatting, providing a great deal of flexibility. To reference a parameter, use the syntax {ParameterName}.

To offset a value, use the form {ParameterName+offset}.
To format a value, use the form {ParameterName|format}. The format pattern is the same as that used for the numberFormat expression function. In short, "0" can be used to require a digit, and "#" can be used for optional digits. ie: ##0

Example:

For this example, we'll assume that we're parameterizing the OPC Item Path, and that the data type has an integer attribute named BaseAddress defined. We'll pretend the OPC Server provides Tags named like DataPoint1.

Standard referencing

OPC Item Path: DataPoint{BaseAddress}

Offset

Imagine that our data type had three fields, and these were laid out sequentially in the device.
Instead of specifying each address for each Tag, we can simply offset from the base address:

Member 1: DataPoint{BaseAddress+0}
Member 2: DataPoint{BaseAddress+1}
Member 3: DataPoint{BaseAddress+2}

Formatting (with offset)

Continuing from the example above, imagine that our OPC server actually provided addresses in the form DataPoint001, in order to stay consistent up to "DataPoint999". This can be accommodated
using number formatting in the reference:

Member 1: DataPoint{BaseAddress+0|000}
Member 2: DataPoint{BaseAddress+1|000}
Member 3: DataPoint{BaseAddress+2|000}

This format of three zeros means "three required digits". If our instance has a base address of 98, the resulting paths will be DataPoint098, DataPoint099, DataPoint100.

# This dynamic OPC Item path takes in three parameters to determine the tag path
ns=1;s=[DeviceName]Path/to/tag{BaseAddress+(ParamNum*Multiplier)|0000}

# The OPC Item path resolves to the following assuming the following values:
# BaseAddress = 5
# ParamNum = 8
# Multiplier = 2
ns=1;s=[DeviceName]Path/to/tag0021

Calculations and numerical parameter names

If the parameter names are purely numerical values (we don't recommend this: it gets confusing), then quotation marks must encase the parameter to run any sort of calculations on the value of the parameter.

For example, if a UDT contains a parameter named 0, and its value is 10:

// This will evaluate to 0, because it thinks you mean the integer 0, not the parameter named "0"
{0 * 1000} 

// This will evaluate to 10000, because the quotation marks denote a parameter named "0"
{"0" * 1000} 

Overriding Properties

Subtypes and instances can override the properties defined in parent types. To do this, simply select the override control, the small grey ball () next to the property to override in the member editor. Conversely, to remove the override, simply unselect the control.

Custom parameters can be overridden as well, but it is not required to specify that the value is an override. Simply provide a new value for the property. For inherited parameters, the delete button next to the parameter table will simply remove the override. The parameter can only truly be delete from the type that defines it.

UDT Error Indication

The Tag Editor will indicate if there is an error in the UDT. For example, if you configure circular inheritance (A inherits from B, and B inherits from A), then the Tag Editor will show a UDT Error icon as well as squiggle line under the UDT name. In addition, the Parent Data Type property will show a warning icon in this state.

Trait Badges

Trait badges show the presence of various configurations such as Alarms and Tag History in the Traits column of the Data Types folder in the Tag Browser. Trait badges also appear in each instance of a UDT in the Traits column of the Tag Browser. 

Trait badges are also displayed within a UDT in the Tag Editor.

Pre-Defined Parameters

UDTs have a few parameters already defined to make things easier for you. They give you access to the name and various paths associated with a UDT member Tag. These parameters can be accessed from anywhere in a Tag that a normal parameter can be used. Each of these parameters uses that Tag it is in as a starting point for its path.

How to Edit an Existing UDT

If you make a change to a UDT, all your instances will automatically get updated because they are all of the same UDT type. You can make rapid work of making changes to instances using a UDT.

1. To make a change to your Motor UDT, go to the Tag Browser and double click on Motor. This example adds a new Memory Tag. 

2. The Tag Editor will open. Click on the Tag  icon on the top-right of the Type Structure, and select New Memory Tag.
   
   

   

   
   

3. While still in the Tag Editor, configure the following properties:

   Name:  MotorType
   Data Type: String
   Value: Basic
   
   

4. Click OK. 
   
   

   

   
   

5. Now, each instance automatically gets the new Memory Tag. Expand each of your Motor Tag instances to see the new MotorType.
   
   

   
   
   

Data Type Parameters in Expressions

It is possible to use the value of data type parameters directly in expression bindings within a UDT.  Parameter references can be quickly inserted into an expression.

1. Open the UDT, and select the Edit   icon next to one of the members. 
   
   

2. This opens the Expression window. Click on the UDT Parameters  icon on the right of the expression area, select a parameter, then click Commit. 
   
   

Syntax

Quotation marks are not required when referencing string parameters. The syntax for data type parameter expressions does not differ from Tag and property references when using string values. If you use quotation marks referencing string values, the parameter values will not display correctly. It will display the parameter rather than the parameter's value. 

If the data type of the parameter is not a string, then quotation marks are not required, but can be used.

It does not matter if double quotation marks or single quotation marks ( " versus ' ) are used as long as a matching closing quotation mark is present.

{string parameter} //This expression will evaluate successfully.

Examples

Below is an instance of a Turbine UDT. It contains a string parameter named TurbineLocation.

Inside the Turbine UDT is an expression Tag named Member Location. To show the value of the TurbineLocation parameter on Member Location, the following expression would be used on the UDT definition.

If you use quotation marks referencing string values, the parameter values will not display correctly. The Tag displays the parameter rather than the parameter's value.

The same syntax should be applied to parameters in bindings on alarm properties. Below is an example using the same UDT, but the expression is instead located on the Display Path property of an alarm.

Notice, that static values are included in quotation marks, and non-string parameters are outside of the the quotations marks.

Combining Parameters and Tag References

Because parameter and Tag references differ in syntax, some consideration must be made when attempting to use both in the same expression. Tag references must not be placed inside of quotes. After adding a string Tag to the Turbine UDT, a reference to the Tag can be added to Member Location's expression. Single quotes were added to create a space between the Member's Location and the string value.  

Here's what it looks like in the Tag Browser.

Quick Reference

"This is a string"

{turbine_location}

{[.]String Tag}

"The turbine is located at " + {turbine_location}

{turbine_location} + " " + {[.]String Tag}

"The Turbine " + {[.]String Tag} + " " + {turbine_location}