I have had many go-rounds with VX Works and how it handles the TCP communications. As to why communicaions do not come back when the TCP thread gets re-enabled, I can't answer, however I have seen that behavior myself on a couple of systems I did about 2 years ago. The best way I could describe it was when the TCP thread was suspended something happened to connection between VX Works and LabVIEW RT.
As far as my client computer was concerned, the TCP socket was still open. The client could send data to the RT controller and not receive any sending errors.
On the LVRT side, the TCP read functions never returned an error, but also never returned any more data after the TCP thread was resumed. It was as though the link between VX Works and LVRT was partially broken as no further data was passed, but the conections still indicated open and good.
Due to the design of the RT program I was not able to test if the RT side had the ability to send data out in this condition.
My solution, although it was not much in the way of fixing the problem, was to modify other areas of my code to preclude high CPU demand and thus prevent the TCP thread from being suspended. As long as the thread remained active, my application worked fine.
I worked with one AE and even the PSE at trying to duplicate the behavior, but was never successful. It seemed sporadic at best, sometimes the connection would restore fine, other times it would come back in this partially broken state.
Greg Sussman
Sr Business Manager A/D/G BU
