User Defined Data Types (UDTs) and OOP

by John Schop

For years now, Object Oriented Programming paradigm (or OOP) has been a commonly used programming practice, and has of course found its way into industrial automation as well.

In the mean time, most PLC manufacturers have found ways to make the programmers life easier by introducing User Defined Types or UDTs. The name says it all; it is a ‘type’ that you, the programmer, can define all by yourself. This means that your programming environment will not only have the regular integers (INT) and Booleans (BOOL), but could also have a ‘VALVE’ type or a ‘MOTOR’ type.

I can’t speak for other brands of PLC’s, but the Allen Bradley ControlLogix series of PLC’s, together with RSLogix 5000 programming software, makes it very easy to work with these UDTs, and since the introduction of RSLogix version 17 earlier this year, it is now even possible to edit your UDTs while online with a running system.

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

I am of the opinion that every PLC program should rely heavily on UDTs to improve readability, and if you are an OOP adept, it can be a great help to organize 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 properties and methods in one simple type. But, as always, we can expect further complications of the class ‘VALVE’ during the realization of a project. To be as flexible as possible, I highly recommend the practice of nesting UDT’s, which will become clear along the way.

Let’s start with defining our class, and keep in mind that it will have to be easily accessible for maintenance people or other programmers.

If we start at the I/O end, the best method is to create sub-classes called VALVE_IN and VALVE_OUT, which will contain our I/O.

The following example uses RSLogix5000 V16. First, create the sub-classes. From the File menu select New Component > Tag. The following dialog box appears to create and edit the members of the UDT.

Now, make a UDT called VALVE, and ‘nest’ these sub-UDTs in it:

As you see, I am allowed to take the types I just created as the data type in this UDT. The real advantage of this feature will become clear if you create a object called Valve001 of the type VALVE, and look at the object 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.