Compactlogix I/O not responding over Wi-Fi

[SimonAllard]

Hi to everyone,

I am using a compactlogix 1769-L35E Rev 13.34 with 8 remote i/o racks. All of the communications is done via wi-fi using the local enb ethernet port to 1794-AENT modules.

We are using Prosoft RLX2 industrial hotspots. Everything works just fine except that we sometimes lose one of the remote racks from anytime between 2 secs to X minutes. What is weird is that if i do a PING on the ip adresses of the remote rack i get a response from the Remote AENT module but when i look online in the I/O config of the rslogix 5000 project i see my module as not responding. I have been running the 5000 task monitor for a few days and from what i can tell everything seems fine. The cpu usage % is at 35% steady and in the module tab the % of cpu usage of the ethernet module is at 20%.

Just to clarify, it is not always the same module that is not responding. It seems to be random. I have tried increasing the Overhead time slice from 40% to up to 80% without any improvement.

Most of the time doing a power reboot on the remote module solves the problem but as you can imagine it is not ideal. This is a crane system for an aerospace company so the acces to the remote racks is 50 feets above the ground and when a plane is attached to the crane we cannot always have acces to the module.

Any idea as to what might cause the Master Plc to stop communicating with one of the module even tho the network path seem fine as i can ping the module?

I know the firmware revision 13 is old but i am always a bit scared before flashing a plc. especially doing huge jumps in revisions. I know a lot has changed at around rev 16 so if u guys believe this is the most possible issue i might try that but i would love other ideas to try

Thx in advance

 

[Ken Roach]

At a minimum you should be using Wireshark and a WiSpy spectrum sniffer to figure out the signal conditions and network health.

WiFi always drops packets. ALWAYS. Your design needs to account for that, which is why I never use wireless for I/O. This includes commercial aircraft final assembly machines: the remote devices get their own controller, not an I/O rack.

Are you using multicast or unicast connections to the 1794-AENT modules ? If it's multicast, you might be overloading some of your access points with traffic that doesn't need to travel over them.

There is just no substitute for network protocol analysis when you're chasing this sort of problem.

 

[The Plc Kid]

As Ken said make sure you design your system to deal with packet loss as it will happen.

Also if you are using V13 then default is multicast and if you are not using managed switches with IGMP snooping you will have issues with packet flooding on your devices.

The other things to consider are your average signal strength, Point to point distance and RPI.

I have several systems using wireless Logix based I/O with no issues ever but it's something that has to be done right and cross your I's and dot your T"s.

Also make sure the wireless gear is only being used for that piece of equipment or line. Don't do wireless I/O over plant networks, etc. it needs to be a dedicated wires network for comms and I/O on that specific line or machine.

 

[mk42]

Simon,

I can't comment much on how to fix it from the logix side. I'm surprised that the connection doesn't automatically reset, so perhaps the firmware upgrade might help.

On the wireless side, however, I am a little more knowledgeable. Ken is definitely correct. Standard wireless is sometimes wacky. Going to local controllers can be one way to avoid the impact to your system, or at least give you a buffer.

I've seen wireless systems that run so smoothly that they are used for safety IO, but you have to do the planning in advance, and make sure you have the right equipment. The most important part of any wireless system is doing a proper site survey before it is installed, to allow you to design a system that does what you need but avoids the interference. You need to make sure that the channels you are using are not used anywhere else in the vicinity. If you treat a wireless system as just a simple replacement for an Ethernet cable, you will probably not have much success.

For overhead cranes, I typically see either directional antennas going down the whole bay, or leaky coax cable built into the structure. These allow you to minimize access points while maximizing the gain in the direction you want it.

The only experience i've had with the Prosoft equipment is when I was going in to replace it with Siemens wireless equipment, because the prosoft stuff was having random dropouts, and they had to power cycle to get communication back again. Since the Siemens Scalance equipment went in, things seem to be much more stable. They seem to have had had a slightly a different problem, though. It was the wireless client that was unresponsive, not the IO system.

 

[SimonAllard]

Thx for the quick replys,

I know this isnt ideal to work with wifi for such sensible equipement. I am a subcontractor and am stuck with the system as it is right now. The network system is standalone and have no interactions with the rest of the plant.

We have had a company come in and do a full analisys of all the wireless trafic in the plant and maybe go with dedicated frequency hotspots so they dont come in conflict with other equipements. We are still waiting on the results and their propositions so i was looking for quick fixes untill we can make permanent and more durable modifications.

The thing that bugs me the most tho is that i can ping my AENT module but the compactlogix wont re-establish the communication with it so i will first try to upgrade the firmware since its the easiest thing to do. I have already upgraded the firmware of the Prosoft hotspot without any improvement.

About unicast Vs multicast, i am not familiar with those setting and i have no idea how to set these. I have looked in the AENT module properties and also the Local ENB port but dont see the option. Any help on how to modify this setting would be appreciated.

Thx again

 

[KuulKuum]

This site might help you further troubleshoot your issues.
It is not specific to a wireless network, hope it helps.

http://plcview.blogspot.com/2011/01/troubleshooting-ethernetip-system.html

 

[Firejo]

There is a difference between being able to ping a device and making a UDP connection to it. The device isn’t gone, it’s just dropped the connection and either can’t reset it or it’s taking a long time.
The best you can do with what you’ve got (in my opinion) is set your RPI times as high as your application can handle and hope it’s enough. Ideally what you should do is put in processors at each one of the I/O spots so all you’re doing is TCP messaging which is much more tolerant to dropped packets. The other option is a “protocol to I/O” type device where you’re messaging to the master unit via EtherNet/IP and it’s communicating to remotes that are I/O devices. It removes the need for a PLC at each I/O location but gives you the robustness of message instructions.
http://www.data-linc.com/cixfamily/cix6400.htm