My software talks to a motion control unit via TCP. We are running two servers:
MCU Server is at 192.168.1.220:8888
Desktop server is at 192.168.1.221:8889
My application acts as both a client and a server. As a client, it issues commands to the MCU at 220:8888, and receives confirmation of receipt on that same “channel”.
As a server, the desktop is listening for incoming messages from the MCU. This is at 221:8889. On this “channel” we get alerts from the MCU, as well as responses to queries from the desktop client.
This works perfectly but only if we follow this procedure:
- Launch my software
- Tell my software to connect with the MCU
- Power on the MCU
The MCU initializes, establishes a connection with the desktop server and begins sending alerts, and starts up its server. Once my software connects with the MCU, we are able to issue commands to the MCU, and we receive responses at the desktop server. This works exactly as we’d expect.
However, If we follow either of these procedures:
- Power on MCU
- Launch my software
- Connect with MCU
–OR–
If both servers are working properly, but we quit the Desktop application, relaunch, reconnect – while the MCU remains powered on –
…Then the desktop client can send a command and get confirmation of receipt. But we never get the report that the MCU is sending us on 221:8889, or any alerts sent by the MCU client. The connection between the Desktop server and the MCU client is now broken.
Our firmware developer says that he’s letting the MCU’s TCP stack handle reconnects, and that if the connection to the desktop server is broken, it is re-established automatically within a few seconds of the connection issue being resolved. But that doesn’t seem to be happening in practice.
Is there something I can do in Xojo, as a TCP server, to handle this broken connection and force it to re-establish it with the MCU in the above two scenarios?
Thanks.