I don't have a direct solution, but it would be very useful to find out exactly what the problem is here.
Let's assume that your "device" is not running LabVIEW (e.g. RT), just the PC side. Is this correct? It is not entirely clear what's going on, so I have some troubleshooting tips. I suspect that the "device" is not closing the connection properly, leaving the PC e.g. in one of the FIN-WAIT or CLOSE-WAIT states. (Of course power cycling one side will definitely not close the connection properly, leaving the connection hanging. The FIN-WAIT-2 timeout is about 5 minutes, I think). For more information on the terminology, see section 3.2 of <a href=http://www.faqs.org/rfcs/rfc793.html><b>RFC793</a></b>. What is the device? Maybe it's quite primitive and has a faulty/incomplete TCP/IP implementation, e.g. a "lite" version with some details missing or buggy. (1) Once the problem occurs, go to a command prompt and type "netstat -an" and search for the connection involving the ports of your LabVIEW application. What is the connection state? (2) Hook up a packet sniffer and record the packet exchange during connection closing. (e.g. <a href="http://www.ethereal.com/";><b>Ethereal</b></a>) (3) How reliable is the connection? Do you have a lot of packet loss and retransmissions? (4) Do you run any kind of personal firewall software on the PC? Interestingly, the "close connection.vi" has an "abort" terminal that, according to the online help, is "reserved for future use". Maybe this will allow to RST the connection immediately in future versions? Most likely, you don't need to wire a local port for the "tcp open connection.vi". In this case the OS will choose a random ephemeral port and you won't have any conflicts. (Do you know if the device insists on a certain source port for incoming connections?) You still need to troubleshoot the issues for the server port used in TCP-listen.
