Refnum is No Longer Valid

[OmarGator]

Since my original post we have found just as 'mbn123' found, that we would have to exit and completely unload LabVIEW to complete the disconnect from the .net driver.

The .net driver in used to communicate over Ethernet via data sockets and it seemed the .net driver was not disconnecting after the .net close was issued. Either the .net driver was not getting the message or something else.

The 3rd party .net developer added a data socket disconnect to the .net driver for me. Now I have to call the disconnect function right before before the close function. I works now for me. Not sure just who's fault it is.

[mbn123]

I have tried to device a simple program that illustrated my problem. The real project I am working on is not a good example. I only succeed in showing the same effect as OmarGator, when this thread was started. I suspect I need something more elaborate than a single-property .net component.

Included in the .zip file is some vb.net and a subdirectory "lv project" which includes the labview code. The FunctionalGlobal.vi cannot be run twice, but the FunctionalGlobalTest.vi works as intended. No errorhandling or shutdown code is included, otherwise it would be a nice example of .net and labview.

[tst]

Your attachment is corrupt (only 1 KB), but it shouldn't really matter, because as explained, the effect seeing in the original post is by design - when the top level VI in a hierarchy goes idle, all the refnums created during the run of that hierarchy are garbage collected.

[Neil.Pate]

>> The simple (and correct) solution is not to call the functional global by itself, but only to call it as a subVI.

tst, please can you provide some clarification on what you mean here?

The functional global is a sub vi surely? Do you mean it should be one level further down inside another sub vi?

If you have a main VI (assuming a state-machine type architecture)  with functionals (possibly containing refnums) scattered in the various states, surely there is no chance of them being garbage collected by LV?

[tst]

When you press the run arrow inside the FG itself, it is the top level VI and when it stops, the reference will no longer be valid, and that was my understanding of what was originally described. If you are calling it from another VI, you should be fine, as long the top level VI is still in memory.

This does get complicated if you have more than one top level VI where you load and unload the VIs into memory, but as long as you have a simple application, the garbage collection is only done when the top level VI stops.

It seems that I may have misunderstood the original post, because Omar says that this works for other kinds of references which is not entirely accurate. It can work for references like control references, because they are still in memory, but it should not work for dynamically called VIs, TCP Connections, etc.

[Neil.Pate]

Right, thats pretty much what I thought. Thanks for clarifying though.

[Lycangeek]

I know I'm pretty late to this discussion, but I just started checking devzone again...ah, the drinking from the firehose at a new job 🙂

Let me throw out a few bits of info to see if any of it helps...

1. As of LV 8, the refnums go invalid when all the VIs in a LV Project context go idle - not just in a call chain. One trick I would often do is create a little VI with a for loop and a timer to sit and run quietly in the corner...I probably should have used events or something more clever, but I was always better at .NET than LV *grin*. Either way, that prevented the shutdown.

2. For clarification, it's not so much the gc as the AppDomain. Think of an AppDomain as a LV Project context, but more so. You actually create a .NET AppDomain for each project context whenever you run a VI - that is the space in which all the .NET code runs during the VI execution. When the last VI in the project context goes idle, we destroy the AppDomain. This is why things like static members of .NET classes get reinitialized when you run the VI again.

3. This feature - a new AppDomain each time - exposes many bugs in .NET code. Most .NET code doesn't handle shutdown correctly. They are used to the fact that for 99% of the people, when the AppDomain is destroyed, the entire process is going away. Surprise - LV doesn't require that! Thus the driver code is very confused when it is brought back to life in the same process. Basically you've run into one of the key differences between LabVIEW and .NET programming environments. It's one of LabVIEW's strengths in my opinion, but does make interop with other worlds a bit tricky.

4. The WinForm control is an entire other basket of fish. The WinForm controls behave very similar to the rest of .NET, but they also have their own master in the .NET world, and it's called Win32. Unlike most of the .NET code called in LabVIEW, WinForms can begin running code that was started by the Win32 UI system - and which LV doesn't see. I can't explain in specifics what you are seeing as I don't really have LV anymore, and definately not the code, but problems with the controls are often very specific to the .NET control implementation - not saying the bug is always in their code, just that debugging these problems is generally a case-by-case issue.

[tst]

Brian, I was wondering what was going on, since you've been quite for a few months (I assumed MS would have as much interesting stuff to write about as NI)...

Welcome back.

[Lycangeek]

Thanks tst - yes, a lot of interesting stuff...however, I'm working on a release that is still quite a ways out so we haven't released any information publically yet. I'm looking forward to the day when I can start blogging about it though.

[samwarr12]

I'm having the same issue.  I have to restart once the VI closes.  I have tried to package it as a subVI and call it but I get the same symptoms.  I'd love to solve the root problem but if someone has figured out a "band-aid" fix, I'd be interested.

I am using a .NET call to talk to a USB lab camera (Clearshot II).  To make things more frustrating, if I disconnect (or power down) my lab camera then Labview will crash.  I'm not sure if it's related to the Refnum problem though.  Any thoughts?