AB PLC Peer-Peer Communication

It’s as sure as the sun coming up in the east and a politician asking for money: as soon as you get two Allen-Bradley PLCs in operation, you’ll want to coordinate their operation and exchange data. Unfortunately, that’s not as straightforward a task as you might expect. In this article, I’ll discuss one of the common ways that you can accomplish that coordination and exchange of data.

A control engineer’s first thought is to use EtherNet/IP. It would be great if you could just use the second PLC as an EtherNet/IP adapter device. Unfortunately, that’s not the case. AB PLCs are unable to become EtherNet/IP adapters. In fact, most of the legacy ones – SLCs, PLC 5s, and the like – don’t support any EtherNet/IP at all. I talked about this at length in my article on ControlLogix peer communication.

The way that some control engineers accomplish this is to configure two unidirectional connections between the two PLCs. On each side of the link, the PLC would cyclically send a message to the other PLC. This accomplishes almost what an EtherNet/IP scanner/adapter accomplishes. In that relationship, a scanner sends outputs to an adapter on some schedule and the adapter sends inputs back to the PLC on some other cyclic schedule. The two unidirectional connections mimic that operation.

What’s different is that the communication is more automatic when you use EtherNet/IP. With EtherNet/IP, you name the adapter you are going to be using and the tags for input and output, and the PLC handles the complex series of interactions that establishes the EtherNet/IP scanner/adapter relationship. There is a whole lot of structure to that relationship. It specifically defines how the two devices initiate communications, what happens on failure, and how the relationship is terminated. When you initiate two bilateral communications links, you are on your own and have to build whatever part of that infrastructure you need, yourself.

Both the automatic communication of EtherNet/IP and manual communication of two bilateral communication links point to tags that get exchanged. Generally, you are going to use a tagged variable data structure. You can exchange any data you want as you’ll be customizing the PLC programming on each side. You’ll need to manually make sure that both PLCs process the data properly. As you might suspect, it is a good idea to establish a common structure for this operation so that you can keep your PLC programming identical from one PLC to another. That way, you be able to easily extend the data by just adding to the data structure on both sides or simply add another PLC to the mix and have it use the same structure.

One nuance to this kind of communication is that AB PLCs don’t produce data from a structure like that in an atomic operation. You can’t count on the data being stable when the communications occur. The PLC could be halfway through updating a floating-point value when the value is transmitted. That’s going to give you all sorts of problems.

The workaround for this particular problem is to send a copy of the produced data. Use a copy operation to copy the original data into a variable tag structure. Have the cyclic production message send the data generated by the copy instruction. The copy operation is “atomic,” meaning that it finishes in one uninterruptable execution so you’ll always have complete data to send. The communication system can’t transmit a partially updated variable content of a variable that is the object of a copy instruction.

You must do the inverse on the received variable data structure. Copy the received data into a local variable and then operate on the local copy, not the copy received from the other PLC. If you do this, the contents of a received data structure available to the program can’t be updated when the program is only partially through decoding the contents of the data structure information.

This kind of problem is unique to the unidirectional communication paths described above. PROFINET IO, Modbus TCP, BACnet, and EtherNet/IP communication are integrated into the PLC operation in such a way that this is not a problem.