Understanding RSLogix5000 I/O Base Tag Addressing Structure

I am a new user on this forum (but fairly experienced in RSlogix navigation and editing) and have tried to search this topic so if it is here please direct me and I'll stop wasting everyones time, heh heh.

My question: I have noticed different structures of base tags in rslogix5000 controller/program tag database for allen bradley flex I/O modules. Can anyone please explain why some naming conventions differ? I can't figure out especially on the digital modules why some use "location:type.data[slot].bit" and others use "location:type:slot.data.bit" in their tag structure. I have some examples posted below with Program tags that Alias Controller Base tags. I notice this when looking in the program tag database window with the "Edit Tags" active (not "Monitor Tags")........

Ex 1. 1794-IE8/B Analog Input module: UF0085 channel 6 (UF0080 is an ACNR, module is in slot 5, channel 6 connected to a 4-20mA pressure transmitter)
Base Tag is UF0080:5:I.ch6Data with Program tag name PDT6050 (aliasing the base tag on the left)

I understand that ch6Data means its analog data and is using all of the binary bits ch6Data.1 & ch6Data.2 etc......so this isn't a problem for me


Ex 2. 1974-OB16P/A Digital Output module: UF0092 channel 3 (channel 3 connected to a binary run command for a motor)
Base Tag is UF0090:O.Data[2].3 with Program tag name M6041 (Alias For the base tag on the left)
I don't know the rules to why this structure is the way it is.


Ex 3. 1794-OB8EP/A Digital Output module: UF0080 channel 4 (channel 4 connected to a binary motor pump command)
Base Tag is UF0080:0:O.Data.4 with Program tag name M6020 (Alias For the base tag on the left
I see this structure in Rockwell's literature pdf: 1756-pm004 Logix5000 Controllers I/O and Tag Data

Yes, it can be confusing, more like different people, while designing the modules, created different structures. But let me through a word out there that once you start using it, it will be indispensable:

ALIAS

No matter what the module structure is, I create tags that are aliases to the module's properties that I'm interested in using. It allows me NOT to be concerned with the module layout, just using these tags gets me to the data that is important for the task at hand.

Thanks jstolaruk. I understand the importance of aliasing and love the usage as well, but it can be a little difficult to alias correctly sometimes if I don't know what structure I am aliasing to (like in example 2 and 3).
This is true for me when creating new logic after adding new hardware and making it alias to the correct input or output module. I can usually stumble through the process but I am just asking to see if I can gain a more thorough understanding of why things are the way that they are in the world of logix5000

When you find out please post it here. Me, I'll continue to be not concerned as I've been exposed to it for 20 years now.

jstolaruk said:

Yes, it can be confusing, more like different people, while designing the modules, created different structures. But let me through a word out there that once you start using it, it will be indispensable:

ALIAS

No matter what the module structure is, I create tags that are aliases to the module's properties that I'm interested in using. It allows me NOT to be concerned with the module layout, just using these tags gets me to the data that is important for the task at hand.

Click to expand...

Well, I hope I never hire you to write a program then...aliases are the devil.

RET said:

Well, I hope I never hire you to write a program then...aliases are the devil.

Click to expand...

I find them quite useful and powerful, they can make program development much quicker saving you $$$ and can provide much more clarity while allowing for functional efficiency. Especially when concerned with communication to SCADA systems.

Working on large batching systems, aliases are a dream when having to make tedious program changes. 'Find and Replace'....please, I'll just change a single alias reference OR, just copy and paste and let the alias update itself.

You should be more concerned about someone writing you a program that doesn't understand how to create a well structured tag name convention than if they use aliases.

Every program I've had to either convert or move over to another physical platform with different i/o mapping, aliasing has been nothing but a serious PITA, and made it harder to cross reference and follow the program flow.

That's my opinion and I'm stubborn to change it.

aliases are a dream when having to make tedious program changes

Click to expand...

That just sounds like a crutch for laziness.

RET said:

Well, I hope I never hire you to write a program then...aliases are the devil.

Click to expand...

No worries, knowing that I would no-quote everything.

blanchsb1 said:

Thanks jstolaruk. I understand the importance of aliasing and love the usage as well, but it can be a little difficult to alias correctly sometimes if I don't know what structure I am aliasing to (like in example 2 and 3).
This is true for me when creating new logic after adding new hardware and making it alias to the correct input or output module. I can usually stumble through the process but I am just asking to see if I can gain a more thorough understanding of why things are the way that they are in the world of logix5000

Click to expand...

What you are seeing there is the difference between the "Plain Vanilla" output module (OB16P), and a "Smart" output module (OB8EP).

The OB16P is read by the controller in rack optimized format, meaning that it is just one entry in an array that the processor reads as a group. All simple I/O modules are handled like this, essentially on a single communications channel, so you need the adapter, the index into the data array for the rack, and the bit number to reference a point.

The OB8EP has a communications channel all its own, since it isn't just a simple module. It has both multiple groups of input elements, and multiple groups of output/configuration elements. That cannot be handled over the simple rack optimized format.

This is why even though there might be a limit of say 10 connections for a particular communications adapter, there can be more then 10 actual IO modules hung off of it. Anything that fits into the simple rack optimized format only consumes one connection. You cannot however address 11 smart modules that each require one connection.

RET said:

That just sounds like a crutch for laziness.

Click to expand...

Something like that.