It’s no wonder that many control engineers confuse Allen-Bradley PLC Communications with EtherNet/IP communications. AB (and Rockwell) is so synonymous with EtherNet/IP that it’s hard for the casual control engineer to know where AB PLCs end and EtherNet/IP starts. In this article, we are going to take a look at both and define exactly what that difference is.
Allen-Bradley programmable controllers had lots of communications facilities long before EtherNet/IP arrived on the scene. Remote IO was probably the first popular mechanism for connecting IO to a controller. Prior to Remote IO, all I/O points were hard-wired back to the controller. There were literally thousands of wires that had to be laid in wire trays and checked out one at a time by plant electricians. It was costly and tedious. Remote I/O simplified all that and reduced the cost and complexity of field wiring. The next major step forward for AB PLC communication was DeviceNet. DeviceNet, along with Profibus DP used by Siemens, were the first and most popular of the Sensor Bus technologies.
As popular as DeviceNet was, it was rapidly displaced when EtherNet/IP began to be deployed. EtherNet/IP offered many advantages over all the sensor bus technologies. EtherNet/IP used off the shelf technologies and equipment to dramatically lower the overall cost of training and ownership. EtherNet/IP operated initially at 10 Mbps, nearly 20 times faster than the fastest version of DeviceNet, with the ability to carry much more data in a packet. Over the last twenty years, it’s been a clear choice for manufacturers to automate their product line.
During all this time, as I/O technologies progressed from hard wired I/O to data highway to remote I/O to DeviceNet, and finally to EtherNet/IP, AB controllers always supported another type of communication. A communication protocol that allowed access to the data table of a PLC. That communication protocol was something called PCCC (Programmable Controller Command and Control Language).
PCCC is an application layer protocol with Read and Write commands to access the data table and perform other PLC operations. That application layer protocol must be carried by some lower level, transport, and link layer protocol. In the early days of PLCs, Allen-Bradley used DF/1 as the transport and link-layer wrapper to move a PCCC command from a PC to the PLC. DF/1 operated over a physical RS232 link and could be configured for Full Duplex or Half Duplex communications.
Over time, PCCC evolved. The number of commands and functionality increased. Specific commands were added for various models of PLCs, and the way the commands were transmitted to the PLC changed. Some systems began to use USB to connect laptops to PLCs instead of serial ports, and later Ethernet. Ethernet eventually became the standard way to interact with an AB PLC.
That’s where a lot of the confusion lies. Because commands to read and write registers of the PLC use Ethernet, and EtherNet/IP uses Ethernet, it is natural for the layperson to think that PLC data table communication and EtherNet/IP I/O communication is one and the same thing. They aren’t.
RTA helps vendors who develop automation devices with both. We have EtherNet/IP stacks for those automation vendors that need to operate on an EtherNet/IP network as EtherNet/IP Scanners or EtherNet/IP Adapters. We also have a communication stack for those vendors who just need to read and write the data table of a PLC using PCCC communications.
You can contact one of our application engineers at firstname.lastname@example.org or call us on 800-249-1612 to get more information on how your automation device can be more integrated with Allen-Bradley PLCs.