I have a TCP message sender in it's own loop. The rest of the program runs and queues messages for the messaging loop to send. Every once in awhile (1-2 days of run time) I'll notice the messages aren't coming anymore. When I try and shut down the application using a FGV, the messaging loop doesn't stop (everything else does). When I open it to see what's happening I can see it was attempting to Open a TCP connection. The abort button or close eventualy cause a popup saying LabVIEW is reseting the VI and I have to kill LabVIEW in task manager.
My question really is no matter how the code is put together, shouldn't I get an error out so I can handle it, or figure out how to fix the issue? I can't open the TCP Open vi to see what's up. Is it a windows thing? I know I've had issues trying to reach network drives that disappear in windows. If exploerer locks up trying to reach the drive, LabVIEW will also.
On the off chance that it's something in your code, why don't you post the VI (or VIs) that illustrate the problem? Note that you need to post actual VIs, so we can examine and test them (very hard to execute a JPG image).
Are you sure to close all network refnums properly after you are done using them? This includes not only connection refnums you open explicitedly though TCP Open, but also refnums that you receive through a TCP Wait on Listener as well as the listener refnum itself. You may deplete the local TCP/IP ports which are limited to 64k only. As long as the refnum is not closed the underlaying socket will be kept alive and that will also use up the port number to which it is (implicitedly) bound.
LabVIEW only attempts to automagically close any left open refnums after the top-level VI in whose hierarchy the refnum was created (opened), has returned to idle state (fully stopped executing).
I'll check make sure they are. Still would be nice to get an error, rather than lock up. But your idea could explain why it's takes awhile before it happens. 64K is a lot though.