Allen Bradley/Flexy 205 catastrophe

I have a 4g Flexy 205 using a verizon sim, which is supposed to talk to a 1769-L33ERMS safety controller. When the PLC is connected to any LAN port on the flexy, the entire LAN network craps out. When we unplug the PLC, comms to other devices on the network are restored. Initially the connection was just so slow it literally took an hour for a 20 rung routine to open while online, however comms with the rest of the devices on the network were great and we could even ping the PLC with a very fast 150 ms response. After exhausting all other options we tried setting the gateway address on the PLC to the address of the Flexy. This caused the Flexy to just stop talking. Even the VPN connection was broken. Not even comms to the other devices which we had a connection to. Now with the PLC unplugged we can talk to the other devices, but once the PLC is plugged back in, the whole network crashes. Total Memory in the processor is 2,097,152 bytes Used: 644,048 Available: 1,453,104. Could the memory which RSLinx uses be an issue? Any ideas? Anyone?????

Welcome to the PLCTalk forum community !

Make sure that your I/O connections, especially the Safety ones, are configured for Multicast instead of Unicast. Many routers cannot handle large amounts of multicast traffic and choke just trying to filter it out.

If you're using Multicast on purpose (like with multi-Consumer tag sharing) then a managed switch properly configured for IGMP Snooping is essential.

Are you using a managed switch to connect to the system ? Any chance you've accidentally configured the router's port to be a "mirror port" ?

Ken!!!!! I was hoping for your response. Just to be clear, do you mean use Multicast config for safety I/O? Our current configuration is using Unicast for all Safety I/O, tag sharing, VFD, and AENT modules. We are using an Unmanaged stratix 2000 switch. I honestly cant find an option for port mirroring in the router setup. Thanks again for your response!

An unmanaged switch means that there's no risk of having a mirror port enabled, and that the switch can't help you with constraining multicast traffic. So it's imperative that you don't have any multicast traffic that you don't need.

Connect up to the network with your computer running Wireshark; multicast traffic will be immediately apparent.

I'm basing my comments on the theory that the router can't handle the traffic it's seeing. I literally destroyed a LinkSys router once by exposing it to multicast traffic; it must have tried to handle it by writing to some part of nonvolatile memory, or it just red-lighted in despair.

It appears housekeeping is the culprit, Ken. After investigating the produced tags used in our project, it turns out that we have 500 bytes worth of data being sent over the wire that's not even being used by the consumer. Is it possible for our controller to contain the produced tags, but the consumer controller to have had the consumed tags removed?

You can certainly have Produced tags defined and no Consumers on the network, but the data should not be actually transmitted until there's a Consumer to establish a connection and negotiate the RPI rate.

Thanks, Ken. Your extensive knowledge has been extremely helpful. I've been in touch with an integrator who has been on site working on the SCADA system. Apparently the produced tags which were in question do not exist in his controller as a consumed tag, however consumed tags do exist in our controller that do not exist in his controller as produced tags. I was running a wireshark while connected through the router at the beginning of all of this. That is until i got kicked off the network. I did notice many errors being transmitted. It almost sorta kinda reminded me of a DLR beacon being transmitted during a ring fault. Should I expect to see this given the absence of the produced tag? If not what should i expect?