Lynn's Industrial Automation Protocol Tips
Home > Rockwell >
IP-Enable Blog
New iatips Wiki
White Papers
Digi Product Tips
Yahoo Group
Contact Info

The information on this web page is either Lynn's opinion or something Lynn agrees with. He has complete control over its contents. Nothing contained within this pages is approved by or represents the opinion of Digi International, The Modbus Organization, the Modbus-IDA Group, ODVA, or any other organization Lynn is associated with.

Rockwell Protocols

Question? What are Rockwell's most common protocols?

In a nut-shell, I'd say:

  • for most PLC, DF1 Full-Duplex on RS-232 is what you need to use/know
  • for most small networks, DH485 is the way to go but isn't a published spec
  • for future/long-term work, Ethernet/IP and DeviceNet will be the things one uses most 5-10 years from now.

return to top

Question? What are the 2 main protocol families?

Answer: PCCC or CIP

Basically PCCC lets you issue legacy poll/response messages to arrays of data. It is the default form used with DF1 and non-Logix processors such as PLC5 or MicroLogix.

CIP (or Control-Information-Protocol) is used in ControlLogix and CompactLogix processors. CIP is what Rockwell paints as the future. It is an object oriented paradigm where services are sent to specific instances of objects.

Understanding these 2 strong distinctions helps you understand what can and cannot be done. CIP messages can be encapsulated within DF1, but CIP messages can be larger than DF1 so a fragmentation protocol is required. This is how RSLinx talks to a C*Logix processor by DF1, but this is not documented. PCCC can also be encapsulated within CIP and Ethernet/IP.

return to top

Question? What is PCCC?

Answer: PCCC is the 'Application Layer Message Packet' of DF1

It is also referred to as PC-cubed.

I'm not sure what it really stands for - a good guess would be Programmable Controller Communication Commands. These are the 'Application Layer Message Packets' as shown in the on-line DF1 Manual Chapter 6. AB people do not include the DST/SRC bytes when they speak of PCCC - these 2 bytes are really the DF1 header attached to PCCC.

Basically, PCCC lets you issue legacy poll/response messages to arrays of data. It is the core message that moves easily between DF1, DH485, DH+, AB/Enet and Ethernet/IP with PCCC encapsulation. Each form likely has its own header format.

return to top

Common Rockwell Protocols by Media


DF1 Full-Duplex (FD): the core serial protocol spoken by most AB PLC. A peer-to-peer link - either side can send requests or responses IN ANY ORDER! DF1 uses a 16-bit TNS number to match requests to responses. (tip: avoid sending first request with TNS zero, as some devices will discard it as a duplicate since they init 'last TNS' to zero!) Most PLC can also have from 4 to 16 outstanding requests pending. Although it has a source/dest byte, most PLC ignore this.

Many newer PLC firmware can now "bridge" or "pass-thru" based on dest byte, so a PLC with both DH+ and DF1 could be set up as a gateway so that DEST=7 may mean "myself", while DEST 0-6,8-63 means pass-thru to the DH+. The knowledge base has many nice app notes covering the dozen+ ways to "pass-thru".

See: DF1 Manual (1770-6516)

DF1 Half-Duplex (HD): an interesting change from full-duplex - a Master node cyclically polls all the slaves for work. The response could be a response to the Master, or it could be a request or response for another slave, which the master MUST repeat to that destination slave as a proxy. So in many ways, the Master is the real slave of the network! It is very inefficient & slow. Half-Duplex has lost favor for DH485 (much, MUCH faster) - except when a half-duplex media like radio is involved.

See: DF1 Manual (1770-6516)

DF1 Radio Modem: a new change (2003?) to the old spec, it eliminates the ACK/NAK to cut the packet number in half, plus adds some thing for store-n-forward RTU use in radio networks. In this day when many radio and other modems offer error-recovery, the ACK/NAK have little value other than adding cost & delay. If I poll the PLC and it answers, then it must have seen the request. I'm not sure where this is documented, but the lower-end PLC have started to offer this.

See: AB knowledge base (at has a few tidbits on this, but the actual spec doesn't seem to be anywhere.

DF1 to Logix processor. DF1 has the ability to move other protocols within itself (CMD=0x0A or B). The ControlLogix and CompactLogix use a DF1 transport to move fragmented CIP messages. I beleive some AB drives also use protocols within DF1 that your average AB PLC won't understand. It uses just the data link portion of DF1, everything else is something else.

See: No public info I have seen. If you know CIP and then do a serial trace it's rather easy to see what's happening.

DH485 in RS-232. Most AB PLC with an RS-232 port also allow DH485 to be enabled. They assume an external (preferably isolated) RS-232 to 485 converter.


DH485 has displaced DF1-HD because it is a fast, token-passing bus. It allows slaves to talk directly to each other and eliminates the lone Master as single-point of failure.

It does NOT work thru radio modems or Ethernet encapsulation or USB because of the fast token rotation. This also means that some DH485 serial drivers under Windows don't work well due to Windows occasionally not servicing the port fast enough (AB had to create some custom serial drivers for RSLinx).

See: well, see nowhere I guess - this is a closed protocol. Many 3rd party OPC servers support DH485 as sole master, meaning they don't manage the token. So they can talk to a serias of "slaves" by DH485, but if any of the PLC try to take the token and initiate comms, the OPC goes off-line or screws up the token so comm fails.


AB/Ethernet(AB calls is CSP, but most others call it AB/Enet). An older TCP port 2222 protocol from the PLC5E series. Very closely related to DH+ and DF1. AB formally is trying to obsolete it since it only works on non-CIP messaging. I don't know of any public info on this (other than the commands moved are the same as DF1). A Ethernet sniff of the data makes it easy to see what's happening. You need to send an initial "register" command, but after that it is just a header with a PCCC command attached.

Ethernet/IP: This is AB's wager for Ethernet. It uses an older encapsulation protocol to move CIP messages. It can also move older DF1/PLC5 style message. See: for the spec. It has a big future. If I were king, there are some core things about the "encapsulation" I'd fix, but standards don't work that way - they build on what exists and some of that existing one wishes did not. It is object oriented (as opposed to register/table/file based like DF1)

** Others **

DH, DH II, DH+: a serial of older, proprietary token bus systems. AB's trying to move users off these to ControlNet. These are NOT RS-485 and require custom hardware and isolation transformers. They (DH+ at least) are also covered by patents related to token movement, so trying to reverse engineer them into a product isn't worth it.

ControlNet: a nifty network supporting dual-redundant media. It has both scheduled traffic and open space for other non-repeated queries. It works well for industry in that while trying to initiate a repeating control message stream, the system checks that band-width exists and the message succeeds ONLY if there is bandwidth available to dedicate & guarantee this same message can repeat itself as required. This allows it to be "theoretically deterministic" in a way Ethernet cannot - even though in practise Ethernet works well enough. (Plus Siemens and some drive companies are trying to hack an IEC standard to modify IEEE 802.3 Ethernet to include this scheduled/unscheduled slots idea - not something I support since it obsoletes all (ALL!) existing Ethernet hardware). Personally, I think ControlNet is a bit of a "BetaMax" - a 'better' technology that will never reach universal use.

DeviceNet: uses CANBus - a marvel of the modern world. The way it allows multi-node sharing of a bus with 100% utilization *AND* no collision loss *AND* priority is very impressive. CAN is the only non-Ethernet media I'd bet money on still existing in new products 20 years from now. Over simplified, CAN is to Ethernet what DeviceNet is to FTP or Modbus/TCP or EThernet/IP. DeviceNet is an application layer running on top of CAN. In many ways it is a nice compliment to TCP/IP+Ethernet - it is strong where TCP/IP+Ethernet is weak and weak where TCP/IP+Ethernet is strong. For example CAN allows a multi-drop or daisy chain of devices with bus-power. I predict the day will come when CAN/Enet bridges will be as common as Enet hubs/swicthes in industrial panels. So CAN will be the I/O feeder network into the Ethernet which is the site-wide bulk network.