If you’re starting to dive into the world of User-Defined Data Types (UDT’s), 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, and in most situations, they’re easy to use as well. Let’s take a closer look.
What is a User-Defined Data Type?
User-Defined Data Types are data structures defined by the user. For those who are familiar with computer programming, establishing a UDT is a bit like building the fields of a class – 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.
As an example that I hope will be intuitive, let’s imagine that the ceiling fan in your living room is a device on your industrial network, and that you want to establish a User-Defined Data Type on your processor 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 Input||Data Type||Min Value||Max Value|
|Fan On Command||BOOL||0||1|
|Light On Command||BOOL||0||1|
|Set Fan Speed||DINT||0||3|
Additionally, the fan has the following outputs:
|Fan Output||Data Type||Min Value||Max Value|
|Fan On Status||BOOL||0||1|
|Light On Status||BOOL||0||1|
|Fan Speed Setting||DINT||0||3|
While this is a fictional example, it may not be far from what you would see set up for 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 be used by the PLC to know if there is a problem with the fan. In your logic, it may be useful to only attempt to run the fan if its Communications Ok and Motor Ready bits are high, indicating that the device is communicating with the controller and is ready to operate. Status bits like these are common and are typically programmed at the device or firmware level by the manufacturer of each specific device; 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 a User-Defined Data Type
Making a new UDT in RSLogix is easy. There are a few limitations that you’ll run in to here and there, but for the most part, 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.”
- If it’s collapsed, expand Data Types by clicking the +. Right-click on User-Defined.
- Click New Data Type…
Setting Up Your New UDT
And you’re off! The first thing to do is name your UDT. 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; 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
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!
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:
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.
- If necessary, click the + next to the Application category to show the Display category.
- Click the Display 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 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 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.
- Once you’ve entered the name and UDT, click anywhere else in the Edit Tags window to add the new tag. You’ll see the UDT description pop up in the Description column.
- 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.
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 Type’s
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 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.
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!