Dear All - Hope this helps somebody.

When I reported to work this AM I was immediately paged to one of our packaging machines. The HMI was obviously not communicating with the PLC. My Laptop coudl access the PLC and see the logic executing. It could likewise RADMIN control the HMI PC. I'd seen this issue once before and it was a Coms Server Lockup I was told by the engineer who designed the machine.

"Reboot the PC and all will be well"

LOL HA HA LOL

After rebooting I could not RADMIN the PC, but it had an IP address and all lights on the NIC looked ok. The PLC was still available just fine. A couple of hours later when out IS Department showed up the "fixed" the machine by turning off Symantec Firewall which had been turned on during the reboot. They can't explain why, but I thought it was fun.

Psh - typical. That livened up my day

They "fixed" a control pc by turning off the firewall???

They couldn't open the ports for that specific application???

RADMIN uses TCP port 4899 by default, it was probably blocked by Symantec. An exception rule woud have probably done the trick.

That would imply they understood controls PLCs and the ports used to talk to one. Good luck there.

As a followup I have had problems with OPC drivers exhibiting similar symptoms as well as DDE. Seems that after a lot of arguments back and forth between several different software vendors the upshot is overflowing Windows buffers. With OPC it's mostly a problem when you are polling a disconnected device. If you close your OPC connection and re-open it (or DDE for that matter), this will fix the problem when it happens.

I have had this problem off and on with RS-Linx as the OPC driver. Turns out that they have one of those "hidden" points that tells you if the device is available (online). So if you can set up two separate connections, then use one only to monitor the device available information. Use the second to do real communication. If the device becomes unavailable, close the second connection. Reopen when the device becomes available again.

Keep in mind that one of the worst design features of COM/DCOM is dynamic port allocation. I'm not sure what it's really called, but it chooses random ports to communicate over a wide range. They can't work with a reasonably configured firewall. This is why such calls across the network are a big security no-no. OPC tunnellers solve the problem in such applications.

That's why at my place, process controls people take care of the process PC's.

Sounds like your IS department needs an overhaul. In the civilian world I am a control systems engineer, and we are part of the IS department. Don't assume that IS personnel everywhere have no idea what a PLC is.

As I said, I am an engineer in the civilian world. Right now I am in Iraq supporting a large chunk of a windows domain. For me, PLCs and PCs are basically the same (they just have different peripherals). I take pride in the fact that I can support any system I may come across regardless of its intended use or design.

If anyone would like a little education on PC/PLC security this is a good place to start. As our industries evolve, the line between control system and computer system fade.