LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to call a VI by reference that is already loaded in a different application instance?

I get the feeling that there is probably a much better way to do what you are trying to do than your method.. Can you give some further details on what your end goal is? 

 

You mentioned that you want to ensure correct FGVs are used, indicating that you have already called the VI in question somewhere else in your sequence? How did you call it there? Are you calling it directly and by reference? Why?

 

 

 

0 Kudos
Message 11 of 15
(711 Views)

I don't want to waste your time going over our (legacy) design but since you ask:

The lvproj contains a bunch of drivers that are an abstraction layer to many underlying instrument drivers, e.g. the NI DMM. It also contains some FGVs, for example one gets called in the TestStand Setup section to read in a file containing a set of name <-> relay mappings, then later when you call the lvproj matrix driver you pass in the name and it looks it up in the FGV to get hold of the actual relay numbers.

So yes, earlier in the TestStand sequence at least one call (by reference presumably) to something in the lvproj has been done; the actual VI being called by my new code might or might not have been called previously but it needs access to the initialised FGVs regardless.

Probably I should just bite the bullet and put the new code in the same project, I just wanted to see if I could do something simple that would avoid that.

0 Kudos
Message 12 of 15
(706 Views)

Here's an interesting thing: if the VI I am trying to run was previously run (to completion) in the TestStand sequence I get the problem, but if it has not previously been run it works OK. It's as if TestStand somehow puts it into the "Running" state and keeps it there...

If there was an easy way to make a memory copy of the VI and run it instead that might work, but I don't think that's possible without using VI Scripting (which the runtime engine doesn't support).

0 Kudos
Message 13 of 15
(697 Views)

Following on from my last message, I have found that setting TestStand's Unload Option to "Unload after step executes" for all steps that call a VI that I might call later from my new VI fixes the problem. It seems that TestStand keeps the VI loaded and in the "Running" state unless you do this. However this is not a satisfactory workaround because it makes repeated sequence runs much slower. I think I will transfer my question to the TestStand forum to see if there is a better way to do this.

Many thanks to Intaris for your help and suggestions.

0 Kudos
Message 14 of 15
(683 Views)

I found a TestStand thread asking essentially the same question:

Unloading a module used in another sequence/sequence file

This didn't actually have a solution but does have a few clues and I managed to work out for myself what to do, which is to check whether TestStand has the VI reserved for running and, if so, tell it to unload the module before running it myself. It's not straightforward, you have to examine all steps in the sequence to see which has the VI loaded and ask the step to unload it. More details and a VI that works are in one of my posts in that thread.

0 Kudos
Message 15 of 15
(672 Views)