Peer Communication from One Allen-Bradley PLC to Another

This is one of those things that you just expect should be easier than it is. I am forever baffled why there isn’t a single standard for TV/Cable remote controls. Why do you have to go through the list of hundreds of codes to get your new remote control to talk to your Sony, Samsung, or LG television? Why isn’t there just one standard that every manufacturer can agree to so that it can be preprogrammed into a remote control? I’ve put up with barely functional remote controls just because I didn’t want the hassle of programming them.

When people start thinking about how nice it would be for two Allen-Bradley PLCs to talk to each other, they also start thinking that this has got to be simple. There must be some parameter where you give the PLC the address of the other PLC and they automatically can share data table values? That’s not the case with most PLCs, though it’s gotten better with more recent controllers. But unlike TVs, where new models come out all the time and a standard could be put forth, PLCs stick with us for five, ten, or even twenty years. They were built at different times when different communication standards existed with different kinds of technology. I don’t blame AB for this. They’ve been in the PLC business for almost 50 years now, and we can’t expect everything to be compatible over all those years.

There are standards that exist for PLC to PLC communications. PLCopen is an organization that has put forth some function blocks that let any PLC talk to any other PLC that supports the standard. At the heart of those function blocks is OPC UA, a standard for factory floor communication. OPC UA operates at the information level while things like EtherNet/IP and PROFINET IO operate at the I/O level.

I don’t know how widely used those function blocks are. I know that some people use them, but I think that if you are just doing PLC communication from one ControlLogix to another ControlLogix, it’s likely that you will just use unicast communication. Unicast communication, as you might remember, is a messaging mode in which a transmitting node sends a message directed to a single recipient within the same network or within another network.

ControlLogix PLCs have two types of message ports for these messages: connected and unconnected. The unconnected message ports are used for messages that are intermittent in nature and don’t require the overhead of opening and closing a port. The connected message ports are for messages that are going to be ongoing. You could use either for your PLC–PLC communication depending on how often and for how long you need to establish the communication link.

Many people think that they can simply make one PLC an EtherNet/IP Adapter and use EtherNet/IP communications to share data. That’s not possible with the current ControlLogix configurations. A PLC can never be configured as an Adapter. Other, more non-standard, communications mechanisms must be used.

As with much of industrial networking, establishing the connection is the least difficult part of the task. You can easily implement the communication link, but what are you going to send? The content of the message is much more important and requires a lot of thinking.

You could do it on an ad hoc basis. PLC 3 needs the motor drive status from PLC 5 so you set up a message for that. And when PLC 4 needs a temperature from PLC1, you set up another message for that. Or you could develop a data structure for standard kinds of data. At one vehicle manufacturer, they have a standard robot control structure that is shared between all PLCs whether they need it or not. If something changes and the data is required, it’s already there.

It’s a good design practice to make critical process data in a user-defined data structure and share it among all your PLCs using unicast communication links. There are lots of ways to do this. You could have PLC 1 put its data in the structure and send the structure to PLC2, which updates it and sends it to PLC 3. It all depends on the requirements of your process.

Like many things in industrial automation, there are many ways to skin this cat and some good ways to attack the problem. I have hope that the ways we can do this will get more sophisticated as we move forward.

I just hope that in my lifetime, getting a TV remote control to work will be simpler than it is now.