Allow Create Network Stream to reopen a existing reference.

[viScience]

I think this would be a good option since I have run into the problem during debug where a previously used Network Stream did not get destroyed and then when the code tries to reopen the stream you get an error that the stream is still in use.  Since the refnum is lost there is no way around this dilemma.

[reddog]

The refnum for the Network Stream Endpoint should never get lost.  The refnum and the endpoint should automatically get cleaned up when the top level VI containing the refnum goes idle even if you never destroy the endpoint within your code.  I think there are some exceptions to this if you're using VI server to dynamically launch the VI which creates the endpoint.  However, if you're seeing behavior different than this, then it's probably a bug.

[viScience]

Yes, I am using VI server on a windows HMI to call into code on my cRIO. As you suspect there are cases where the cRIO based vi that creates the Network stream fails and goes idle but does not close the reference.

[reddog]

I tried a couple of quick tests using VI server, but I wasn't able to reproduce the behavior you described unless the VI being run through VI server was a reentrant VI that never went idle.  Regardless, as a work around, you can free up the refnum by creating a VI with a refnum constant containing the correct endpoint name wired to the Destroy Endpoint VI and running it on the target.  Similarly, if you want to reuse the refnum, you can just wire a string or refnum constant containing the correct endpoint name to the Read/Write VI.

[nanocyte]

I wanted to give a quick example of the problem and reddog's workaround.

The problem is that if the developer forgets to close the reference as shown for the Reader, the reference can't get autocleaned and there's an error on the second iteration.

The reddog solution is to create a dummy refnum that you can then close (implemented in third iteration). Now, that's a pretty hacky trick and not in the normal labview reference handling practices.

I think if we want to be able to handle the "forgets" use case, we should add an input to the create primitive to optionally force close existing reference (similar to the third iteration) before attempting an open. That action, of course, would be unsafe and might unintentionally kill an existing connection.