Network switch recommendations

[alive15]

Hello, I have a A.B Compact logix communicating with two fanuc robots via ethernet. The plc also communicates to an automation direct hmi screen. For a while, the HMI began lagging a little bit on the cycle timers I had on the screen (meaning it would be counting up, then pause, then suddenly jump to the correct #). I swapped out the ethernet switch box for a new one from a different company, and it went back to working well for about 6 months, until the HMI began lagging again. I'm assuming it's a ethernet box issue since after swapping it out the first time, there was no lag for about 6 months. I plan to also add a PC which showcases the ladder logic live and also a remote io block, so I'm worried this will also slow down all the communication and definitely do not want any lag, especially between the robot and PLC.

Thanks,

 

[james13]

I would wager any lag isn't to do with the switch.
The small amount of traffic from all of the above would be handled by even the most basic Moxa for example.

Check anything with a buffer or logs to see if the memory is being reduced. I'd start with the robots.

 

[AlfredoQuintero]

Are you using multicast T->O settings? If multicast is not needed, maybe using unicast may help if your switch is unmanaged, as in case the switch does not have IGMP snooping function the HMI may be having to process unneeded traffic.

 

[James Mcquade]

is it a managed switch? if not, we use Ntron
an unmanaged switch polls the port and gets data every scan whether it needs it or not.

 

[alive15]

it's a regular unmanaged switch from McMaster. Is there a recommended unmanaged switch that sends data faster than other unmanaged switches?

 

[AlfredoQuintero]

alive15, hello. I do not think that replacing the unmanaged switch for another will solve your problem, but I need to be sure. There is not enough information in your posts to confirm whether the problem is what I believe, but since you confirmed you are using unmanaged switch, the likelihood of the cause of the problem being what I am thinking increases.

In EtherNet/IP IO communication, or implicit messaging communication, many devices are configured by default for "multicast" T->O (that is target to originator, or "adapter" to "scanner" or slave to PLC). What this means is that the IO data produced by the adapter device is sent to a multicast IP address, not the IP address for the scanner. If you have a managed switch, the switch remembers the ports to which the packet has to be forwarded an does not forward to those ports that do not need it. I suspect your HMI is getting overwhelmed by multicast traffic that is simply does not need.
If I am right, there is a soft and a hard solution.

Hard solution: Use a managed switch.
Soft solution: Change the IO connections in the scanner to T->O "unicast". That way the unmanaged switch will only forward the produced IO connection to the scanner and not to the HMI.

 

[alive15]

Managed switch sounds simple enough. So is there any programming involved in using a managed switch or does it automatically remember the ports as you mentioned?

 

[AlfredoQuintero]

You have to enable he Internet Group Management Protocol (IGMP) snooping functionality and make sure the port to which your HMI is connected is excluded from the group.
IGMP snooping - Wikipedia

However, I am not 100% sure if this is the cause of the problem. Before hooking-up a new switch, I recommend you connect a PC with Wireshark to one of the free ports in the switch and do a capture for a few seconds. If there is multicast traffic, you will get in the trace such traffic. If you post the data can analyze it for you if you are not sure how to interpret it.

 

[lfe]

These sporadic delays sound to me like an HMI problem, not a network problem, especially if you don't notice any lagging problems with the robots or other connected devices.

 

[alive15]

@AlfredoQuintero I uploaded the Wireshark file here, about a 3 minute capture: Easyupload.io - Upload Files and Share Them Easily

I do see all the traffic coming from only the two robots; 192.168.0.10 and .20 are the robots. The PLC is 0.1 and HMI is 0.2, while my laptop is 0.57 ; I don't even see the PLC or HMI traffic which is confusing me because how are they talking to the robots without sending data back and forth? I also pinged the PLC around 75 second mark. I attached a snapshot photo also:

 

[plvlce]

I don't even see the PLC or HMI traffic which is confusing me because how are they talking to the robots without sending data back and forth?

As Alfredo noted your trace shows multicast traffic, ie traffic which is broadcast to all devices including your PC. The PLC/HMI comm is presumably unicast, so the only way to see it would be insert a tap between the two devices.

 

[AlfredoQuintero]

What plvce is correct. I have done a quick analysis. There are at least two devices configured with T-> O multicast connection.
You show a trace that includes about 200 msec and shows 24 or so frames. The multicast traffic is about 80 packets per second. Not sure if this can negatively affect the HMI.
We need the trace with a tap to see HMI traffic.

Is the control engineer in charge of the PLC program working with you? Changing the multicast option to unicast would diminish the traffic to the HMI. The robots are Fanuc and I am sure their product supports unicast. It is a minor change and this will cause no issue to the PLC's performance. Only if there is a redundant scanner one would need multicast. For most applications this is not used.

If you can get the trace with a tap the filter is shown below, for your reference, would show the HMI traffic. Here of course you will not see HMI traffic

ip.src == 192.168.0.2 || ip.dst == 192.168.0.2

 

[AlfredoQuintero]

I want to qualify the above further. The multicast traffic does not seem that bad. If the RPI was, say 1 msec you would see thousands of packets per second, not a few dozen. At this moment I lfe's statement in post #9 sounds plausible.
So, I do not want it to sound that if you hook-up a managed switch the problem will be over.
Having said that, having a managed switch does have advantages, such as being able to use port-mirroring, in which case you would not need an Ethernet tap for the Wireshark capture because you could get the trace from the mirroring port, using the port for the HMI as the mirrored port.
Anyways, having the traffic to and from the HMI would be useful, but with the information available at the moment it does not seem that you have a network problem.

 

[Cheeseface]

Multicast is not your problem, ordinarily I would doubt your switch is the problem either. Buy some of these temperature stickers and see how hot it's getting.

There's no way three, most likely 100-mbit, devices are overloading a switch.

ed: Also, check the ethernet error counters, you could have something wrong at layer 1.

 

[drbitboy]

My two cents: I have found that some consumer-grade unmanaged switches experience what a friend of mine calls "bit-rot." I think the switch firmware has some memory leaks, but memory is cheap and plentiful, and the leaks occur at rare edge conditions, so it takes some weeks or months before the switch starts to run out of memory and the performance degrads. Usually a power cycle clears it. Putting better firmware (e.g. the from the open-source OpenWrt project, if possible) into the switch is one solution. Getting a better switch is another.

Whether this is the source of the problem for this thread is anybody's guess; again, this is only my two cents.