Just wanted to get some different opinions of using UDT’s in your projects.
Are they complex UDT’s?
Do you use them with Modbus devices?
Do you mix them with other tag types or use UDT’s exclusivly?
The company I work for is trying to figure out if UDT’s would fit well into the projects we do.
One of the main drivers behind using UDT’s is the ability to easily link them to templates and to easily manage alarm limits. However, we have methods in place now that work perfectly with just OPC and memory tags.
Up until now I have never deployed UDT’s in a project because modicon processors do not have UDT’s so it seemed to me to be more of a time sync to create UDT’s verses just creating flat OPC tags.
By the way, given that alarm limits should be much easier to write, I have put a new topic on the ideas forum. Please upvote it if you agree with me that all properties should be read/write instead of just a few of the properties.
For in Ignition using UDT’s I believe depends on the application. If you have multiple pieces of equipment that are essentially the same then UDT’s are great. If its a one off then UDT’s aren’t worth the time since you can still maintain a consistent tag folder structure without it.
If your doing multiple at pieces of equipment that are the same then UDT’s can save you a ton of time since you can build out your tag structure to where you just feed in a UDT parameter to set your device as you build at your tags. With Modbus doing them by device may not save you time unless the device addresses are grouped in a way that you can use the parameters in UDT’s. But even that depends on your situation. If they all need the same alarm functions every time then building a UDT and then assigning each one an address could still save you time since you would only have to do your alarm setup once. It would also allow you to change the alarm configuration for all of them by editing just your main UDT structure.
In the projects I do, its always a case by case basis in deciding if a UDT is of value or not. I have some very complex UDT’s and some very simple ones and have it working with a mix of different PLC’s. Some of the equipment I work with are similar to Modbus in that they don’t use UDT’s in the PLC but I still built UDT’s in Ignition because I had multiple lines running the same equipment.
You can use UDTs for all repeating tag structures, regardless what the PLC involved can or cannot do. The UDTs in Ignition should reflect your visualization and supervisory control requirements. UDTs are easiest to deploy if parameterization can help generate OPC item paths, but that is not strictly necessary. A single UDT in Ignition can include data from multiple tags from different PLC UDTs.
Do not just copy the UDTs from your PLC into Ignition. Only include the OPC items you actually need.
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.
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.
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.
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.
