PLC & Control

For years now, Object Oriented Programming archetype (or OOP) has been a frequently acclimated programming practice, and has of advance begin its way into automated automation as well.

In the beggarly time, best PLC manufacturers accept begin agency to accomplish the programmers activity easier by introducing User Defined Types or UDTs. The name says it all; it is a ‘type’ that you, the programmer, can ascertain all by yourself. This agency that your programming ambiance will not alone accept the approved integers (INT) and Booleans (BOOL), but could additionally accept a ‘VALVE’ blazon or a ‘MOTOR’ type.

I can’t allege for added brands of PLC’s, but the Allen Bradley ControlLogix alternation of PLC’s, calm with RSLogix 5000 programming software, makes it actual accessible to assignment with these UDTs, and back the addition of RSLogix adaptation 17 beforehand this year, it is now alike accessible to adapt your UDTs while online with a active system.

The Controller Organizer has a binder alleged Data Types > User-Defined with all the UDTs in the project.

I am of the assessment that every PLC affairs should await heavily on UDTs to advance readability, and if you are an OOP adept, it can be a abundant advice to adapt your classes.

Let’s go over the fundamentals of OOP for a little bit:

• Classes: Classes define the abstract characteristics and behavior of an object. For example, a simple ‘VALVE’ class would have the characteristics (or attributes) that it can be open or closed (the things it can be), and as far as behavior goes, it could have the methods ‘to open’ and ‘to close’ (the things it can do)
• Objects: An object is an instance (occurrence) of a class. In our example, there could be a Valve_001 and a Valve_002, which are both instances of the class ‘VALVE’, with the same attributes and methods.

Of course the definition of OOP goes a lot further than this. There is a very understandable explanation here: http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_concepts for those who would like to read more. For now, let’s leave it at this, and see how we can apply this to an industrial environment.

If you look at a valve as an object in a typical industrial automation environment, you should note the following:

• It has inputs and outputs that are specific for the object (proximity switches and solenoids).
• It can be either ‘open’ or ‘closed’
• You can tell it to go ‘open’ or ‘close’.
• It could have an alarm timer, that would tell us if the valve did not open or close in a given time period after a command.
• It might have interlocks, which allow the valve to open or close under certain conditions.

A UDT for this class, would fit all these backdrop and methods in one simple type. But, as always, we can apprehend added complications of the chic ‘VALVE’ during the ability of a project. To be as adjustable as possible, I awful acclaim the convenance of nesting UDT’s, which will become bright forth the way.

Let’s alpha with defining our class, and accumulate in apperception that it will accept to be calmly attainable for aliment bodies or added programmers.

If we alpha at the I/O end, the best adjustment is to actualize sub-classes alleged VALVE_IN and VALVE_OUT, which will accommodate our I/O.

The afterward archetype uses RSLogix5000 V16. First, actualize the sub-classes. From the File card baddest New Component > Tag. The afterward chat box appears to actualize and adapt the associates of the UDT.

As you see, I am accustomed to booty the types I aloof created as the abstracts blazon in this UDT. The absolute advantage of this affection will become bright if you actualize a article alleged Valve001 of the blazon VALVE, and attending at the article in the ‘monitor tags’ window:

Wow! Just by creating a new tag of the type VALVE, it gets all these I/O points right away, and referenced in the program:

Of course, going further with this concept, everything for a valve can be included in one object. Allow me to skip some steps, and show you a possible final result:

The ‘VALVE’ class is now contained in a UDT called VALVE, which looks like this:

As you see, the class VALVE now consists of the sub-classes VALVE_IN, VALVE_OUT, VALVE_TIMER, VALVE_STATUS, etc.

And an instance of this class, the object Valve001, would look like this:

While adding stuff to my class, I did not have to re-create the object Valve001. RSLogix updated it for me, so all the properties and methods are available in my program.

Now, let’s say you’re working on this project with a couple hundred valves, and the customer decides to go with a different type of valve, that also has an analog input, that tells us the exact position of the valve. All we have to do is modify our VALVE_IN sub-class to add this to every instance of the type VALVE:

Of course, you would still have to write code to tell your program what to do with that information, but that is also the reason why PLC programmers still have a job.

For somebody that is not familiar with your program, it might be confusing to look at all your UDT’s. We just made eight UDT’s for one simple valve class! But remember, you only have to do this during the design phase. Once you have a solid design for all your classes (and made sure their names are self-explanatory), you will never have to look at your UDT folder again, and creating a new instance will be a breeze.

Please visit us at  http://plc2u.com/index.php/plc-article/plc/user-defined-data-types-udts-and-oop

Related Post: