07-13-2023 08:53 AM - edited 07-13-2023 09:05 AM
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.
07-13-2023 09:22 AM
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.
07-14-2023 01:35 PM
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.