Logix 5000 : Local Tag Definitions

AMarks95

Member
Join Date
Jul 2018
Location
South Dakota
Posts
224
I know the syntax for local tags on various processors varies, but I'm not familiar enough with all of the different PLCs to know which ones will be the same, or how many variations there will be.

For example, I have one project that addresses IO like so:

Code:
Local:1:I.Data.13
and
Code:
Local:4:O.Ch0Data

and another that addresses IO like so:

Code:
Local:1:I.Pt13.Data
and
Code:
Local:4:O.Ch00.Data


Any insight into how many different variations there are, and which PLCs use which syntax?
 
I think the differences arise from the different I/O hardware platforms. And it really occurred when RA came out with their Compact5000 I/O line.

The first two addresses in your example look to me like ControlLogix using the 1756 hardware platform. Though it could also be CompactLogix using 1769 I/O. The tag names really don't change between those two systems.

When you move to CompactLogix, and the 1769 I/O you see the tag structure is pretty much the same as ControlLogix. But there are some slight differences in the organization and format, if not the actual naming. For example, adding a 16-pt digital input module in the ControlLogix with all default settings creates a DINT for the "Data" where it is an ""INT" in the Compact. Likewise, adding a standard analog input gets your data stored as a REAL in the CLX but an INT in the CMPLX. But the actual tag names are consistent between 1756 and 1769.

Now, when you move to the newer 5380/5480 CompactLogix controllers using Compact5000 I/O, then things are noticeable different. That's where your third and fourth examples come in. Both digital and analog tag structures and names are different. The organization of the tags is different too. I find the new format to be much clearer.

You specifically mentioned Local I/O, but of course when you get to remote I/O things can be a little different there too. So, it isn't so much the controller, but the I/O that determines the tag format. That means we have two different formats for Local I/O tag naming. We would place the CompactLogix 5380/5480 models on one side since they use Compact5000 I/O, and all of the other controllers on the other side.

OG


*EDIT* if you really wanted to dig deeper, the old FlexLogix controller (long obsoleted now) was a controller that sat on a DIN rail and used 1794 Flex I/O modules for its Local I/O. Those used a format that was slightly different too. The analog was pretty much the same as the CLX and early CMPLX, but the digital was very different. For example Local:2:I.3. Note, no "data" in that name. Oddly, the DriveLogix (also long obsoleted) used Flex I/O for its Local I/O. But even though it used Flex I/O, it followed the same pattern as the CLX and CMPLX. So the FlexLogix controller was definitely an odd duck in the 5000 family when it came to its tag naming.
 
Last edited:
That makes alot of sense. Both of these are actually CompactLogix processors, but the first is 1769, the second is 5069.

So, I have those 2 down, but like I said I'm not familiar with all of the hardware. Where can I find all of the IO hardware that would be compatible with Logix 5000?
 
In your project under controller area, at bottom is the IO config tree. This shows all the IO that is attached to the plc controller.
If your looking for advice i would go to youtube and look up videos on how you add IO modules, building your IO tree. Of course the electrical prints have to match this IO tree.

Then once you have that down make sure your familiar with module firmware revisions as it relates to a module in your IO tree. The use of RSLinx can be used to see what firmware revisions are on a live system.

I could go on but i think this is what your asking about now.
 
Logix 5000 is a collective name for a whole family of controllers. I don't know that Rockwell has a document that necessarily covers that entire family. At least not one I'm familiar with. But this would be a starting point

https://www.rockwellautomation.com/...e/allen-bradley/programmable-controllers.html

The Large, Process, and Small controllers are all part of the Logix 5000 family. Click on any of those to jump into more details. The Micro controllers they list here are not part of the Logix 5000 family. They are a separate family of micro PLCs.

OG
 
In your project under controller area, at bottom is the IO config tree. This shows all the IO that is attached to the plc controller.
If your looking for advice i would go to youtube and look up videos on how you add IO modules, building your IO tree. Of course the electrical prints have to match this IO tree.

Then once you have that down make sure your familiar with module firmware revisions as it relates to a module in your IO tree. The use of RSLinx can be used to see what firmware revisions are on a live system.

I could go on but i think this is what your asking about now.

I am well aware how to add modules to my IO tree. I'm wanting to define the syntax for the IO points of the various modules so I can create a spreadsheet that will import the tag descriptions into the IO definitions for me.
 
I think the biggest difference in Local IO formats are the different brands:
Compactlogix, contrologix, flexlogix, VFD IO formats, and Point IO.

To see the difference io points in CSV there has to be a description entered in the controller tags to see it in CSV spreadsheet.
 
I am well aware how to add modules to my IO tree. I'm wanting to define the syntax for the IO points of the various modules so I can create a spreadsheet that will import the tag descriptions into the IO definitions for me.
I've done this, and oh boy was it a PITA to work out the exact formatting for all the different platforms and types of module. There was even one quirk where a 1756 analog card (can't remember whether it was input or output) in the local chassis had a very, very tiny difference when compared to the same 1756 analog card in a remote 1756 chassis. All the other 1756 modules are the same whether local or remote, but just that one did something like "Ch1Data" in the local chassis, but "Ch01Data" in the remote chassis. Infuriating.

All that just goes to say - good luck, you can do it, but it's painstakingly tedious.

Of course now that I have it done, it's f***ing great :ROFLMAO:
 
Last edited:
I've done this, and oh boy was it a PITA to work out the exact formatting for all the different platforms and types of module. There was even one quirk where a 1756 analog card (can't remember whether it was input or output) in the local chassis had a very, very tiny difference when compared to the same 1756 analog card in a remote 1756 chassis. All the other 1756 modules are the same whether local or remote, but just that one did something like "Ch1Data" in the local chassis, but "Ch01Data" in the remote chassis. Infuriating.

All that just goes to say - good luck, you can do it, but it's painstakingly tedious.

Of course now that I have it done, it's f***ing great :ROFLMAO:

I have a spreadsheet that will be a working document and only updated as needed. I might have to rework it completely, at some point, but I don't want to put that work into it if most of it's not going to be used. We use the same modules a majority of the time, so it might be easier to just manually type in those other cases.

Anyway, I've got the format down for 5069, 1756/1769, and 1734, since those are the four most common for us.

5069: Local:#0:I.PT00 | Local:#0:I.CH00
1756/1769: Local:#0:I.DATA.#0 | Local:#0:I.CH#0DATA
1734: Local:#0:I.#0 | Local:#0:I.CH#0DATA

I have already found this case that you mentioned once:
All the other 1756 modules are the same whether local or remote, but just that one did something like "Ch1Data" in the local chassis, but "Ch01Data" in the remote chassis. Infuriating.

the 1769-IF8C uses the Local:#0:I.CH#0DATA format, while the 1769-IF16C uses the Local:#0:I.CH00DATA format.

(for those unfamiliar with numeric format strings, "#" is an optional digit, "0" is a required digit.)
 
Urgh, not sure if I caught that one or not! I'd like to have some words with whoever was in charge of firmware standardisation on the ControlLogix platform :confused:
 
Urgh, not sure if I caught that one or not! I'd like to have some words with whoever was in charge of firmware standardisation on the ControlLogix platform :confused:

Good luck with that! :ROFLMAO:

FWIW, Rockwell's discrete IO data *can be* generalized controller-side to a common format (one of my ongoing side projects).

Could end up more cumbersome than what it's worth, but some UDT magic and/or AOI fairy dust might get it there.

Some practical info:
5069 DI/DO format uses a 4 bytes per point.

5069 default DI stuff (bits populated are dependent on the IO config, but they are always fixed positions):
  • INT: DataBits
  • Bit 0: Data
  • Bit 1: Fault
  • Bit 2: Uncertain
  • Bit 3: Open Wire
  • Bit 4: Short Circuit
  • Bit 5: Chatter
  • Bit 6: Field Power Off
  • Bit 9: Status (safety)
  • Bit 10: Indeterminate
  • Bit 12: Timestamp Overflow OffOn
  • Bit 13: Timestamp Overflow OnOff
  • Bit 14: CIP Sync Valid
  • Bit 15: CIP Sync Timeout
  • INT: Pad

You can COP Pt00Data into a DINT for example and have the all the bits to maneuver with.
 
Last edited:

Similar Topics

Hello everybody, I have a vendor system that has some remote monitoring (read only) and remote control (read/write) data that is available via...
Replies
7
Views
2,872
I know tags can be im/exported from/to an L5K. Wondering if IO tags (Local:1:I) can be overwritten in the same way. For example, if I have an L5K...
Replies
1
Views
776
Hello, I'm trying to create IO tags that will allow I/O to be changed via the HMI once the system is deployed, and without needing to connect via...
Replies
3
Views
2,798
Good Afternoon , I worked on a project from home this weekend . Added some local and controller tags to it . At the plant most likely a lot...
Replies
8
Views
2,580
Crimson 3.0 version build 624.005 Driver Allen-Bradley native tags via L5k file enhanced Studio 5K version 24. So crimson cannot see the "local"...
Replies
13
Views
5,003
Back
Top Bottom