Curious about your UDT usage. (Studio 5000)

[AutomationTechBrian]

I'm focusing on Rockwell programming for a couple of projects, and I've been thinking about some of the details I've come across while working with others' project files. It's the little details that I'm curious about. The thing I'm thinking about this morning is this person's use of UDTs for all the components, like HMI tags. Usually, I just make my tags like 'HMI_EnableMachine,' and then I have all of my 'HMI_' tags in one area in the controller tags. But in the file I'm working on, he used a UDT for all the HMI tags... 'HMI.EnableMachine,' etc. From an organization standpoint, it's nice. You have one line in the controller tags, and you can expand it and then see all the HMI tags. He has a UDT for every component of the machine... Press, Printer, RollFormer, SafetySystem, etc. Up to this point, I've only used UDTs when I knew all the tags beforehand. When you edit a UDT that is already being used, you get a warning about the consequences of editing. I assume it's the consequences of eliminating something, and not adding new tags. But I think I'd like to use UDTs more this way, live editing, to make the program more organized. So I'd like to see what you all think of using UDTs like this. Thoughts? Experiences?

And while we're talking, what about AOIs... is there a big collection of AOIs somewhere, like on the Rockwell site? I've picked them up here and there, from manufacturers like ABB for a VFD. But they are used so much, that I wonder about a larger collection to browse online.

 

[Nova5]

PLaces I've worked had motor/vfd/valve/etc control UDTs. They tied them into their AOIs. WOuld have specific in/out mapping tags for IO. Option settings to enable or disable logic functions and HMI display functions, etc. it worked fairly well, kept tags to a minimum as pretty much everything for VFD on Belt 5 was found in the VFD_Belt5 UDT.

 

[AutomationTechBrian]

PLaces I've worked had motor/vfd/valve/etc control UDTs. They tied them into their AOIs. WOuld have specific in/out mapping tags for IO. Option settings to enable or disable logic functions and HMI display functions, etc. it worked fairly well, kept tags to a minimum as pretty much everything for VFD on Belt 5 was found in the VFD_Belt5 UDT.

And that's how I've associated UDTs up to this point. This person has gone further with it's usage. And keeping a library of these tags would give me a leg-up and a similar project.

 

[CLanford]

I personally am a huge fan of UDT's and AOI's, especially in applications where you're using either complicated data or copying and pasting multiple functions or machines in an application. I use AOI's for any complicated process or unit that normally requires a large amount of programming, and will have multiple machines or units that require it. For example I may have a conveyor system with 10 VFD's. I create one AOI that controls the VFD, and then copy and paste for each VFD that I add. And I make the inputs and outputs of the AOI useable so I can pass in and out different frequency commands, start/stops, etc to make it customized for each VFD.

I am currently working on a Line that has other UDT's nested within a larger UDT. I've found that complicated UDT's like this are generally used in assembly processes where you are passing a part down an assembly line where maybe you have unique operations and stations where components are added, and you'd like to keep track of all of that. Each part or subcomponent can have a register associated with whatever you're adding or changing, and can be used for traceability later on or then dumped into a database at the end of the process.

 

[drbitboy]

Regarding the restrictions for online editing of UDTs, the UDT could be initially designed with a few dozen spare bits, words, reals, etc., so if there is a need to add something online, then it can be accomplished by changing only the code to use some of those pre-existing and unused spares, and not changing the UDT.

This is not in the least a new idea.

-

 

[PLC Pie Guy]

I would feel lost without UDTs and AOIs now that they are in 99% of my projects. I hate the thought of doing anything on a software or platform that doesn't have the ability to use these features. It just makes things so much more organized and so quick to program. Also, I know if something doesn't work, its not my code, its simply an interlock bit I didn't configure, or a scaling issue within my UDT, the logic is already tested as I tend to use them over and over. It make me shiver a bit when I go back and look at projects I wrote 8, 10 years ago, before I had the knowledge to use re-useable code.

 

[drbitboy]

i would feel lost without udts and aois now that they are in 99% of my projects. I hate the thought of doing anything on a software or platform that doesn't have the ability to use these features. It just makes things so much more organized and so quick to program. Also, i know if something doesn't work, its not my code, its simply an interlock bit i didn't configure, or a scaling issue within my udt, the logic is already tested as i tend to use them over and over. It make me shiver a bit when i go back and look at projects i wrote 8, 10 years ago, before i had the knowledge to use re-useable code.

+1

 

[AutomationTechBrian]

I would feel lost without UDTs and AOIs now that they are in 99% of my projects. I hate the thought of doing anything on a software or platform that doesn't have the ability to use these features. It just makes things so much more organized and so quick to program. Also, I know if something doesn't work, its not my code, its simply an interlock bit I didn't configure, or a scaling issue within my UDT, the logic is already tested as I tend to use them over and over. It make me shiver a bit when I go back and look at projects I wrote 8, 10 years ago, before I had the knowledge to use re-useable code.

I could see this being the case for me as well. Because of the diversity of my customers, I have almost every major brand of PLC software on my laptop. As I build a library I could see reaching for Studio 5000 more and more often. Like you, I thought about a program I wrote in 2018. The machine runs great, but my organization was pretty basic. I would be embarrassed if somebody else had to work on it.

 

[johnd_125]

I make use of UDT's as described above. Repetitive devices like Motors, VFD's and Butterfly Valves all get a UDT. Defining one tag with a UDT gets you all the associated tags, automatically and organizes them nicely.

I'm not as sold on AOI's for anything but very small chunks of programming. I support a conveyor system from an international OEM and most of their programming is AOI's. Maybe I am missing something but if I want to monitor a bit within an AOI, I'm screwed. Can't see it. If one out of 30 conveyor motors needs an extra interlock to shut it off, I'm screwed. Do I create a NEW AOI just for that motor? I suspect thats what the OEM does because they have a dozen different AOI's with nearly the same name. Multiple, nearly identical, AOI's kind of defeat the purpose. Of course there is no way for me to know which AOI does what.

Also, with properly named tags I bet I can copy a subroutine and search and replace all instances of Motor1 to Motor2 about as quick as some can copy their AOI and set it all up for Motor2.

I can see how complex AOI's may save time for the original programmer but for an overachieving farm boy like me it just feels like it takes more time to troubleshoot and make changes. Maybe I haven't given them a good enough try and I am missing something?

 

[AutomationTechBrian]

Those are good points to think about. Good portion of my job is troubleshooting. The thought of making it harder to troubleshoot doesn't sit well. I need to think this through a little.

 

[CLanford]

I'm not as sold on AOI's for anything but very small chunks of programming. I support a conveyor system from an international OEM and most of their programming is AOI's. Maybe I am missing something but if I want to monitor a bit within an AOI, I'm screwed. Can't see it. If one out of 30 conveyor motors needs an extra interlock to shut it off, I'm screwed. Do I create a NEW AOI just for that motor? I suspect thats what the OEM does because they have a dozen different AOI's with nearly the same name. Multiple, nearly identical, AOI's kind of defeat the purpose. Of course there is no way for me to know which AOI does what.

I agree, that is one big downside to AOI's. The inaccessibility of AOI data can make it tough to troubleshoot, especially if you're trying to work on multiple units that are being controlled across separate AOI's. When I create AOI's like this, I make the things that typically go wrong (On/Off, commanded speed vs output frequency of a VFD, etc) visible outside the AOI so I can monitor the tag externally in a trend, Xref or whatever. Then I dive into the specific problem AOI to further troubleshoot a problem. But you're right, for Bubba on night shift it's gonna be a problem.

 

[cwal61]

If open the AOI in the organizer and select logic. It will open the subroutine logic for that AOI. If your online in the top right-hand corner, you'll see a drop-down list. Select the device name of the AOI to see live data and logic execution. I think, but not sure this has been available since Version 20.

 

[5618]

I use UDTs extensively and AOIs are awesome too. A lone base type tag is rare in my new stuff. I try to make tagnames as descriptive as practical. I think that good tagnames and good rung structure greatly reduce needed program commenting. I'm in-house and there's usually a download opportunity within a few weeks, so I can add temporary online then do a download later to add it to the UDT or AOI.

When I add something online, I'll use underscores as placeholders until I can do a download. Something like Conv21_Gate_NewFeature will later get replaced in the PLC and, if applicable, the HMI with Conv21.Gate.NewFeature when I get to the download.

On rung structure, I make what are probably larger than average rungs with multiple branches to generally group the related logic to perform a function. Siemens sort of turned me onto that concept with the ladder development in TIA. One rung called a network with reduced visibility of surrounding rungs changed my thinking to this. It's easy to see the related logic when grouped and it's easy to duplicate. I think it improves readability.

A simplistic example: I hate seeing XIO Condition - RTO, then a completely separate rung with XIC Timer.DN - OTE Something, then another separate rung to reset the timer. I'll make that all branches of one rung unless there's a reason otherwise.

In my post history are some examples like all the logic for a pump hourmeter is grouped as one rung. In general, all the I/O mapping for each drive is a bundled rung. Motor fault timers and associated alarm logic are a bundled rung. And so on...

 

[AutomationTechBrian]

I

On rung structure, I make what are probably larger than average rungs with multiple branches to generally group the related logic to perform a function. Siemens sort of turned me onto that concept with the ladder development in TIA. One rung called a network with reduced visibility of surrounding rungs changed my thinking to this. It's easy to see the related logic when grouped and it's easy to duplicate. I think it improves readability.

A simplistic example: I hate seeing XIO Condition - RTO, then a completely separate rung with XIC Timer.DN - OTE Something, then another separate rung to reset the timer. I'll make that all branches of one rung unless there's a reason otherwise.

Yes, I started doing that a while back, as well. I noticed that in a couple of projects I had to troubleshoot. When I troubleshoot, the first thing I do is find the output and follow it back. So it only makes sense to have fewer rungs to look at.

I work with Siemens step 7 classic every Thursday, so I understand what you're saying. In fact, I made a set/reset aoi to speed things along when I was under the gun to create a bunch of seal-in rungs in a short period of time... just like step 7 S/R blocks.