UDT definitions are templates: member names, the Device of a member, addresses, conditions, messages and actions may contain tokens that are resolved when an instance is created or pushed. Tokens never reach the runtime: every materialized variable, alarm and event carries the fully resolved text. This article lists the available tokens, the compute expression syntax, and a worked example that combines them.
Built-in Tokens
Every definition parameter is also a token: a parameter named Base is written as {Base} and resolves to the instance's explicit value, or to the definition's default value when the instance does not set one. The built-in tokens below are always available and cannot be redefined as parameter names.
| Token | Resolves to | Example |
|---|---|---|
| {Instance} | The name of the instance within its asset node, without the asset path. The full name of the instance is the asset path followed by this name. | Pump1 in PLC2.Pump1_Power |
| {Asset} | The full path of the asset node the instance is attached to. | Site/Electrical/Utilities: pump speed high |
| {Index} | The element number of an array member, from First index upward. Available only while an array member expands; see Array Members in the UDT Manager article. | {Device}.{Instance}_StageTemp[{Index}] |
No rows match the filter.
{Device} is not a built-in token. A definition normally declares a parameter of the type Device under the name Device, and {Device} is the token of that parameter. The Device column of a variable member defaults to {Device}, so a member is created on the device the instance names there. Declare further Device parameters, for example PowerMeter, and point members at them with {PowerMeter} to create part of the instance on another device. A definition that declares no Device parameter has no {Device} token, and a member that still uses it is reported as an unresolved token.
In a member name {Device} has a second meaning: it stands for the device of that variable. The materialized variable keeps the token, so the variable follows a rename of its own device, also when the member takes its device from another Device parameter.
The full name of an instance is composed of the path of its asset node and the name given in the Add instance dialog, separated by dots, for example WTP.Distribution.Pumps2.Pump1.
{Instance} resolves to the last part of that name, Pump1, and not to the full name. This keeps materialized variable names short, and it means the same definition produces the same variable names wherever its instances are placed in the asset tree. Use {Asset} where the path itself is needed.
Because {Instance} does not include the path, two instances with the same name under different asset nodes produce the same variable names. Place them on different devices, or include {Asset} in the member name, so that each variable has its own name.
Compute Expressions
A compute expression has the form {= expression } and is evaluated after all tokens are resolved, so the expression can be built from parameters and {Index}. The expression accepts numbers, + - * / and parentheses. A whole result is written without decimals, which keeps addresses and point numbers valid.
Compute expressions are accepted in the address fields of variable members, for example %MW{= {Base} + {MeterIndex} * 100 } on Modbus TCP or %MW{= {BaseAddress} + {Index} * 2 } for a REAL array on consecutive registers, and in parameter values and parameter default values, including Number parameters. The Add Instance dialog and the instance detail show the computed result.
An expression that does not reduce to numbers and operators after the tokens are resolved, or that cannot be evaluated, is reported as an error naming the member or parameter, and nothing is materialized.
Worked Example: A Power Meter Fleet
A definition SchneiderPowerTag reads meters that sit 100 registers apart. The shared base address belongs in the definition; only each meter's position is per instance.
Parameters: Base register (Number, default 3000) and Meter index (Number, default 0).
Member address: %MW{= {Base} + {MeterIndex} * 100 }
Instances PM2 to PM5 set only Meter index to 0, 1, 2 and 3 and leave Base register on its default. They materialize at %MW3000, %MW3100, %MW3200 and %MW3300.
Moving the whole fleet to a new base is now one change: edit the definition's Base register default, all instances show Outdated, and one Push re-addresses every meter. A value the fleet shares belongs in the definition as an inherited default; only what is genuinely per machine is set on the instance.
Bulk Create Tokens
The Add Instance dialog resolves two further tokens before the instances are created; they are never stored.
{N} is the running number of the Create multiple fields (Count, Start at, Zero-pad) and substitutes in the Name and in the parameter values. Combined with a compute expression this gives each created instance its own stepped value: Name PM{N} with Count 4, Start at 2 and Base register {= 3000 + ({N} - 2) * 100 } creates PM2 to PM5 at %MW3000 to %MW3300 in one save.
{Device} substitutes the device name when the definition's single Device parameter contains a comma-separated list of device names, in the Name and in the parameter values, creating one instance per listed device.
Slot tokens
Two built-in tokens exist for definitions that are used inside slots (see Slots in the UDT Manager article). {Slot} resolves to the name of the slot the member materializes under, for example MotorA. {SlotPath} resolves to the full dotted path, for example SkidA.MotorA, which stays unique when slots are nested. On members of a definition that is used directly, both resolve to an empty text.
When one definition fills several slots of the same contained definition, its member names must contain {Slot} or {SlotPath} so every slot materializes distinct names. Slot and SlotPath are reserved and cannot be used as parameter names, like Instance, Asset and Index.
Script members do not use tokens in the script body. The body is shared by every instance and reads its resolved values with GetParam instead: GetParam('Instance'), GetParam('Asset'), GetParam('Slot'), GetParam('SlotPath') and every parameter by name. The script triggers Interval, RunWhen and Run at startup do accept tokens.