Can a single LW/CVI 4.0.1 app act as both a TCP server and client?

[jkurkjian]

I have an embedded application that receives command messages on one TCP port and responds with data messages on a second TCP port.

I wrote a LabWindows app to act as a test station for the end-product. When the test software is configured to transmit messages only (ignoring responses) as a client, my end-product receives 100% of the messages. When the test software is configured to receive messages only (does not issue command messages), 100% of end-product transmissions are received.

So far, so good, but now comes the fun part...

The test software is supposed to transmit a message on the command (or uplink) port and then listen for the response on the data (or downlink) port.

As part of the test software initialization, I register the test software as a TCP server using RegisterTCPServer and connect to the end-product using ConnectToTCPServer for downlink data.

I have two TCP CVI callback functions, one for uplinks and one for downlinks.

Uplink messages are sent using ClientTCPWrite. Downlink messages are handled via the TCP downlink callback function and ServerTCPRead.

When the test software is shutdown, calls are made to UnregisterTCPServer and DisconnectFromTCPServer.

The above works great the first time a message is sent. The second time, the command message is sent, but no data is received.

I have fairly well exhausted the possibilities of this being an end-product problem. So, now I am wondering if LabWindows/CVI apps can simultaneously act as a TCP client and server.

Thoughts?

[Scott Y]

Hello,

There should not be any fundamental reason why you cannot have a client and server in the same CVI application. However, I am not sure how to explain the behavior you describe, where the first message gets through, but after that the program is unresponsive.

Have you tried breaking the client and server into separate applications to verify that each has been implemented correctly? You might consider returning dummy responses in the case that the communications on the server port needs to have an impact on the client port.

Scott Y
NI

[RobertoBozzolo]

My experience is somewhat different from your application so it's not exactly portable to your problem, but anyway...

Some years ago I was developing a communication between two programs in CVI. I don't remember which version of CVI I was using and surely I had only one port, with one program acting as a server and the second as the client, but I found that if I had breakpoints in the tcp callbacks to debug the application all messages after the program was break down were lost, as if the communication were automatically closed (by whom? I never discovered it!). I solved my problem by launching messageboxes to see messages as they were caught by the callbacks and after that the communication proceeded regularly.

Maybe this can make some sense to you...

[jkurkjian]

Thanks for the input.

After further troubleshooting, there was a problem in the timeouts set with CVI as well as in my target app. Problem has since been resolved with the CVI app being fully capable of being a client and a server, concurrently.

Thanks for the help,
John