Networking issues, and am curious about Produce/Consume versus MSG: (Allen Bradley PLCs)

[Russ]

I have a client who periodically experiences network communication issues. Sometimes when I VPN into the site, their SCADA systems will flash comm loss alarms, and they won't get updates on their screens from the two plant compressors. However, when they were starting up the plant (and these 700hp compressors were off, or running at low speed) I had no trouble connecting and doing a lot of programming through VPN.

The main plant plc is a 1769-32E. When I did some basic diagnostics I noticed the processor was sending 13 messages, and had a peak of 17. A few other processors also execute a couple of MSG arguments.

In speaking with Rockwell, they suspect that one/both of the ethernet cables by the compressors could be getting noise from the motors' current loads, which could be affecting comms.


Is there a way to verify this?


Would there be any benefit to using Produce & Consume tags in place of the MSG arguments? The MSG argumetns are set up for each of the main pieces of equipment. A lot of them could be replaced fairly easily with P&C. But I'm not sure how much this would benefit the client.

 

[OkiePC]

The main advantages of MSG instructions are that they can be added or edited while running, and that you have more programmatic control over their execution.

The main advantages of P&C are that they can be made to operate transparently and don't require any logic (and associated debugging) to operate. The main disadvantage is that they cannot be added in RUN mode.

I don't think P&C is going to help with a noise issue on the media, but fiber optic cables in place of copper should.

 

[Ken Roach]

This is a neat discussion ! Sometimes we get asked to resolve problems with media, noise, voltage, or physical damage via software, with varying degrees of success.

Has actual rebooting/power cycle to the controllers been ruled out ? You can put a simple runtime counter or timer in the controller that resets on first-scan, or use the Uptime indicator on the embedded webpage as a good way of telling when the power actually has gone down.

The port object for any A-B controller will have some hardware statistics. These can be examined inside the controller itself, or browsed via the webserver, or logged into a SCADA system so you can look at when the error counters increment and when they don't. Similar functions are often available from managed network switches via SNMP protocol.

In general, Produced/Consumed Tags time out if the Consumer doesn't see a new sequence-incremented packet within 4x the RPI. They tear down and restart automatically, so that might be faster than whatever connection timeouts are configured (like the 30 second default unconnected timeout) or are programmed (setting the .TO bit if the .DN bit doesn't come on soon enough) for MSG instructions.

This sounds like a fine opportunity to examine the network and see what its mix of managed switches is, and look at a network management system, whether commercial or open-source or DIY.