ADCS Reference lost when calling from subpanel

[Tesla]

My Main.vi inserts VIs into a subpanel and runs them.
In the first VI that is run in that subpanel a Diagnostic Connection is created, the session ref is written to a global variable.
In the second VI that is run in that subpanel the session ref is read from global variable and used.

The reference handle or whatever is used internally seems to be lost when the first VI that creates it finishes. I get an error -8000 "Handle passed to the function is not valid" in the "sub.vi".

 

I can pass other classes like ModbusTCPMaster without any problems with this method.

 

Any ideas?

 

[hooovahh]

This sounds like the expected behavior of LabVIEW.  Many references go idle and the automatic garbage collector takes care of it, if the VI that made the reference goes idle.  I'd suggest redesigning your software to handle this in a different way.  Like maybe initializing the interface in a VI that doesn't go idle.

[Tesla]

Thanks for your input.
I will probably keep the "create" VI running (wait until done=false) and implement more functions like reconnection on error, tester present and others.

As long as that VI does not finish, everything works fine.

[ShaunR]

  On 3/24/2025 at 8:02 PM, hooovahh said:

and the automatic garbage collector takes care of it

Expand  

There is no automatic garbage collector. It's an AQ meme that he used to rage about it.

[hooovahh]

Well regardless of the reason, what I was trying to say is that references opened in a VI, get closed when the VI that opens them goes idle.

[Rolf Kalbermatter]

  On 3/25/2025 at 5:32 PM, ShaunR said:

There is no automatic garbage collector. It's an AQ meme that he used to rage about it.

Expand  

Technically it is a resource collector, but not exactly in the same way typical garbage collectors work. Normal garbage collectors work in a way where the runtime system somehow tracks variables usage at runtime by monitoring when they get out of runtime scope and then attempts to deallocate any variable that is not a value type in terms of the stack space or scope space it consumes.

The LabVIEW resource collector works in a slightly different way in that whenever a refnum gets created, it is registered together with the current top level VI in the call chain and a destroy callback with a refnum resource manager. When a top level VI stops executing, both by being aborted or simply executing its last diagram element, it informs the refnum resource manager that it goes idle, and that will then make the refnum resource manager scan its registered refnums to see if any is associated with that top level VI and if so, call its destroy callback.

So while it is technically not a garbage collector in the exact same way as what Java or .Net does, it still is for most practical purposes a garbage collector. The difference is, that a refnum can be passed to other execution hierarchies through globals and similar and as such might still be used elsewhere, so technically isn't really garbage yet.

There are three main solutions for this:

1) Don't create the refnum in an unrelated VI hierarchy to be passed to another hierarchy for use

2) If you do create it in one VI hierarchy for use in another, keep the initial hierarchy non-idle (running) until you do not need that refnum anymore anywhere.

3) If the refnum is a resource that can be named (eg. Queues, Notifiers) obtain a seperate refnum to the named resource in each hierarchy. The underlying object will stay alive for as long as at least one refnum is still valid. Each obtained refnum is an independent reference to the object and destroying one (implicit or explicit) won't destroy any of the other refnums.