EthernetIP and Multicast

I am trying to understand something with regards to EthernetIP and multicasting. The network involved is a CLX processor talking to FlexIO modules. I have read the Application Note A46234811 several times for clarification but it has not answered my question. I have uploaded this file for review.

My understanding (which may be wrong) of mulitcasting is bandwidth conservation and in my application, I don't really gain anything from this. This may seem stupid, but how would you get rid of mutlicasting?

I have a single 1756-ENBT talking to 4 (four) 1794-AENT nodes. Each of the 1794-AENT nodes contain a combination of IB32 and OB32 modules. As far as I am concerned, this should all be unicast becasue there is only 1 conusmer of all data being exchanged.

The CLX (through the ENBT) PRODUCES data to a particular OUTPUT module and that particular OUTPUT module CONSUMES it. This method is done for all modules in the system (I am using a direct connection due to having 32pt modules).

Each of the INPUT moduels PRODUCES data (at the RPI) and is sent to the single ENBT module that will allow the CLX to CONSUME this data.

This whole process of exchanging is UNICAST the entire time. So to prevent certain hosts (AENT modules) from being flooded from data that it doesn't need, I have to use a switch that suppports IGMP so that only the nodes that want the data will get the data. But it seems that each of these multicast groups will have only a single member. Because of this multicasting, I have to invest money in a better switch which I really wouldn't need if everything was UNICAST.

I hope I am missing something here and just need some clarification.

Your understanding of multicast is correct for your specific system, except the fact that it is universal method for all applications and this is how it was defined in Ethernet/IP spec originally.
Systems may have multiple contollers that will be using the same I/O modules so producing input data once lets all controllers read it. Same for outputs: one PLC owns the module, other can have a listen connection.
Since Ethernet/IP spec changed recently Ver 16 introduced unicast for Produced/Consumed tags. We can assume that it will be unicast I/O option in a near future.
There is nothing wrong with multicast, managed switches with IGMP snooping and VLAN can easily handle multicast.

Also with your system you still will have an individual unicast or multicast message for every 32pt module. To minimize traffic you should use 16in/16out modules that allow rack optimization

Thanks for the response Contr Conn. While on this subject, I would like to ask something else.

I am in the process of specifying a switch with IGMP snooping capabilities (to handle this burden of multicast). The problem you run into is that just becasue a switch has this capability, it doesn't mean it will actually work. The snooping function just means that it can 'listen' in on JOIN/LEAVE messages. These messages are generated by another device (router or Layer 3 switch). The results of this snooping (listening) will create the proper routing table to prevent mulitcast flooding problems.

So my choices are to get a switch that has all the capabilities (Layer 3 switch) in a single unit OR I need a switch with the IGMP snooping function and another unit that does the IGMP quering.

I took a look at the N-Tron product line and the 500 Series (with A option) seem to cover this as a single unit but I can't seem to justify this price. Is there something out there that compares to this as far as IGMP technology but doesn't require me to pay for the 'industrial version'. In my application, I don't anticipate really needing an 'industrial version' switch. The environment is in a clean room and I don't anticipate any real noise problems.

Maybe I am backing myself in a corner but I just want to see what are some other options.

Personally I would not go with a cheap "switch" since you are using enet for I/O. We have went around and back on this issue over the years (with HMI comms). When that switch fails you loose control of your i/o. loosing an interface is bad enough but your I/O is another story.

I should clarify that my setup is already isolating the IO network from the DATA network. The IO network will handle the FlexIO (1794-AENT) devices and the DATA network will be used for HMI communications, program upload/download and other various devices that we may want to access through Ethernet. I am using two different ENBT modules to handle this. This gaurantees that the two are completely independent from each other.

My intention is to provide a good switch that can handle multicast for the IO network and provide a somewhat 'off the shelf' switch for the DATA network. Nothing on this network is that critical as it is all EXPLICIT messaging.

I am just trying to evaluate my switch options for the IO network. I am trying to avoid an 'industrial version' if possible but not neccesarily go cheap.

The switch that I typically spec is industrial but only cost $290 for the 4 port version (sounds like the size you need). I have had great luck with these and I haven't had any fail.

Chehk out www.N-Tron.com they have one of the easiest to use.

Here is the layout of my IO network. The mistake that I have made originally was using 32pt modules which prevents me from using RACK OPTIMIZED connections. But it is too late to change now due to the design of the system. This is why I want to be careful with the items that still need specified such as the Ethernet switch.

In my experience the combination IGMP querier/snooper switches from N-Tron, Rockwell, Hirschmann, and Cisco are worth the money just in hassle-reduction. I never have to worry about what else is being connected to the system and whether the guys who control the upper-level networks have done their jobs right. I especially like the power supply connections, as I don't want my applications at the mercy of a wall-wart transformer.

Let's talk about your application. Are you running very fast (5 ms or faster) RPI's on these FLEX adapters ? The 1794-AENT has a good low-level UDP multicast filtering mechanism, so you don't have to worry about "blinding" the -AENT's, unless you're trying to push through a thousand frames per second each.

And let's talk about the upstream gear. If the ControlLogix gear is the only equipment that will be connected to this switch, then you have one element of justification for an unmanaged switch, because all the equipment attached can handle the multicast traffic.

If you are connecting an upstream router or another switch to this network, you have to look at it carefully. Does it have port management or VLAN capability ?

Ken -

My diagram of my IO network is exactly what is involved. There is a 1756-ENBT module in one slot of the CLX rack and a second ENBT module in another slot. This second module is used for HMI, upload/download and general processor communications.

If I need to access anything on the IO network, I will just use the CLX rack as a bridge. Essesntially, the IO network is completely isolated and nothing will ever directly plug into this network. My intention is that it is standalone and hopefully worry free. It's existance will not even be known to the IT department. I can't let those guys (experts as they like to think) get their hands on it. Maybe a little overkill, but I don't want any future problems.

I have not decided what my optimal RPI will be. There is a few modules that I have decided will need to be alot faster but for the most part, everything is just air valves and sensor feedback and the RPI can be pretty forgiving. Something like 20ms or so.

I plan on doing my packets/sec calcuations with my determined RPI to make sure that the modules can handle them. Like I mentioned earlier, I can't utilize rack optimization but that is something I overlooked in the past and there is no turning back now.

I do agree with your comment on using those brand switches due to their hassle and worry free integration. I just wanted to explore all my options before I decide to go with something like this.

Thanks for your input and would appreciate anything else you have to offer.

If network picture is complete (nothing else involved), than you really don't need IGMP snooping.

But you have another problem: 30 connections
The best RPI you can do is probably 15ms (4000 packets/sec). You really should review your hardware and get 1794-IB16XOB16P modules that will allow you do use Rack optimization.

Yeah, I realize that I should have used 16I16O modules. But that is a screwup from the past that I can't change easily now. I should have asked more questions earlier but I did not.

If the specs on the ENBT module are correct (5000 packets/sec) then I will go with the following RPI setup.

28 of the 30 modules will use an RPI of 25ms. These modules should be just fine with this. Doing the math, I get (2*28/.025) 2240 packets/sec used. That leaves me with 2760 packets/sec for the last 2 modules. With this I can have a minimum RPI of (2*2/2760) 1.5ms. I would most likely just use a value of 5ms to give me some breathing room.

I am in the process of getting those 15 IB-32 modules and 15 OB-32 modules changed to 30 IB16XOB16P modules. I essentially will have the same amount of IO (both in each rack and total points) except now I will be able to use RACK OPTIMIZATION.

The 32 point modules have been ordered already but there wasn't enough time put into using these modules that will prevent me from changing this now. I am just verifying that the order from the factory will accept this change this late in the game.

I will just have to remap the IO points in my logic (because that has already been written). This will reduce my 30 connections to only 4 and allow for a faster RPI and less traffic on the network.

I wish I would have asked more questions earlier but hindsight is 20/20...

Before setting low RPI values check if you really need them that low.

Will your data change that fast?
What is your scan time?
Will you use high speed periodic tasks?

Also, on the picture above you put multicast addresses - why? They are automatically assigned buy firmware and you have no control with ENBT.

Contr Conn -

The multicast addresses that are shown is for reference. These are the values that AB has documented to generate. The application note that I have attached to my first post comes with an Excel file that shows you how to figure them. Once again, reference only.

Anyways, I understand that I don't need a fast RPI. There is no point in transmitting IO data any faster than my logic scan time. My goal is still to reduce the amount of traffic on the network and I am doing that by taking your recommendation and changing my hardware to 16In-16Out modules.

I think that I am going to take Ken Roach's suggestion and not use a 'managed' switch. That will be a little cost savings.