I have an Industrial HMI written by a third party in C++ that communicates with 36 GE PLCs via TCP/IP. The HMI is running on two different machines in the same room connected to the same switch. One HMI is running on Windows Server 2003 32 bit. The other is running on Windows 7 64 bit. There are a few PLCs to which the Windows 7 HMI can’t connect. All PLCs communicate normally on the Windows Server 2003 HMI. I’ve run Wireshark to see what’s going on.
Upon a reset of the PLC’s ethernet card, the Win7 HMI and one of the faulty bases will send a SYN/ACK sequence. Once the HMI sends data (PSH), the PLC responds with an RST packet. From that point on, any SYN packet from the Win7 HMI receives an RST response. I just set this new HMI yesterday and it’s been like this since that point. This HMI is running without a problem on other Win7 computers. As far as I know, all of the PLCs are at the same hardware/firmware revision level. I do know for a fact that the software on each of the 36 PLCs is identical.
I’m at a complete loss as to what to do to troubleshoot this further. There hasn’t been an increase in the number of connections to the PLCs as this new machine I set up yesterday is replacing one that died earlier in the week. Plus most of the other PLCs are all communicating just fine, so it doesn’t seem to be an issue with load on the PLC hardware. The C++ code is communicating to all of the bases in the exact same manner. The code just keeps an array of 36 PLC objects and loops through them when updating the information. Does anyone have any ideas on what I can do to troubleshoot this further?
It turns out that I was mistaken in my assumptions. There weren’t other HMIs running on Win7 that. I replaced the Win7 PC with an XP PC and all is well now. Will have to troubleshoot this at some point once we’re forced off of XP, but for now things are working. I expect it’s an issue in the PLC firmware since all communication from the HMI is identical.