Atomic Data Types in RSLogix 5000 – RSLogix 5000 Training

In this article, we’ll discuss atomic data types in Rockwell Automation’s RSLogix 5000. Atomic data types are the predefined data types that form the backbone of RSLogix 5000’s memory structures. These data types are inherent to RSLogix 5000 and will be utilized by many of its native instructions.

RSLogix 5000 supports the following IEC 61131-3 atomic data types:

Below, I’ll go over each of these data types. Further down the page, we’ll go past the basics by looking at memory utilization and programming practices. Let’s start by looking at RSLogix 5000’s simplest atomic data type, a BOOL.

Want to take the next step in your industrial automation career?

We want to help.

Are you looking for opportunities to advance your career and make more money?

At no cost to you, the Industrial Automation Connection can get you in touch with training and job opportunities in your area. Click one of the buttons below to get started!

Atomic Data Types


Bits of Data1
Bits Reserved for Stand-Alone Tag32
Possible Range of Values0 to 1

A Boolean tag can hold one of two possible values: a 1 or a 0. Booleans are useful for storing states that are either true or false, light or dark, on or off, etc. Booleans are perhaps the most-used data type, representing not only real world inputs and outputs (proximity sensor made or not made, valve output on or not on, etc.), but also various status conditions in the PLC (process 1 complete, next unit data available, etc.).

What does “stand-alone tag” mean?

By “stand-alone tag”, I mean a tag that is not part of a UDT or other structure.

For example: I go to Controller Tags and click the Edit Tags tab. Then, on the very bottom row, I type New_Boolean for Name and BOOL for Data Type. The New_Boolean tag would be an example of a “stand-alone tag” of type BOOL.

Programmable Logic Controllers that are compatible with RSLogix 5000 use 32-bit memory allocation. As a result, even though it only requires one bit to represent a Boolean value, a stand-alone tag that is defined as data type BOOL will still take up 32 bits in memory.

I’m not saying that you should never use BOOL’s, and in fact, you’ll surely use many, many BOOL’s. But there are ways to economize your memory usage if you’re going to use a lot of Boolean tags in the same chunk of logic. You should consider doing so, especially if you’re writing logic that will be reused over multiple devices or applications. We’ll cover memory economization further down the page.


Bits of Data8
Bits Reserved for Stand-Alone Tag32
Possible Range of Values-128 to 127

A tag of data type Single Integer, or SINT, stores 8 bits of information. Because SINT’s hold signed values, a SINT tag can hold values from -128 to +127. A SINT may be useful for storing integers with small possible values, such as robot program calls, small counter values, etc.

The 32-bit rule applies for stand-alone SINT tags as well. Even though SINT’s hold only 8 bits of information, 32 bits of memory are nonetheless allocated for a stand-alone SINT tag.


Bits of Data16
Bits Reserved for Stand-Alone Tag32
Possible Range of Values-32,768 to 32,767

A tag of data type Integer, or INT, stores 16 bits of information. INT’s also hold signed values, and so a tag of type INT can hold values from -32,768 to +32,767. An INT may be useful for storing larger but still not gigantic integer values, such as encoder counts, total events since some infrequent reset, minute of the day, etc.

I bet you’ve picked up the pattern by now. Despite the fact that you only need 16 bits to store an INT value, 32 bits will still be allocated to a stand-alone tag of type INT.


Bits of Data32
Bits Reserved for Stand-Alone Tag32
Possible Range of Values-2,147,483,648 to 2,147,483,647

A Double Integer, or DINT, stores 32 bits (one “word”) of information. Like SINT’s and INT’s, DINT’s hold signed values. A tag of type DINT can hold values ranging from -2,147,483,648 to 2,147,483,647. DINT’s are a bit paradoxical, as it’s uncommon (in my experience) to need to store an integer with a value in the multi-millions. Nonetheless, because the size of a DINT matches the size of the memory allocated for a stand-alone tag, DINT’s are very, very commonly used when programming in RSLogix 5000.


Bits of Data32
Bits Reserved for Stand-Alone Tag32
Possible Range of Values-3.4028234738 to 3.4028234738

Unlike the other data types we’ve looked at, which only store integer values, tags of data type REAL store signed, 32-bit floating-point decimal values. A tag of type REAL can hold values ranging from -3.4028234738 to -1.17549435-38, 0, and from 1.17549435-38 to 3.4028234738.

As you can see, REAL’s can represent some very large and some very small numbers, but they do so at reduced precision when compared to a DINT. In addition to the smaller number of significant digits, there is another factor to consider when using REAL’s.

Some decimal values must be approximated

BOOL’s, SINT’s, INT’s, and DINT’s all represent integer values. In binary, integer values can be represented precisely. In other words, when you store 255 in a DINT tag, the PLC stores a value at that address that represents 255 exactly. REAL’s, on the other hand, represent floating-point decimals. Just as 1/3 cannot be represented precisely in decimal (1/3 becomes 0.33333…), many decimal values cannot be represented precisely with floating-point data types. Because math.

Even the value 0.1, which seems like such an innocent number, can be very troublesome when you attempt to represent it in binary. The necessity of approximating decimal values can sometimes lead to unexpected or unwanted behavior.

Will this prevent you from using REAL’s? No; from time to time, it will be necessary to use REAL’s in your logic. There are some considerations to make when doing so, however, and sometimes it may be better to avoid them if possible. To learn more about floating-point decimal data types, head to the additional information section at the bottom of the page.

Special-Use Atomic Data Type: LINT

Bits of Data64
Bits Reserved for Stand-Alone Tag64
Possible Range of ValuesDate & Time information
(see below)

Long Integers, or LINT’s, store 64 bits (two words) of information. LINT’s are not always listed when discussing atomic data types, but Rockwell Automation considers them to be “Special-Use” atomic data types. Rockwell typically discusses them in the same literature as the others.

LINT tags are used for Date and Time information and, per the Rockwell literature, represent the following:

Valid Date/Time range is from 1/1/1970 12:00:00 AM coordinated universal time (UTC) to 1/1/3000 12:00:00 AM UTC.

From Logix5000 Controllers Design Considerations

Native RSLogix 5000 instructions provide limited support for LINT’s. Although they are an option, there are other ways to represent date and time information that don’t get into some of the messiness that can result from using LINT’s.

Summary of RSLogix 5000’s Atomic Data Types

Here’s a nifty summary from Rockwell Automation’s Logix5000 Controllers Design Considerations document:

The Data Type summary chart for RSLogix 5000 from Rockwell Automation's "Logix5000 Controllers Design Considerations" document. This chart summarizes the atomic data types (BOOL, SINT, INT, DINT, REAL, and LINT) and their memory allocation and supported range of values.

Deciding Which RSLogix 5000 Atomic Data Types To Use

Choosing Atomic Data Types For Stand-Alone Tags

Let me cut to the chase: when creating stand-alone tags, use DINT’s and BOOL’s. To perform operations on smaller integer data types, the PLC has to first convert them into DINT’s, do the operation, then convert them back to their original data type. DINT’s don’t just use less memory per useful bit; they’re actually faster, as you can see in the Rockwell guidelines below. So don’t be silly. Use DINT’s.

Rockwell Automation's Guidelines for Data Types. This chart shows DINT as the preferred atomic data type in RSLogix 5000 for integer values. It also shows the memory reserved and instruction execution times for the various data types.

Like SINT’s and INT’s, BOOL’s are also memory-wasters, in that you’re only getting 1-bit’s usage out of 32 bits in memory. Nonetheless, for stand-alone tags, I say that you should still feel OK to use BOOL’s as they can potentially make your logic more readable. With that said, if memory is at all a concern, you should instead use DINT’s or arrays of DINT’s and allocate individual bits to your Boolean operations. If you do this, you’ll want to make sure you use good descriptions for the various bits you assign.

An example of BOOL vs DINT

To illustrate what I’m saying above, let me show you the same logic using BOOL tags and using bits from a DINT. Here’s with BOOL’s:

A ladder logic rung with an XIC on a BOOL tag and an OTE.
Both instructions reference tags of type BOOL

Here’s the same logic if I need to consolidate my stand-alone BOOL tags into bits off of a DINT:

A ladder logic rung with an XIC on a bit from a tag of type DINT and an OTE refering a different bit from the same DINT.
Both instructions reference specific bits from the same tag of type DINT

The difference is that instead of creating two tags of type BOOL, I created a single tag of type DINT. I can then reference any of the 32 bits available in that DINT by using [tag name].0 through [tag name].31. My two BOOL’s would occupy 64 bits in memory, whereas the DINT requires only 32 bits. Furthermore, I have 30 more bits available off of the DINT. If I instead defined 30 additional BOOL’s, I would occupy 30 x 32 additional bits in memory.

Decriptions are key if using DINT’s

If you do use bits off of a DINT as Booleans, it is very important that you provide good descriptions for each bit. In the example, I provide the “Process Output Conditions Met” and “Turn On The Process Output” descriptions for the specific bits: Process_Output_Bits.0 and Process_Output_Bits.1. If I didn’t take the time to provide descriptions, I would have no idea what those bits represent.

On the other hand, with the BOOL tags we defined in the first example (Process_Output_Trigger and Process_Output), the tag names themselves served as pretty specific documentation for what the bits represent.

In summary, the decision between using BOOL tags and referencing specific bits off of a DINT tag is a decision between readability for humans and reducing wasteful allocation of memory. For many projects, throwing in a few Boolean tags probably won’t be the end of the world.

Now, with all of that said, there will surely be exceptions. For example, Rockwell’s documentation states that you may need to use SINT or INT tags ” when communicating with an external device that does not support DINT values”. In such cases, you may have to go with what works and not worry about the overhead. There is, however, a case where you can use BOOL, SINT, and INT tags without wasting memory. We’ll cover that case below.

Choosing Atomic Data Types In RSLogix 5000 For User-Defined Data Types (UDT’s)

With User-Defined Data Types, you have the ability to consolidate bits (and save memory) without sacrificing descriptive tag names. In other words, if you do it right, you can define BOOL, SINT, or INT tags within a UDT without wasting (as much) memory as you would with stand-alone tags. Let’s take a look.

Within a UDT, consecutive elements of the same data type will be packaged within the same 32-bit address in memory. If you have a UDT with 32 BOOL tags, the size of the UDT will be 4 bytes (32 bits):

A User-Defined Data Type with 32 BOOL in RSLogix 5000.
A graphic depiction of 32 BOOL tags being consolidated into a 32-bit block of memory when using a UDT in RSLogix 5000.

Similarly, if you have a UDT with 1 DINT followed by 4 SINT’s and then 32 BOOL’s, the UDT’s size is 12 bytes (96 bits):

A User-Defined Data Type with 1 DINT, 4 SINT's, and 32 BOOL's in RSLogix 5000.
A graphic depiction of 1 DINT, 4 SINT's, and 32 BOOL tags being consolidated into a 96-bit block of memory when using a UDT in RSLogix 5000.

UDT’s are most memory efficient when like-type elements are located together

UDT’s will not, however, consolidate memory usage for non-consecutive elements. If you have a UDT with 1 BOOL, 1 DINT, and then 31 additional BOOL’s, the size of the UDT would be 12 bytes (96 bits). In other words, in the 1 DINT / 4 SINT / 32 BOOL example above, you get a full additional word of memory (the 4 SINT’s) for free just by making sure your elements of the same data type are grouped together. Here is how the memory shakes out in the non-consecutive example:

  • A 32-bit block of memory is allocated to the 1st BOOL
  • The DINT must start a new 32-bit block of memory
  • The 2nd BOOL starts a new 32-bit block of memory
    • The remaining 30 consecutive BOOL’s are allocated to this same block
A User-Defined Data Type with 1 BOOL, 1 DINT, and 31 more BOOL's in RSLogix 5000. The purpose of this example is to illustrate that when elements of the same atomic data types are not grouped together in a UDT, memory is wasted.
A graphic depiction of 1 BOOL, 1 DINT, and then 31 more BOOL tags being allocated 96 bits of memory when using a UDT in RSLogix 5000. The purpose of this example is to demonstrate that RSLogix will consolidate memory for elements with atomic data types in UDT's, so long as those elements are organized in the UDT consecutively.

As you can see, taking care in the design of your UDT’s can allow you to reduce your memory consumption. On top of that, you can still provide nice, descriptive tag names to make your logic readable. In this sense, UDT’s can offer the best of both worlds.

To continue learning about PLC programming with Rockwell Automation’s RSLogix 5000, read more about User-Defined Data Types.

Additional Information On Atomic Data Types In RSLogix 5000

Want to see more info like this? Sign up for the Industrial Automation Connection newsletter to stay up to date whenever we post something new:

Do you have any questions about atomic data types, RSLogix 5000, or PLC programming in general that weren’t covered in this article? If so, head down to the bottom of the page and leave a comment with the information you’re after.

Rockwell Automation Literature On RSLogix 5000 Data Types

Let’s get technical! Here are some great publications on this topic, straight from the horse’s mouth:

Floating-Point Decimal Data Types

If you’d like to dive into floating-point decimal representations, here are two brief articles and one incredibly in-depth publication. You can go as deep as you like into the difficulties of storing decimal values in binary:

Thank you for reading!

I hope this article was helpful for you. If you feel there’s anything we’ve missed, or you want to reach out for any reason at all, please feel free to leave a comment below or to contact IAC. Lastly, if you can think of someone else that would benefit from this information, use the share buttons below!

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.

Are you ready to take the next step in your industrial automation career?

The Industrial Automation Connection’s goal is to help you connect with opportunities to advance yourself.

Let us put you in touch with organizations that are looking for people like you.

This service is always free, and it takes only a few moments to register. Click one of the buttons below to get started!


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

True To Life?

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 to 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, and may be the best method, depending on how many references you would need to change.

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 us 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 our newsletter. We’ll keep you posted whenever new industrial automation content is available. Thanks again for reading!