Back to tutorials
PLC Instructions

User Defined Data Type [UDT] Tutorial - Explanation, Usage, Examples & Custom Definition in RSLogix 5000

By
Vladimir Romanov
Table of Contents

Introduction

User Defined Data Types or UDTs are commonly used in Programmable Logic Controller Programming in order to group data and maximize code reusability. This structure allows the user to combine any of the existing data types into a package which can be reapplied multiple types across the program, be exported and imported into other structures.

In this post, we will be looking at why we’d want to use UDTs, how to set them up in RSLogix 5000 and a practical example of their usage.

When to use a User Defined Data Type (UDT)

User Defined Datatypes consume space on a controller. Therefore, you need to think strategically before combining your data in this manner. From a practical sense, this means that you don’t want to include too much data which will not be used in your program. It is also important to make sure that the application for which you’re using this data will actually need all those placeholders.

To illustrate the above principle with an example, let’s consider a simple pump system. This system consists of inputs, outputs & operational tags. Critical inputs could be “start”, “stop”, “fault reset”. Outputs we’d like to know about the system are “Status”, “Faulted”, “Running”, “Speed”, etc. Internal operation tags could be anything which will be used in programming the structure of the system. Using the bits we’ve covered above along with a few extra ones for programming the internal operation makes a lot of sense. We can define a UDT which will contain BOOLs, INTs, REALs as well as several arrays of undefined tags to accommodate the operational data.

An improper way to use a UDT would be to utilize it for a system which is extremely large such as an entire plant. Although you may get away with defining it as such, you will never be able to reapply such a UDT as opposed to our pump system above. It can be exported and imported into the next program which will use the UDT. It’s also not advised to apply a UDT for an entire machine even if it will be built multiple times. In fact, try to restrict UDT usage to small systems which exist in any field: motors, pumps, conveyors, tanks, boilers, etc.

Creating a UDT in RSLogix & Studio 5000

UDTs are defined within the “Data Types” folder of the Controller Organizer. This section is also used to identify the other data types typically used within Allen Bradley logic & controllers. Examples include Strings, Timers, EN2T structures & much more. As the name would suggest, User Defined Datatypes need to be created within the “User-Defined” folder.

To create a new User Defined Datatype, right click the folder and select “New Data Type…” (As shown in the image below).

User Defined Datatype UDT Tutorial - Explanation, Usage Examples & Custom Definition in RSLogix 5000

A new window will open and allow the user to define the specific tags used within the UDT. Here, you can customize your set of data and define the different data types as well as give them a description. The example below displays a simple implementation of a UDT used for a motor based system. It’s constructed from the inputs & outputs we discussed above as well as several utility arrays. Keep in mind that you may use any data types as well as arrays of them within the UDT. In fact, you can even “nest” a UDT within another. As you build one for yourself, you’ll realize how useful they are.

User Defined Datatype UDT Tutorial - Explanation, Usage Examples & Custom Definition in Studio 5000

Utilizing the UDT in RSLogix & Studio 5000

After completing the definition of the UDT and applying the structure, it will be saved within the program. From this point on, you may use it within your code. You may also choose to Export & Import it into another project. A common practice is to create new UDT structures within an offline file and to import them into a running program.

Just like you would define the type of a new tag to be a “BOOL”, you can choose for it to be the type of “UDT_xxx” where UDT_xxx is the name of the UDT you defined above. Do note that it’s my personal preference to add the “UDT_” prefix to each UDT; it’s not mandatory. By creating a tag which is specified as the UDT, the software will place the tag as well as the associated structure into the memory. This will allow you to create & identify tags based on this structure.

Using the same example from above, this translates to us being able to create a “Motor1” structure which will contain all the data types we’ve specified. In ladder logic, a basic example of this equates to a program which is entirely based around this structure. There are several advantages to this practice: we have a single structure for all the tags required to create a motor based system & we can easily reapply this system within the same or a different controller. From a re-usability standpoint, you should strive to contain your code within UDT in order to re-use it for other applications.

User Defined Datatype UDT Tutorial - Explanation, Examples & Custom Definition in RSLogix 5000

Conclusion

User Defined Datatypes are extremely powerful. They allow the user to create re-usable pieces of code which contain a logical implementation of a subsystem. By encapsulating your code within such structures, you’re allowing yourself to easily re-utilize the code & to be able to migrate it between multiple controllers.

The user may specify a combination of different data types to be contained within the custom structure. This includes simple ones such as BOOL, INT, Timer as well as more complex ones such as CONTROL structures and even other UDTs. Once defined, the user is able to create tags based on this structure within the same controller.

It’s possible to miss-use a UDT. You should avoid using them for large systems which aren’t going to be reapplied anywhere else. Furthermore, it’s best to define the systems as self-contained. In other words, you should only define the tags which are needed by the program. Defining tags which aren’t going to be used will waste memory on the controller.

Video Tutorial

Back to tutorials

Related Tutorials

Advanced

PowerFlex 525 Parameter, Input and Output Programming Tutorial in RSLogix Studio 5000

The PowerFlex 525 series of Variable Frequency Drives from Allen Bradley is highly utilized and respected within the automation field. The drives are compact, versatile and easy to use. We’ve written an extensive tutorial on how to get started with these drives in a previous tutorial; it covers how to initialize the drive, connect it to an EtherNet/IP based PLC and how to set the right parameters. In this tutorial, we’re looking to expand on the concepts and demonstrate a way to access and utilize the multiple Input and Output options available on the drive. The reason you may want to utilize the IO is to save money on purchasing external components, integrate instrumentation into your drive and save floor space, wiring and cost. We’ve seen the need to integrate closely related sensors into a PowerFlex 525 application; this would be the right way to do it.

By
Vladimir Romanov
Advanced

Publishing MQTT Data Using Opto 22 groov EPIC PAC

MQTT is a communication protocol that has taken off in the IIoT community. It’s a light-weight, efficient protocol that works through a publisher / broker / subscriber model. It creates an easy way for field devices to communicate and retrieve data from a single location. In this article, we’ll go over MQTT and dive into an example of how you can publish data using a groov EPIC PAC and retrieve the data using a MQTT client.

By
Vladimir Romanov
Intermediate

HMI Design - Best Practices for Effective HMI Screens

HMI Design is the practice of building HMI screens that are intuitive to the end user, pleasing to the eye and are efficient to operate. As control systems within manufacturing are migrated from traditional push button designs to primarily operated from HMI displays, HMI Design has become trivial to any new installation.Although there is a wide range of HMI based systems, the basic principles of good design remain the same. Different industries may dictate different patterns of layout for their systems, but the good practices remain.

By
Vladimir Romanov