PLC5/80C - having problem with processor hanging

Hi all! I'm having a problem with a new PLC5/80C freezing or hanging. We use ControlNet to interface with our DCS via KFC modules. We have 4 remote racks via RIO. We use an Ethernet card next to the processor for remote monitoring and programming across our company network on a VPN across a couple Cisco PIX firewalls, and we use the DF1 port on the processor for programming and monitoring locally.

The problem seems to occur when we have more than one person monitoring the logic and someone does an on-line edit via the Ethernet connection (over the VPN). We have to reset the PLC processor to get it scanning again. We use this same kind of configuration on our other 50 or so PLC5s without problem.

Changing the PLC processor does not keep the problem from occuring.

We're running SFCs in this PLC5. We've got unusually long scan time also. Initially we had scan times around 280ms. We've made some of the logic execute conditionally and the scan times are now down around 120ms most of the time. Reducing the scan time seemed to help, but we've had the PLC hang twice again this morning.

While the most obvious solution would be to stop multiple simultaneous access (and we're doing so temporarily) it doesn't really address the issue of why this is happening.

Anyone have any ideas?

A guess would be that the Cisco firewall (and perhaps other company network virus protection programs) can slow the data transmission enough to confuse the processor as to which on-line edit has priority.

A company network is NOT a good choice for PLC connections.

Advice

Let Rockwell know about this and all the particulars in your application. This is concerning and Rockwell can't imagine all the configurations we integrators/users come up with so they may not be able to explain it. Obviously it may have something to do sith the multiple protocols online at the same time. Good luck.

We're not actually doing more than one on-line edit at a time. We're seeing the problem when one user is doing an on-line edit and another is monitoring logic.

I think it's likely you are right about the lag through the PIX being a possibility. I was also concerned whether the on-line edits may use some odd packets that are blocked at the firewall by a misguided rule.

While a company network may not be the ideal choice for PLC connections, this is a monitoring and editing connection rather than a control connection. As this plant is spread out across a 160km area and 12,000 elevation difference between lowest and highest parts of the control system, it's not normally practical to send an engineer out to any given PLC to plug in locally every time we need to monitor logic, nor is it practical to have a massive network parallel to our MIS one just for access to the PLCs. The VPN (virtual private network) system has worked well for us, allowing us to have a PLC programming and monitoring network using the MIS system without having to worry about unauthorized access and unwanted traffic.

Flopro,

Thanks - I've been trying to get our guys who actually have contact with Rockwell to raise this issue with them.

We've done some testing on an off-line system running the same logic we have in the plant. So far, it looks like the VPN is the culprit (in conjunction with the long PLC scan times). Using the ethernet port without going over the VPN and using the local serial port does not cause the processor to freeze. Putting the testbed on our VPN causes failed edits and/or processor hanging. Unfortunately, identifying the VPN as the issue doesn't solve my problem as I can't put the PLCs on an open network.

Cheers,

Kevin