For sure. I use UDTs for tracking operator information. If they move to a different workstation, all of their previous information can follow them. Plus I can use one project with indirect tag bindings.
I do CNC machines. I have UDTs built for bar feeders, mills, lathes, grinders and so on. I don’t care what is at the machine end. So long as I get the relevant data to the relevant UDT item. This has been effective for me for several reasons. Chiefly organization. A couple of weeks ago, I got a machine in that is two mills in one and just made a new folder and used two of my mill UDTs. Worked like a dream.
I have drunk the UDT kool-aid. You guys should too.
+1 for that
I agree with the last three posts; if there’s more than one instance, UDT it. You’ll thank us later.
Expanding on what @pturmel said, it doesn’t matter if the PLCs have UDTs or not. One thing Ignition has done for us is make it easy to slap a modern HMI on really old PLC hardware that we were previously considering replacing as it was too time-consuming to bring it up to our current HMI standards using past HMI products without reworking the PLC code. And the PLCs didn’t have the ability to do a fraction of what we’d do on the PLC end with modern PLCs.
With Ignition UDTs, scripted tag creation and overrides make it relatively easy to cram any mess (think lovely tag addressing like B3:10/1 or HR57, etc.) from the PLC end into standard UDTs that work with standard templates in Ignition for fast development of consistent HMIs with features we’d never spend the time on if we had to reinvent the wheel for each project/PLC rather than reusing a standard code base we continually improve on that–from the HMI end–works for all our PLCs, old and new.
Programmers still far prefer new projects with PLCs that support tag browsing, UDTs, AOIs, etc, but Ignition has allowed us to make it difficult for operators to tell the difference between running on ancient PLCs versus the latest stuff. It all looks and works the same on the HMI end. We have fancier features we’re not going to add to the old PLCs (not feasible) disabled in the UDTs and the templates automatically adapt to this so all the basic functionality looks and works the same from operators’ perspective.
Everything has already been said, but I’ll say it again. UDTs allow you to standardise repeated objects, which will streamline your development and give you more time to spend on more pressing tasks. If you relate it to back when AB plcs didn’t have add-on instructions, the same rungs of ladder would be copied 10s or hundreds of times say for each valve, and the relevant addresses replaced. It made the code difficult and overwhelming to navigate. It also means that, without comparing every block of rungs, you have no idea if each device is being controlled in the same way or not. Same thing with Ignition UDTs vs simply copying and pasting tag structures. You know they should all have the same tags and addressing structure, but without going through each and every one, you don’t know. It significantly reduces time testing as well, and you can test the UDT once for functionality, and know that the functionality will work for all of your other instances. Of course you still need to check addressing and wiring etc.
Thank you all for the responses.
I believe my main hesitation to jump into UDT’s comes from the fact that we have almost no equipment that is repeated. All the areas of the facility are unique.
One UDT we have been considering is an “Analog with Setpoint” type UDT. This would have an OPC item for the field value and 4 memory tags to hold the alarm setpoints. Again, this would allow for easier alarm management then using scripting to get and set alarm limits.
Almost all objects I have on a screen are template instances, but I am either dragging in a direct OPC item for binding, or coping and pasting the tag path for indirect tag referencing.
Sounds like a good candidate. The repeatability mentioned above is not limited to top-level objects on a PLC by PLC basis. Anywhere you have strictly repeating data organization requirements–generally matched to some repeatable functionality in Ignition–is a good excuse for a matching UDT.
This. Any repeating structure from the device level (motors, sensors, etc.) right up to full machines (nesting their component UDTs) in cases where you do have repeating machines. If you don’t have repeating machines, you’ll still benefit by putting other logically associated repeating data into UDTs at a more fine-grained level.
I currently dont use them. I use an almost UDT type structure with regular tags. I have “template” dataset tags that hold things similar to a UDT and I feed in a couple of inputs to a script and generate the tags that I need. Things are so different from site to site in Oil and Gas that I feel like I would be modifying templates left and right. I think there may be some performance gain by using UDT’s but I have 85000+ tags and the tag centric stuff has not been an issue for me performance wise.
This is what I do for all my templates that use UDTs as well. I never use UDT Type parameters for a number of reasons
I say if in doubt, UDT.
I use UDT’s all the time. Sometimes can be a little more work on the front end. But my projects typically keep reusing the same ones, so it pays off. Makes my indirection on faceplates so simple.
Could you comment on why you prefer indirect tag path referencing to UDT type parameters?
The only thing I can think is the ability to use multiple UDT’s as template parameters that aren’t strictly identical but contain similar tag structures.
- at a glance, it’s not possible to see by looking at a component’s properties which UDT instance has been bound to a UDT type property. E.g. in the screenshot below, I have no idea which Tower UDT is bound, I have to click on the binding to find out.
It’s also far slower to populate template parameters than simply modifying a parameter string value. I tend to use 2 parameters: DeviceParentPath and DeviceName, then combine these together in an internal parameter DeviceTagPath, which also aids in speed of populating values
It’s not possible (as far as I know) to pass UDT instances in using a dataset to the template repeater/canvas. (This alone stops me from using them altogether).
It looks like they’ve become less restrictive in v8 in terms of accepting other similar UDT types, but that was always a big turn off for me where if a template had a UDT type parameter assigned, it would accept that UDT type and that only.
In v7 I also found using UDT types had performance issues with large numbers of templates on the page, however as I understand it this has been significantly improved in 8 (and in fact may even be more efficient now than the tag path method)
Also, not mentioned above i think. If you have differences between your UDTs, your popups or templates can still be single. Meaning that you can check the UDT-type of any path. Based on the type you can hide, or load components only occuring for this specific UDT. (you can also select template path dynamically based on UDT type)
This way you only have one place to maintain the popups/templates.
The simple answer is you should UDT it. Regardless of repeating patterns. I even UDT a signal bool, and real, and int, and string. In fact, I don’t let any data enter Ignition without first going through a UDT of some shape or form. This gives me great flexibility to bulk control my tags by parameterising them. Even down to your scan class name can be parameterised. So you can choose to put all BOOLs from a certain area or a PLC into a certain scan group. Or give them all a unique security role.
Similarly, all visualisation components should be a template for maximum bulk control. I you suddenly wanted to change all your fonts, you edit one template called “Large Label” rather than just using the Label component. It adds overhead, but it’s worth it.
These are truly powerful thing in Ignition, that others amazingly struggle with. Use it if you can.
Agree with everything said above. Also a great feature is the drop target in your templates. Once your UDTs and templates are created, you can just drag any UDT instance onto the template instance and voila. Then you can set any parameters as needed.
And in UDTs, you are not limited to just OPC tags, you can mix and match OPC, memory tags, expression tags whatever.
I agree, and in addition…
We use Siemens PLC’s with the S7 driver which has no browsing capability since it writes/reads directly to the PLC memory areas. We make a UDT for every data block (DB) that the HMI uses. This allows us to quickly change the tag references to another DB number, modify alarming quickly, add engineering units, etc.
I wish that creating a UDT did not force me to use the expanding menu… we have so many it is a bother to create tags derived from them. It would be great to be able to right click on the UDT type and get a “make tag from this UDT” function. I have recently created an automated way to copy tag rows from TIA portal to automatically create UDTs and the derived tags. Very helpful.
Can you share this?
We also work mainly with Siemens and TIA portal and I know recreating UDTs and tags by ‘hand’ is very…
Agreed. Yeah, we have some bulk UDT Instance management screens and scripts that make life a little easier too. Hey, if you’re working with Siemens TIA, have you tried the on board OPC-UA? That way you can reference tags by symbol and not address and you can optimise blocks.
Yes, I’ve tried, but I wasn’t satisfied…
When I exceed around 2000 tags, the communication with the onboard OPC-UA became unstable and every few seconds every tag had errors…
Can you share this UDT Instance management screens and scripts of yours?