Labview TCP listening port on control PC is closed by third party dll

[KVO]

Dear All,

I am facing a issue with TCP port on LV 2011. In my Main application, i have multiple TCP connection with multiple instruments.For one of the instruments(X), i am suing a its X instrument dll using CALL library function, to establish a tcp connection with instrument. After execution of task i close the connection to this instrument(X), using a shutdown.dll provided. But after few runs of task, shutdown.dll closes all listening ports of Labview, including the default labview tcp listening port. Unfortunately

Consequence is, After closing of all TCP connections, no connection to other TCP based instruments is possible.

Only solution is to close complete Labview and restart from the begining. Form TCPIP View software i monitored the behaviour of TCP connections. After using all Labview based TCP are not presnet. Hence onyl way was to close complete Labiew and restart over again.

i really need help and your suggestions, how i can avoid this perticular situation.

Thanks in advance

[mikeporter]

So I'm not clear:

• Does the instrument you are talking to have its own dll for communicating with it?
• What is the instrument you are trying to use?
• Can you post your code that is talking to the instrument, or at least a subset that shows the problem?

Mike...

[KVO]

Hi Mike,

Yes instrument(communication Tester) has its own C++ dlls provided by its manufacturer. And I am using a API to open and close TCP communication using its propreitary APIs.

 while other instruments are switch Box using VISA over TCP.

The code to communicate to communication tester is just a call library function to execute and API.

[mikeporter]

Well the first thing to check is whether you are calling the proprietary DLL correctly. If the vendor has sample code available in other languages it would at least demonstrate the correct calls to make.

Mike...

[rolfk]

Another culprit is likely that the DLL calls into the Windows functions WSAStartup() and WSACleanup(). While this is necessary to be called in a process that wants to use Windows sockets in any way, LabVIEW already calls these functions at startup and exit itself.

WSACleanup() will release the Winsock DLL, effectively making it unavailable for LabVIEW. So your fix would be to not call any function that might internally call WSACleanup(). Maybe your Close() function maintains a list of open sockets and calls WSACleanup() automatically when no connection is open anymore. Or you actually do call a specific function to shutdown your DLL. In either case you have to delay the call to any of these functions until you are really ready to close your app.

Better yet would be if your DLL provides a means to tell it not to call WSAStartup() and WSACleanup() at all since the calling process has done that already.

[KVO]

Hi,

Oh WSAStartup() and WSACleanup() sounds quite plausible. I read details on MSDN that WSACleanup terminates all sockets.

"An application must call the WSACleanup function for every successful time the WSAStartup function is called. This means, for example, that if an application calls WSAStartup three times, it must call WSACleanup three times. The first two calls to WSACleanup do nothing except decrement an internal counter; the final WSACleanup call for the task does all necessary resource deallocation for the task."

this above sentence also explains, why after FEW successful use of thirdparty shutdown function, Labivew port dissapers. Communication tester has an initializaion APIs for each of its five dlls, necessary for complete initializaion of communication tester.

As a workaround, can i explicitly evoke WSAstartup() using call library node function in my MAIN Application, to keep counter higher so that final WSACleanup do not deallocate resources?

Many thanks,

Kutbuddin