I have been using TCP listen to link up with another computer for data transfer - all is working quite well. So now I go to move on to build an executable for the final target and behold - no more TCP listen functionality using the exe.
Has anyone seen this before - it is a simple TCP listen on port 5000 with a 10mS timeout - it takes about 5 seconds to attach during development execution, but it seems to not see the request at all when in the executable. It seems there is a difference between the devleopment and exe environment when running the VI.
Also worthwhile noting - I have built a very simple VI with only the TCP listen and a few indicators, all works well using both the development and exe of that simple VI. My main program is not very complicated, but obviously complicated enough to shut down the TCP listen funcitonality. I have been able to prove that TCP listen is indeed running - producing error code 56 when it times out, but it will not connect for some reason.
It may be that there is a critical timing issue with TCP listen, but I can not seem to figure it out.
I can't think of anything off the top of my head that would affect an executable but not a VI running in the development environment. Are you trying this on the same computer? Are you using the same port numbers in all cases?
You might try a utility from a very useful website called www.sysinternals.com called TCPView. It should give you a list of all TCP connections open or waiting for connections, as well as the processes that own them. It might help with the debugging so you get a better view of what's happening.
The application is running on the same computer with no changes to the port settings, or any other input to TCP Listen. The only thing that is different is it has been compiled into the executable, and will not work in the executable state. TCP Listen does respond with error code 56 when it times out during operation for both the development and executable situations. I have also been sucessful with a small VI containing TCP Listen in both the development and executable environments. My guess right now is it is a timing issue - I am trying everthing to get it to respond, but no luck thus far.