RSLogix 5000: big general purpose UDT and Add-On.

Elcan

Lifetime Supporting Member
Join Date
Apr 2008
Location
NC
Posts
934
Hi all,
I'm designing UDTs for a RSlogix 5000 project and I would like your valuable comments about this topic.
I have around 10 tanks to control. Some of them have a level sensor, some of them Low Level and High Level Switches. Some of them have a steam valve (ON/OFF) to heat the product. Some have a temperature sensor. Some have a discharge valve. Some a load valve. And so on...
The Add-On will check if the level is high or low, if the discharge valve needs to open according to the level and the temperature, if the steam valve needs to open, if the discharge pump needs to stop, etc.
One approach for the UDTs and Add-Ons is to create a specialized UDT and Add-On for each particular kind of tank. Let's say that there are like 6 different types of tanks. We wouldn't reuse much data structure and code here, but the data and code used will be more optimized.
The other "opposite" approach is to create a UDT that has everything and an Add-ON that does everything (with flags to tell if we are using level sensor or level switches, if there's a temperature sensor, if we are using a discharge valve, etc.). There will be just a "one size fits all" big UDT and a "do it all" big Add-On. There would be unused data and code here.

My questions are:

  • Any real world experiences using a big UDT and Add-On?
  • How much it would affect the PLC perfomance using big generic UDTs and Add-Ons?
  • Do you think that the code would be unnecessarily lengthy and the UDT too comprehensive?
Thank you!
 
My two cents

I have a certain affection for the do everything approach but, with a view towards documentation/readability and the certainty that someone else* will eventually have to look at the logic, I'd have to go with specialized UDTs, etc.

* the someone else may be you six months from now!
 
I also agree with the previous posts. The do-everything approach runs the risk of being hard to implement when the AOI is placed into the main body of the code. the do-everything approach is one of the things that make the AB PID instructions such a challenge to use.

One thing I would say is try to structure your AOIs and UDTs as similar as possible. If multiple tanks share functions code them the same with the same tagnames. It will make it easier for the user to implement when you drop the AOI into the main program; the tagnames will flow more reasonably.

Keith
 
Hey,

I have just executed 2 projects, one with with a long running AOI with lengthy UDTs and the other which is split into modules.

Until you are very clear of the process and variables do not go for 'All Inclusive' AOI.

Its better to have a modularised and smaller AOIs built around structured UDT.
Its easy for diagnostics and easy to understand for others.

Performance wise there was no diffference to the PLC and both behaved the same. But once ONLINE its easy to have smaller things to look into.
 
+1 to the above. The best way I find is to create generic UDT's or AOI's for each component that may or may not be involved in each tank. Then create specialised AOI's for each type of tank you have.

e.g.

UDT "Tank", containing a volume, a temperature, a high level status, low level status, etc.
AOI "Motor". Put general motor control items into here: overload, isolator, run output, auto/man controls, etc. and write some logic to start stop any motor
AOI "Valve". Put general valve controls here - open/closed feedback, solenoids to drive it, and write logic to open/close your valve and check the feedback

Then say you have 3 tanks which have an analog level sensor, a pump, an inlet valve and an outlet valve. Create an AOI with item Tank of type "Tank", item Pump of type "Motor" and tag OutletValve of type "Valve". And also an input parameter LevelSensor of type DINT or float, however the data is coming in. Say you call this AOI TankStyle1. Then you would go and define 3 tags of type "TankStyle1", called "System1", "System2" and "System3". Or whatever. So now you have a modular AOI structure. You can load the volume of the tank into "System1.Tank.Volume" and inside your AOI write some logic that uses this volume and the value from System1.LevelSensor to calulate the actual level of the tank in Litres or Gallons or whatever, and write it to an output tag "System1.Level". You can do things like comparing against setpoints to determine whether you should set System1.Tank.HighStatus or .LowStatus. You can use some external logic to do things like "If System1.Level is greater than Threshold X, OTE System1.OutletValve.CommandOpen and System1.Pump.CommandRun". And then the AOI's within your AOI's take your run/open commands and assuming all conditions permit, activate System1.Pump.Run and System1.OutletValve.Open, which would be connected to your outputs. And so on.

Then maybe your next 4 tanks have only an outlet valve and high/low level sensors. Create a different specialised AOI with tag Tank of type "Tank", OutletValve of type "Valve", HighLevel of type BOOL, LowLevel of type BOOL, etc. Call this one "TankStyle2" and define 4 tags of type "System4", "System5"...etc. DO the same sort of thing - use external logic to say thing like If the operator presses this button and System4.LowLevel is off, OTE System4.OutletValve.CommandOpen.

Nesting AOI's takes a bit of thinking about, but that's what it's there for. The only thing to be aware of is that you can't use UDT's as input or output parameters; only InOut parameters. To give you the oversimplified rundown, this means that you have an AOI which has an InOut parameter of type "Valve", you will have to create a tag external to the AOI called, e.g. "Valve1" of type Valve, and then just point the AOI to that tag. So the AOI just operates on that external tag instead of having it's own internal one. Like I say, that's a very oversimplified version of it, so you may want to read up on InOut parameters if you decide to go this way at all :)

Hope there's something of use to you in all that rambling. I'm sure others will have different takes on it :)
 
Last edited:

Similar Topics

Hello all, I have a question in regards to RSlogix 5000. I am having issues with the program force closing when I try to make online edits. We...
Replies
0
Views
95
Greetings ... someone sent me a request for some student handsouts that I developed ... turns out that I had this hosted on my business website...
Replies
0
Views
111
Thank you for any and all responses/help. I have an RSLogix 5000 v20 and a Cognex In-Sight v5.9 spreadsheet (8502P). I can not figure out how to...
Replies
0
Views
103
Hi All, I've been pulling my hair out trying to fix this for a few days and need some advice. I have V19.01, v20.05, V21, V24, V30, V31, V32...
Replies
5
Views
356
Hello Friends I have a installation with v16, v17, v18, v19, v20. When I tried to open a v20 file, the enable source protection was not enabled...
Replies
1
Views
215
Back
Top Bottom