Most Ignition projects start the same way: someone browses the PLC, drags a few hundred tags into the Tag Browser, and builds screens against them. It works for the first line. By the fifth line, every machine is a little different, alarm settings drift, and adding a sixth means repeating the whole exercise by hand.
User Defined Types (UDTs) fix that. A UDT is a template for a kind of equipment (a motor, a pump, a filler, a line) that defines every tag it has, how each one maps to the PLC, and its alarms, history, and scaling. You build the template once, then create an instance for each real machine.
What goes in a UDT
A good UDT describes the equipment the way operators and engineers talk about it, not the way the PLC happens to lay out its memory:
- Member tags for the values you read and write: run status, speed, faults, counts, setpoints.
- Parameters for what differs between instances, such as the device connection, the PLC tag prefix, or a line number. Member tags reference them in their OPC item paths, for example
ns=1;s=[{Device}]{Prefix}.Speed. - Alarms, history, and scaling set on the definition, so every instance behaves the same.
- Nested UDTs for repeated parts: a line can contain several motor UDTs instead of redefining motor tags each time.
When the definition changes, every instance picks up the change. Add an alarm to the motor UDT and every motor in the plant has it.
Name things for people, not PLCs
The tag path becomes the address everything else uses: screens, alarms, historian queries, reports, and integrations. A path like Plant/Packaging/Line3/Filler/Speed reads the same way to a maintenance tech, a report writer, and a script. Settle on a hierarchy (site, area, line, equipment) before you create the first instance. Renaming later is possible, but it touches everything that references the old path.
Make screens follow the model
In Perspective, build one view per UDT and pass it the instance path as a parameter. Bindings inside the view use indirect paths built from that parameter, so the same view works for every instance. One motor popup serves every motor, and a fix to that popup reaches the whole plant.
Mistakes we see most often
- Overriding instead of parameterizing. If you find yourself overriding the same member on many instances, that difference belongs in a parameter or a second UDT.
- One giant UDT. A “Line” type with hundreds of members is hard to change safely. Compose it from smaller equipment types.
- Copying definitions to make variants. Two nearly identical definitions drift apart. Use inheritance (a parent type) or nested types for the shared part.
- Skipping history and alarm settings on the definition. Setting them per instance is how the fourth line ends up without alarms.
Where to start on an existing project
You don’t need to rebuild everything. Pick the most common piece of equipment, build its UDT, and convert those instances first. Point the existing screens at the new paths, prove it on one line, and carry on from there. The payoff comes the next time a machine is added: it becomes a new instance with a few parameters filled in, not a day of copying tags.