User-Defined Data Types in RSLogix 5000

If you’re starting to dive into the world of User-Defined Data Types (UDT’s) within RSLogix 5000, have no fear. UDT’s are an extremely useful way to package your data and keep your tag list manageable.  Here are some of the things that UDT’s can do for you:

  • Consolidate many related data points into one tag
  • Allow you to share related data over the network with a single explicit Message instruction or Produced/Consumed relationship
  • Simplify and standardize your logic if you are adding more than one of the same device
  • Keep your tag list neat and organized
  • Slightly improve memory storage efficiency

There are a lot of big pluses to using User-Defined Data Types in RSLogix 5000. For the most part, UDT’s are easy to use, as well.  Let’s take a closer look.

Contents of this post:

What is a User-Defined Data Type?

In RSLogix 5000, User-Defined Data Types are data structures that are defined by the programmer.  For anyone familiar with computer programming, establishing a UDT is a bit like building the fields of a class. When you create a UDT, you are establishing the data points that relate to some object or operation. UDT’s can integrate atomic data types, native structures such as CONTROL and TIMER tags, and even other UDT’s.

Let’s imagine that the ceiling fan in your living room is a device on your industrial network. You want to establish a User-Defined Data Type on your PLC to help organize the logic and data that you’ll use to control the fan.

This ceiling fan has a light kit attached; the fan has a 3-speed motor, and the lights can be dimmed.  The fan has the following inputs, which accept the following data types and values:

Fan InputData TypeMin ValueMax Value
Fan On CommandBOOL01
Light On CommandBOOL01
Set Fan SpeedDINT03
Set BrightnessDINT0255

Additionally, the fan has the following outputs:

Fan OutputData TypeMin ValueMax Value
Motor ReadyBOOL01
Fan On StatusBOOL01
Light On StatusBOOL01
Fan Speed SettingDINT03
Brightness SettingDINT0255

While this is a fictional example, it’s somewhat true to what you might see with a typical field device. The outputs let you know the settings at which the device is operating, as controlled by the inputs.

Additionally, the fan outputs a couple of status bits, which can tell the PLC if there is a problem.  In your logic, it may be useful to check for Communications Ok and Motor Ready bits. Before attempting to operate the fan, you would check that these bits are high. Bits like these indicate that the device is communicating with the processor and is ready to operate. Status bits of this type are common and are typically programmed at the firmware level by the device’s manufacturer. As a result, you’re often at the mercy of the device manufacturer in regards to how much help a particular status will be in regards to finding the root cause of a problem.

Creating User-Defined Data Types In RSLogix 5000

Making new User-Defined Data Types (UDT) in RSLogix 5000 is easy.  While there are a few limitations you’ll run in to here and there, I think that once you start working with them, you’ll find it simple to use this powerful feature.

To create a new UDT in RSLogix 5000:

  • Open the Controller Organizer Window, or “COW.”
The Controller Organizer Window in RSLogix 5000.
The Controller Organizer Window (COW).
  • If it’s collapsed, expand Data Types by clicking the +.  Right-click on User-Defined.
The context menu that pops up when you right-click on User-Defined within Data Types in RSLogix 5000.
The User-Defined context menu.
  • Click New Data Type…

Setting Up Your New UDT

And you’re off!  The first thing to do is name your UDT.  When you do so, make sure to follow any standards that your organization has set in regards to naming conventions, or consider creating your own conventions if you’re working independently.  Here is the general format that my organization uses:


For this application, let’s establish one UDT for the outputs and one UDT for the inputs.  A quick note here:  Earlier, I described the “fan inputs” and “fan outputs.”  Now, we’re looking at things from the opposite perspective. In other words, the fan’s inputs will be connected to PLC outputs, and the fan’s outputs will be connected to PLC inputs.  So, as you’ll see below, the “FanIn” UDT we’ll create will correlate with the “Fan Outputs” table you see above.

Given my organization’s naming standards, I’m inclined to use something to the tune of:

Udt_Environment_FanIn_20170817 and Udt_Environment_FanOut_20170817

The UDT name Udt_Environment_FanIn_20170817 shown in the Name line on the New Type... window in RSLogix 5000. This image is being used to describe the process of creating User-Defined Data Types in RSLogix 5000.

Of course, this is just one idea for how to format the name for your UDT. What format does your organization use?  Let me know in the comments section below!

Adding Elements To a UDT

Now that you’ve given a name to the UDT, it’s time to add some elements.  For now, let’s look at the FanIn UDT and add elements to correspond with our Fan Outputs above:

The FanIn UDT shown with its elements filled in.
The FanIn UDT – note that PLC inputs correspond with the device outputs.

A brief interjection:  Although I did it for purposes of consistency, note that all of my elements of type BOOL are listed sequentially, followed by elements of type DINT.  Because the Boolean elements in this UDT are grouped together, it will actually require less processor memory to store these elements than it would if each were defined outside of a UDT as separate tags.

This is because the smallest memory allocation for a tag is 32 bits, even if the data type does not require the full allocation.  UDT elements that are less than 32 bits can be consolidated into the same address in memory, depending on how they are ordered in the UDT’s definition.

Using Pass-Through Tag Descriptions

One nice UDT feature that you can enable or disable is the ability to pass through the overall UDT description to each element.  Note our UDT description above, “From Fan Controller.”  If you choose to leave descriptions off of your UDT elements, you can set RSLogix to use the description from the UDT itself.  Alternatively, you can set your tags to append the UDT description as a precursor to each element’s description; “Comm OK” becomes “From Fan Controller Comm OK.”  This can be a useful feature to provide common text for your tag descriptions.  Here’s how to set up Pass-Through Descriptions:

  • Select Options… from the Tools menu.
Options... on the Tools menu within RSLogix 5000.
  • If necessary, click the next to the Application category to show the Display category.
  • Click the Display category.
In RSLogix 5000, in the Options... menu, the Display category is shown as a subcategory to the Application category.
  • Here, you’ll find the options to Show Pass-Through Descriptions and Append to Base Tag Descriptions.
  • Check or uncheck these settings as desired.

If you want to know more about Pass-Through Descriptions, check out this literature from Rockwell Automation.

To see what the Append to Base Tag Descriptions option looks like, let’s make a tag with our new UDT.

Creating Tags In RSLogix 5000 Using Your New User-Defined Data Type

Creating a tag using your new UDT is as easy as creating a tag using atomic data types.  We’ll follow the typical procedure using the Edit Tags window, and then take a look at the descriptions for your new tag’s elements.

  • Head to your Controller Tags (or Program Tags) from the COW.
In RSLogix 5000, Controller Tags shown within the Controller Organizer Window.
  • In the bottom-most row, type in the name for your new tag, and then type in the name of the UDT that you created under the Data Type column.  RSLogix will auto-fill the data type as you type in your UDT.
Creating a new tag in RSLogix 5000 by typing in the tag name and data type.
  • Once you’ve entered the name and UDT, click anywhere else in the Edit Tags window to add the new tag.  After doing so, you’ll see the UDT description pop up in the Description column.
Te new tag created in RSLogix using the new UDT. The UDT description comes through as the tag description.
  • Click the button next to the new tag to view its elements.  Note that the UDT description (“From Fan Controller”) is appended to the front of each element’s description.
    In RSLogix, the UDT description distributed through each of the element's descriptions in the new User-Defined Data Type.

This can be an easy way to implement common wording in the tag elements that are built from your User-Defined Data Types, while still providing specific notes for each element that identify its purpose.

One Downside to Implementing User-Defined Data Types

While there’s a lot of power in using UDT’s, there’s one hiccup you can run in to when developing and maintaining your logic.

The only problem I’ve run in to when using UDT’s is when it’s necessary to modify a User-Defined Data Type by changing or adding elements.

The problem is that when you modify a UDT, you have to go offline, make your changes, and then download to the processor.

Depending on the production demands in your facility, downloading to the processor may not be an easy option for you.  In the factory where I work, for instance, I only have a window of around an hour each day in which I could do a download, and I would have to answer for any issues that delayed the next shift’s startup.

Another Method For Modifying a UDT

Another option, then, is to modify the UDT offline and then import it as a new UDT – our practice is to update the UDT name with the current date… Udt_Environment_FanIn_20170817 becomes Udt_Environment_FanIn_XXXXXXXX.  This approach, however, has its own concerns:

Any tags that you’ve added to your logic with the old data type will have to be updated to the new data type.  You could change the tag’s data type in the Edit Tags window, but again – you would then need to download.  You can simply create a new tag with the new data type, but then you would need to rename every reference to every element of the old tag to refer instead to the new tag.  This could be a small or massive undertaking, depending on how many elements are used and how many tags have been created with that data type.

A third option is to update your tags offline and then import duplicate routines or programs and switch your JSR’s to reference the new routines.  This has worked for me in the past; perhaps I’ll make it the subject of a future blog post.

In Summary

User-Defined Data Types are an awesome feature that can help you to organize and simplify your tags and even improve your memory usage in some cases.  UDT’s can also come in handy big time when sharing data with other processors on the network.

How are you using UDT’s?  Is there specific information you’re looking for?  Let me know in the comments below, and thanks for reading! If you’d like to continue reading in this field of knowledge, check out Atomic Data Types in RSLogix 5000.

If this post was helpful for you, go ahead and take just a few seconds below to sign up for my newsletter, so I can keep you informed whenever I make new content available. Thanks again for reading!

4 thoughts on “User-Defined Data Types in RSLogix 5000”

  1. Very nicely done, Skylar.
    Would you elaborate on “UDT’s can also come in handy big time when sharing data with other processors on the network.”

  2. OK, you make 5 inputs to a new UDT . Now you want to use them in your ladder code. Say for instance you have “Run Motor”, BOOL. Since this not an alias tag, How does this contact bit change states in your ladder code?

    1. Hi John,

      Just as you would make a new tag of type TIMER if you were making a new TON instruction, you would make a new tag of type [your UDT] and then utilize that tag in various instructions throughout your logic.

      So, if you have a UDT, Xudt_RunMotor with:

      SafetiesOk (BOOL)
      StartSwitchInput (BOOL)
      RunMotorOutput (BOOL)

      you would make a new tag, let’s say “Fan1LH” of type Xudt_RunMotor, and you would set up XIC’s, OTE’s, OTL’s, etc. for your various bits. So you might have:

      XIC Fan1LH.StartSwitchInput OTL Fan1LH.RunMotorOutput

      Does that make sense? Let me know if you have further questions on this topic.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.