AB DF1 protocol with new Logix PLC


Thread Starter

Maurizio Fumagalli

I'm trying to communicate with an AB PLC ControlLogix5550 with my operator panel via my standard DF1 protocol but it doesn't work. I have a copy of the AB DF1 documentation but this new
PLC isn't supported.

Can anyone help me?
Thank you and best regards

Maurizio Fumagalli
[email protected]
The operator interface you have probably only communicates to PLC-5 and SLC-500 processors using the older "PCCC" command codes for A-B logical addressing. The ControlLogix uses tagnames and most 3rd party operator interfaces have not yet upgraded their protocols to support
the Logix.

Fortunately, the ControlLogix can easily emulate a PLC-5 or SLC-500 in its response to queries through the DF1 port. Go into RSLogix 5000 software and select the Logic pulldown menu, then "Map PLC/SLC Messages".

In this window, you select the "PLC-5" style data table number you want the Logix to emulate, and assign it a ControlLogix controller-scope tag to

I usually create a 16-bit Integer array in the Logix (say, "OIArray"] and assign it to common Integer register data file numbers like 7 or 10.

When the operator interface requests, for example, the register "N7:4", the Logix will reply with the value of "OIArray[4]".

It's also possible this isn't the problem at all; I have run into some 3rd part interfaces that don't do true DF1 full duplex (they were adapted from Modbus RTU) and cannot handle the reply speed of the ControlLogix. Handshaking doesn't help because they simply go blind for a few milliseconds after sending a data request, and don't see the reply.


Ken Roach
A-B Seattle
[email protected]

Jerry Miille

I have an application note that I wrote describing how to do this for our Omnii-Comm Protocol Converter. Should be the same as for your operator Panel. Please contact me directly if you would like a copy.

Jerry Miille

Miille Applied Research Co., Inc.
Houston, Texas
[email protected]
You have two options -

1. In RSLogix5000, use the "Map PLC/SLC Tags" option. This allows you to make an array of ints 'look' like a PLC5 file. It can then be accessed with PLC5 DF1 commands.

2. Go to http://www.ab.com/manuals/cl/ and grab pub 1756-AP002A-US-E "Programming Messages In a ControlLogix System". This describes CL additions to the protocol documented in 1770-6.5.16.

Cheers !

Dan Hazel
Rockwell Automation

The new ControlLogix PLC platform for all intents and purposes does not use the DF1 protocol at all. The "new" protocol is called "CIP". It is completely different than DF1. It is MUCH more complex (and obfusicated) than DF1. It has the ability to "embed" DF1 messages but it can not deal with DF1 directly.

This "new" CIP protocol is much more powerful than DF1, but for the vast majority of the world, this "power" is meaningless.

If your operator panel is a PC based device, then it is possible to get the CIP base spec from www.controlnet.org. Using this spec, it should be possible (but probably very time consuming) to rewrite the base code of the panel to talk with the ControlLogix. Be aware that the spec is VERY difficult to follow. Your only other option would be to upgrade to a new operator panel that
supports the CIP protocol.

Ron Gage - Saginaw, MI
([email protected])
Good day all

I have not used the Logix5000 but I understand that it uses a symbol based method of referencing much the same as high level programming. I encourage the use of symbols wherever I work. So I
am at a bit of a loss to understand why someone would want to continue to use address referencing or emulation of other PLC address structures.

Could someone that has used both possibly explain were they favored one approach over another.

Allan Dow

Dan Hazel, Allen-Bradley

Agreed - symbols are a much better way to go. Unfortunately, we'll be stuck with symbols that look like traditional PLC addresses for a while.

One reason is recycling of existing programs. The translation software doesn't have a clue - so the best it can do is make symbols from the existing addresses. Schedule permitting, you can change them later.

The bigger reason is integration with existing HMI and PLC systems. Need to use a 'least common denominator' approach.

Finally, it's more efficient to read an array of values, rather than a scattered group.

Dan Hazel
Rockwell Automation
Hi Dan

Thanks for the response. I understand the concept but my question is why would you take what appears to be a retro-step. Is comms to DF1 the only reason? I see it as a bit like program in C via addresses rather than variable names.

Allan Dow
Embedded Systems & Solutions