Refnum is No Longer Valid

[OmarGator]

I am trying to use "Functional Globals" to set up a device driver for a device via a .net driver.

 

The VI in its init state calls the Constructor Node, but the next time the VI is called the .net Refnum is No Longer Valid from the uninitialized shift register.

 

Screen shot 1:Run the VI the first time and get a valid .net reference.

 

Screen shot 2:Run the VI a 2nd time and the uninitialized shift register still contains the pointer to 0x81C00001, but the Refnum is No Longer Valid. 

 

This technique of using uninitialized shift register work for other type of references. It seems that LabView is "helping" me out by clearing my reference when the VI exits.

We had a simular problem with DACmx that is solved by a low level setting telling LabView not to clear refnum on it's on but wait for the close command. Is there also something like that for .net?

 

Thanks

 


Shot1.JPG:
Loading Image...


Shot2.JPG:
Loading Image...

[tst]

OmarGator wrote:



It seems that LabView is "helping" me out by clearing my reference when the VI exits.


Yes, that's correct. When the top level VI in the hierarchy which opened a reference goes idle or out of memory, LabVIEW does garbage collection and closes all open references. The simple (and correct) solution is not to call the functional global by itself, but only to call it as a subVI. Another option is to run it dynamically as a seperate process so that it stays in memory, but that is too complicated.
I don't know the setting you mentioned, but I wouldn't rely on that anyway. There is a setting like that for VISA, but I don't know of one for DAQmx.

[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.

[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.

[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?
 

[mbn123]

The solution I ended up using, is the one suggested by MikePorter.
 
I stopped using the abort button, and instead i created a stop button in the top vi, that initiates a proper shutdown sequence.
This shutdown sequence includes a refnum close on the .net refnum. This makes it possible for me to restart the labview program without exiting.
 
NI says that it will be fixed in labview 8.5.
 
Hope it helps.

[mbn123]

I have the same problem as described, i.e. a functional global with a .net refnum.
 
I do use it as a sub vi and it works as intended as long as the program is not stopped. Naturally, it is stopped often when I develop my code :-)
 
To me, the problem is that I have to exit labview completely (including the friendly "getting started" menu), before I am allowed to reinitialise my .net controls.
 
Is there a work-around as to how I may reinitialise the .net control without exiting labview?
Are there any tweaking possibilities for the garbage collection? Might be dangerous, but it would be useful during debugging.

[tst]

mbn123 wrote:

the problem is that I have to exit labview completely before I am allowed to reinitialise my .net controls.


What do you mean by that?
I never had a problem in calling a constructor of a DLL I used previously. In my experience, the only time you need to exit LV is when you want to replace the DLL, and that's because LV keeps a reference to it.
Can you post a simple example demonstrating your problem with exact explanations?
P.S. I use LV 7.0, where embedded .NET controls were not available, so I don't really know about those if that's what you're using.

[mbn123]

tst wrote:




mbn123 wrote:

the problem is that I have to exit labview completely before I am allowed to reinitialise my .net controls.


What do you mean by that?



I haven't tested it completely, but it seems that labview (8.2) handles .net exceptions badly sometimes.
I have succeeded in starting and stopping my labview application, without corrupting the .net object. But most of the time, it is unable to load the object (showing a square around an empty control).  When I exit labview, it (sometimes) gives me an error arising in DotNetDomain.cpp and, at next startup, offers to investigate the error.
The .net controls are fairly buggy, as they are in active development, and I suspect that they fail in a way that is incompatible with labview. I use exceptions in my .net code, and labview reports it properly, but apparently it is not enough.
In my oppinion, it is a bug in labview 8.2. It may be circumvented by proper .net coding, but it is annoying during development.


tst wrote:

I never had a problem in calling a constructor of a DLL I used previously. In my experience, the only time you need to exit LV is when you want to replace the DLL, and that's because LV keeps a reference to it.
Can you post a simple example demonstrating your problem with exact explanations?
P.S. I use LV 7.0, where embedded .NET controls were not available, so I don't really know about those if that's what you're using.


The first construction of the .net object of not an issue. The "exit labview" part is annoying, but helps avoid other problems.
I am currently converting vb6 activeX component to vb.net, and once you get a handle on how to handle property and method return values, it works nicely. You have easy access to methods and properties. I have never liked ActiveX components, so I recomment the transition.

[mbn123]

mikeporter wrote:Are closing all the .net references before you stop your application? If so, then I would agree that it's a LV problem. If on the other hand you are simply punching the abort button you are creating the problem yourself. Even when doing development, you should stop code in an orderly manner whenever possible.Mike...



I think you are right. Following your earlier remark about uninitialised references, I looked briefly at checking the validity of my .net refnums, but I didn't suceed.
So, how do I check for uninitialised refs and how do I close my .net references?

[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.
 


LV.net bug.zip:
http://forums.ni.com/attachments/ni/170/260826/1/LV.net bug.zip