How to reserve a VI

[lordsathish]

Hi Ppl,

I'm trying to reserve a VI for execution. I couldn't find any property/method that does it, in VIServer. LabVIEW ActiveX does expose a method to reserve the VI.

But my problem is how to keep the VI in memory even after the VI that opened the reference stops running. I was wondering how TestStand does this. TS loads VI's into memory and reserves them. If TS used some code that open's these VI's ref, after that code stops these VI's should go out of memory. But that doesn't seem to happen.

[GregR]

Typically a VI is reserved by either being run as a top level VI, having a strict VI reference opened or having one of the first 2 done to one of its callers (recursively up the VI hierarchy). In the case of ActiveX, we don't really have a concept of strict references, so we explicitly expose reservation.

However reservation has nothing to do with keeping a VI in memory. TestStand does control VI lifetime through references. They open the references from TestStand itself so they are in control of when they close those references.

The issue you are having is related to the automatic cleanup of references when a top level VI finishes running. Even if we did expose reservation of references through the VI server, your reference would still be cleaned up and the VI might be unloaded. There are a couple of options.

• You either have to change how your code operates such that the VI that opens the reference does not stop running.
  
  • This might mean making a UI where the user can repeatedly press your button to do something rather than having the VI complete and the user hit run again.
    
  • Or it could mean starting up a separate VI in the background that opens the reference and keeps running until you are really done.
    

  [*]If the VI you're loading is meant to stay running, then you can use the "Auto Dispose Ref" option on the Run method. This will cause the reference to stay open as long as the VI you called Run on is running. (The cleanup happens at the end of the VI you called Run on instead of the VI you called Open from.)

[asbo]

• You either have to change how your code operates such that the VI that opens the reference does not stop running.
  
  • This might mean making a UI where the user can repeatedly press your button to do something rather than having the VI complete and the user hit run again
    

I had to approach this problem last week (I was searching for a text string in a folder of VIs which didn't have an easy ancestor to force them all into memory) and used the method GregR mentions about keeping the UI running. It was brain-dead simple for me, just a blocking event structure while I ran LabVIEW's normal Find tool so LV wouldn't try to cleanup all the references. I didn't realize that it would do so, even if I didn't close the references AND left them in an USR, which is a horrible realization after spending 5 minutes loading several thousand VIs...

[lordsathish]

GregR & asbo, thanks for your responses.

TestStand does control VI lifetime through references. They open the references from TestStand itself so they are in control of when they close those references.

TestStand doesn't seem to be keeping a VI running to keep the VI's loaded. Does that mean that, if you are using a C#/.net application that opens the VI reference through LabVIEW ActiveX, your VI reference will be valid as long as the thread that opened it is running ?

[GregR]

This is not really a question of the LabVIEW ActiveX interface but really a feature of the language used to call the open reference. In LabVIEW, references are closed when the top level VI stops running (in most cases). Even if you used the LabVIEW ActiveX interface to open a VI reference, that reference would be closed when the VI stops running. This is not because it is a VI reference, but because LabVIEW closes the ActiveX reference.

In C or C++, references are only closed by the user explicitly closing. TestStand is written in C++ so this is the case they are in.

C# uses garbage collection so a reference would stay open as long as something still remembers the reference. This could be equal to a thread being running if the reference is stored on that thread's stack but more frequently it is independent of threads. It is usually about a method returning which allows its locals to be collected or a static data structure whose value contains the reference.