Multicast (One More Time…)

If you’re doing it right, life is a process of continuous learning. If you’ve learned something today that you didn’t know when you got out of bed this morning, you’ve had a good day – no matter what else happened.

Today I learned a little more about multicast communications – more than I knew two years ago when I wrote my original article on multicast communications. I not only learned more, but I also have a few corrections to that original article. If you haven’t read that article or you’re new to multicasting, now would be a good time to get started.

The purpose of multicasting with EtherNet/IP is to share data from a device with many other devices. The classic case study is a set of HMIs that all need to have the same data: the speed of a motor, the pressure in a pump, the temperature of an oven. One way to do that kind of application is to have the scanner get the data from those devices and store the data in Programmable Controller tags.  Each HMI that needs the data could open a unicast connection with the Programmable Controller and read the tags it needs. That approach adds a tiny latency to the data, but if we are dealing with HMIs the latency isn’t an issue. More importantly, it uses connections in the Programmable Controller, and sometimes those connections are in short supply.

Another way to implement that application is with EtherNet/IP multicasting. Anything that wants those temperatures, speeds and pressures would request a listen-only connection with the devices generating the data. Those devices would agree to supply that data to them on the multicast link, and they would all get the data at the time the owner of the link, the Programmable Controller, gets it. That eliminates the latency and saves scarce controller connection resources.

In the original article, I went through the basics of multicast addressing and talked a lot about the IP (Internet Protocol) stuff behind multicast addressing. What I failed to do there was to really explain how EtherNet/IP uses multicasting.

Here is the basic process of EtherNet/IP multicasting without a lot of the IT technical jargon getting in the way:

1. The owner of the device providing the multicast data is going to be “owned” by a Scanner device. Owned, in this context, means that the Scanner opens an I/O connection with that device and the Scanner, and only that Scanner, can write to that device’s outputs. The Scanner is almost always a Programmable Controller.
2. The Scanner making the original connection requests a multicast connection when making that original connection.
3. When the device receives the multicast connection request, it now knows that other devices are going to request its multicast inputs (data out of the device – outputs are data into an EtherNet/IP device) and do connection requests.
4. The other devices that want to connect to the device make “Listen-Only” connection requests with the device in question. With a Listen-Only connection, they can only get inputs from the device.

One other mistake I made in the original article was my statement that PROFINET IO also uses multicasting. That’s only sort-of true. Carl Henning explained how Profinet designers approach multicasting in this great article in his Profinet Blog Post on Profinet multicasting.  He states that PROFINET IO does support multicasting but argues that its irrelevant with the sort of bandwidth and network speeds we have today. Definitely a good read if you’re interested in multicasting of either EtherNet/IP or PROFINET IO data.