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.
Atomic Data Types
BOOL
| Bits of Data | 1 |
| Bits Reserved for Stand-Alone Tag | 32 |
| Possible Range of Values | 0 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 many 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.
SINT
| Bits of Data | 8 |
| Bits Reserved for Stand-Alone Tag | 32 |
| 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.
INT
| Bits of Data | 16 |
| Bits Reserved for Stand-Alone Tag | 32 |
| 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.
DINT
| Bits of Data | 32 |
| Bits Reserved for Stand-Alone Tag | 32 |
| 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.
REAL
| Bits of Data | 32 |
| Bits Reserved for Stand-Alone Tag | 32 |
| Possible Range of Values | -3.4028234738 to 3.4028234738 (see below) |
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 Data | 64 |
| Bits Reserved for Stand-Alone Tag | 64 |
| Possible Range of Values | Date and 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:
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.
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:
Here’s the same logic if I need to consolidate my stand-alone BOOL tags into bits off of a 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)
Within 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):
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):
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
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
As I continue to flesh out my RSLogix 5000 training material, I want to keep you informed! Sign up for my newsletter to stay up to date whenever I 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:
- Logix5000 Controllers Design Considerations
- Logix 5000 Controllers Data Access
- Logix 5000 Controllers I/O and Tag Data
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:
- Floating point numbers are surprisingly strange from Alteryx Knowledge Base
- Why 0.1 Does Not Exist In Floating-Point from Exploring Binary
- What Every Computer Scientist Should Know About Floating-Point Arithmetic from Oracle
Thank you for reading!
I hope this article was helpful for you. If you feel there’s anything I’ve missed, or you want to reach out for any reason at all, please feel free to leave a comment below or to contact me. Lastly, if you can think of someone else that would benefit from this information, use the share buttons below!