I have a rather puzzling problem. I have created an application that uses a Modbus interface. After it start it launches many processes including a Modbus TCP Slave process built largely from the NI Modbus TCP library. I have a second application, used for testing Modbus. It can either launch a Modbus Slave process or a Modbus Master process. It is important to note that the Modbus Slave code is exactly the same in both applications. I have built applications for both. (Port 502 used for all connections mentioned below)
To test, I install the main application on the industrial PC it is intended to run on, and I install the Modbus Test application on my laptop. I run the main application which launches the Modbus TCP Slave, then I run the test application on my laptop and launch the Modbus Master process. They connect successfully, and can communicate back and for without issue.
Next, I install my application on a physically identical machine on the other side of the ocean, and I install the test application on a laptop located in the same lab, on the same network. I run the same test and they do not connect. Suspecting network issues, all settings were thoroughly checked and appear to be good. To troubleshoot a 3rd party Modbus Slave tool is installed on the industrial PC, and the same test application Master is run on the laptop, and they connect and can communicate without any problems. So we know the network connection is good.
Next test... I install my test application on the industrial PC and run the Modbus Slave process (which uses the exact same code that is used in the main application that I am trying to get to work), and I run the test tool with the Master process on the laptop as before, and they connect! This is so puzzling. The code is exactly the same in both application, but one works and the other doesn't. It is as if there is something in the main application that is preventing the TCP Listener from accessing the port. The listener runs in a loop and has a 3 second timeout. I also send a message to a log file every time the loop runs, and I can see these messages in the log file exactly every 3 seconds. So I know the listener is running and there are no errors, other than the timeout.
Next test... run both the main application and the test application Master on the industrial PC (Master set to connect to the local IP), and that works! So the main application can connect through port 502, just not if the Master is remote. But other applications can connect to a remote Master over 502, so the port is clearly not being blocked.
Next test... I run both the main application and the test application Slave on the industrial PC's... so two slaves on the same port... shouldn't work, but I'm out of good ideas. Run the test Master on the laptop, and as expected neither connected. But then it occurred to me that I started the main application first, then the test application Slave. So I repeated the test starting the test application Slave first, waited for it to start listening, then started the main application, then the Master on the laptop. And amazingly the master connected to the test application slave. So is seems clear that there is something going on in the main application that is blocking the port. I have checked for other instances of the TCP Wait On Listener, but none found other than two that are commented out with disable structures (some of the code in that application I inherited and lots of legacy stuff in it still). Doing a new build now with that code actually deleted, but I doubt that will matter.
But if it is the code that is the issues, why does it work on the industrial PC I have here?
I am so puzzled... anyone have any ideas?
Thanks,
John
