Dear Forum,

I am working at a Gas Processing Plant which is running Emerson Delta Distributed Control System (DCS). The Control System is communicating with over 24 3rd party Packages in the field over Modbus TCP/IP using its VIM Module. We have implemented redundant communication with most of the packages so we have a primary switch and a secondary switch. We are facing a communication issue regarding an Over Head Compressor (using Rockwell Allen Bradley PLC) and Instrument Air Compressor by CAPS Australia running XE Controller (Dedicated Controller). The issue is that when the Over Head Compressor is plugged into the VIM Network (Network in which all 24 3rd Party Packages are plugged), the Instrument Air Compressor **stops communicating**. We can't even ping the compressor. At times the Instrument Air Compressor does reply but with TTL of over 30ms. When OVHD Compressor is plugged out, Instrument Air Compressor resumes communication.

I have attached wire shark capture of the network with and without over head compressor. When the OVHD Compressor is plugged in, the capture shows heavy traffic being generated by its PLC (IP address 192.168.1.60). Another physical observation is that before the OVHD Compressor is plugged in the VIM Network, the NTRON Switch (Ethernet Switch) in OVHD Compressor panel shows static lights, unlike lights of a normal healthy network. When the OVHD Compressor is plugged into the VIM Network, all the lights of switches in VIM Network which were blinking previously also become static. Do the static lights mean that the network is being choked due to heavy traffic?

Below are links for the Capture, IP Scheme and Architecture of Over Head Compressor.

https://www.dropbox.com/sh/ar7ss8zzoo96g37/AAADguRpUDtdOnmN3xQX-Wlpa?dl=0

Please also note that OVHD Compressor is using following IPs
192.168.1.59 PLC (Internal PLC IP)
192.168.1.60 PLC (Internal PLC IP)
192.168.1.61 HMI (Internal PLC IP)
192.168.1.62 RedLion device for DCS Communication

I would really appreciate if anyone would help me trouble shoot this issue.

 

I didn't look at your traces, however one thing to consider ANY time you have higher-end AB Ethernet products is make sure your switch is IGMP capable. AB products can literally multicast up to 10000 packets per second (these are the Class D range like 239.x.x.x). The problem is that many lower-end products treat multicast like broadcast. So as each of those packets shows up, it is placed into the device's Enet ring-buffer, then the CPU looks at it, discarding it - the CPU ends up 100% saturated and your function stops. Older Ethernet MAC had very poor multicast (or logical address) filtering, so enabling a single Class D IP allows in 108,000 undesired IP.

If this is your problem, this actually has nothing to do with Modbus - is a side effect of other protocols. For example, many small devices allow multicast as a cheap way to 'find my device'. So if the makers has some utility which magically finds the device with (or without) a valid IP, then they may have enabled multicast in the device. If this is the case, see if the device in question can turn off the 'auto-find', which will disable multicast receipt & prevent the CPU saturation. So the dying device with stop dying.

Anyway, what happens with a fancier IGMP-enabled switch, is it can block all multicast to a specific port UNLESS the device asks to see that traffic. This would protect your device *IF* it properly issues the IGMP request for only the Class D address it wants. If it is so cheap/low-end that it doesn't issue that request, then even the fancy switch will likely allow ALL class D through, solving nothing.

 

Thanks a lot for your help. We disabled "Supervisor Mode" in the Ethernet Card settings and now the behaviour of the system is normal. The lights of the switches are blinking and the over head compressor not pinging is pinging and giving data on modbus.