UDTs: where they pay off, and where they trap you

The argument for UDTs makes itself: define the motor once, stamp out forty, change the definition and all forty follow. That part works. The part worth thinking about in advance is what happens when one of them stops following.

What you are actually buying

A UDT is a tag definition you instantiate. Parameters act as variables referenced by properties on the members, and the common use is making an OPC item path dynamic so each instance points at its own device address. Parameters can only be added or removed on definitions; an instance can override a parameter’s value but cannot introduce a new one.

The payoff is larger than consistent naming. A definition carries alarm configuration, history settings, scaling and tag event scripts, so forty motors get the same alarms and the same history without forty separate decisions. Bindings benefit too: a component can bind to a member like any other tag, or bind directly to the instance and receive the whole structure, which is what lets one screen serve forty pieces of equipment.

Inheritance extends this. A data type can extend another to add members or override defaults, so a specialised motor keeps everything the generic motor has and adds what makes it specialised.

Trap one: the override nobody thought to look for

An instance can override the value of a parameter, and of most properties. It cannot add members — structure comes from the definition — so overriding values is the only escape valve an instance has, and it gets used.

The scenario usually runs the same way. Someone needs one motor to behave differently, overrides a property on that instance, and moves on. It works. Nobody records it. Eighteen months later a different person edits the definition, watches thirty-nine instances update, and starts debugging the fortieth as though something is broken. Nothing is broken. The override is doing exactly what it was asked to do.

Ignition is not hiding this from you, which is the useful part. A property that differs from the definition shows a green indicator, and a member carrying overrides gets an attribute icon. Better, there are two tools that answer the question directly: the UDT Hierarchy Tool shows inheritance between definitions along with overrides of inherited properties, and the Tag Report Tool can list overridden properties as a column and filter for tags that override parent properties.

So the honest version of this trap is not that overrides are invisible. It is that nobody looks before editing a definition, and nothing prompts you to. Running the hierarchy or a report first turns a debugging session into a thirty-second check.

Trap two: the definition nobody wants to edit

The blast radius of a definition edit is every instance at once, which makes people cautious, which makes changes go somewhere other than the definition — into overrides, into a near-duplicate type, into scripts patching around what the definition should have done. The structure survives and quietly stops governing.

You can test. Tag providers are not limited to one, and UDT definitions export and import as files, so a definition can be copied into a second provider and changed there. Worth knowing when you do: exporting an instance does not bring its definition with it, so the definition is a separate export, and definitions should be imported before instances.

What you cannot do is point an existing instance at the modified copy — changing the parent data type of an instance is not supported. So the test is a fresh instance of a copied type rather than the thing you are about to ship, unless you can stand up a dev gateway from a backup and get both the definition and its real instances. That is usually close enough to be worth doing, and it is worth knowing the gap exists.

Trap three: the rename that orphans everything

This one is quieter and more laborious to undo than either of the others. A definition can be renamed after instances exist, and doing so produces orphaned instances — instances no longer associated with a definition.

Inductive Automation documents no warning here, and its own advice is to avoid renaming a definition unless you are also willing to update the instances. It is worth treating a definition name as fixed once anything has been built on it, in the same way you would treat a database column name.

What UDTs are genuinely bad at

Equipment that is nearly the same but not quite is where UDTs strain. Three variants differing in one member each can be modelled with inheritance and usually should be. Twelve variants differing arbitrarily produce either a definition full of members most instances ignore, or a family of near-duplicate types maintained in parallel. The near-duplicates are often the lesser evil, because a bloated definition hides the problem while duplicate types at least make it visible.

The other limit is worth stating precisely. A UDT standardises tag-level behaviour — alarms, history, scripts, scaling. It says nothing about the PLC logic underneath, or about how the equipment is actually operated. A tidy tag browser makes it easy to assume more consistency than you have.

Worth deciding before you build forty

Which properties are instances allowed to override, and where is that written down?
Do you run the UDT Hierarchy Tool or a tag report before editing a definition, or after something surprises you?
When a variant appears, is the answer inheritance or a new type — and who decides?
Are your parameters carrying device addressing, or have they started carrying business logic?

None of these are reasons to skip UDTs. The alternative is a few hundred hand-built tags, which is worse in every direction. They are the questions that decide whether the structure is still helping in year three, or whether it turned into something everybody works around.

Common questions

What is a UDT parameter for?

Parameters act as variables referenced by properties on the UDT members. The common use is making an OPC item path dynamic, so each instance points at its own device address while sharing one definition. Parameters can only be added or removed on definitions.

Can a UDT instance override the definition?

Yes. An instance can override the value of a parameter and of most properties, though it cannot add members, because structure comes from the definition. Overridden properties are indicated in the tag editor, and the UDT Hierarchy Tool and Tag Report Tool can both list them.

How do I find which instances override the definition?

The UDT Hierarchy Tool shows inheritance between definitions along with overrides of inherited properties. The Tag Report Tool can include an Overrides column listing overridden properties, and can filter for tags that override parent properties.

What happens if I rename a UDT definition after creating instances?

The instances become orphaned, meaning they are no longer associated with a definition. It is safer to treat a definition name as fixed once anything has been built on it.

When is a UDT the wrong choice?

When the equipment is only loosely similar. A handful of variants can be handled with inheritance, but many arbitrary variants tend to produce either a definition full of members most instances ignore, or a family of near-duplicate types maintained in parallel.