LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP error 62

Solved!
Go to solution

I read that also on lavag.org. But how to circumvent?

The only alternative would be to close the socket in the main VI and re-open in the sub VI. However, there is a call chain. The caller VIs may or may not go idle. The sub VI that does the actual TCP write/read is not supposed to open and close the socket every time it's called as this is not you work with sockets, plus the local port might run out.

   

By the way, this only happens with TCP Write as it uses a refnum. Other interfaces use different types of connection IDs. I have COM here and EtherCAT - no problem at all.  

0 Kudos
Message 11 of 13
(250 Views)

We thought this through. The main VI calls the sub VI dynamically, but then goes back into a loop. The sub VI also runs a loop, calling other sub VI upon events. So actually no VI goes idle.

0 Kudos
Message 12 of 13
(245 Views)

You may have thought this through very thoroughly, but it still does not invalidate what I said!

 

Your Start Call.vi opens a connection and then it opens the Write.vi and starts it asynchronously passing it the connection ID. Then it closes the VI reference and terminates! And this termination causes LabVIEW to auto collect, aka close, all refnums created during the execution of the Start Call.vi, even if that would have happened 200 levels deep in a subVI.

 

If you have no delay in the Write.vi, it MAY execute before the Start Call.vi had time to terminate (but there are no guarantees of any sort either for that).

 

To fix this you have two options:

 

1) Make the write VI be executed synchronously

2) Make the Start Call.vi wait for some signalling from the Write.vi to have finished with the connection refnum, before letting it terminate.

 

 

Rolf Kalbermatter
My Blog
0 Kudos
Message 13 of 13
(211 Views)