LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Open VI Reference for a Project Library VI

Solved!
Go to solution

Hi,

my code calls some subVIs by reference by using "Open VI Reference" and "Call by Reference" VIs. Now, "Open VI Reference" expects a path to the VI:

 

Capture.PNG

 

 

When the SubVIs sit in the same folder as the calling VI, it is easy to simply supply the name of the SubVI. However, I would like to call a SubVI that is part of a project library sitting somewhere else on the disk. I could give the relative path, but this make the code pretty inflexible and if the relative path changes all the paths would need to be ammended. Ideally, I want to utilize the fact that I am using a project library. The help for Open VI Reference states that

 

vi path accepts a string containing the name of the VI that you want to reference or a path to the VI that you want to reference. If you wire a name string, the string must match the full delimited name of a VI in memory on that target. If you wire a path, LabVIEW searches for a VI in memory that you previously loaded from that path on the same target.

 

 I thought that the underlined path was my ticket and tried something like this:

Capture.PNG

 

but this did not work and I got

"Error 1004 occurred at Open VI Reference in MainVI.vi:

Possible reason(s):
LabVIEW:  The VI is not in memory.
To load a VI into memory with the Open VI Reference function, a path must be wired for the VI Path input."

 

Wiring a path is not desirable as per reasoning above. Is there a way around the issue?

 

Thanks in advance!

0 Kudos
Message 1 of 3
(5,235 Views)
Solution
Accepted by SenSLabs

That should work, but you have to pay attention to something that's stated both in the help and in the error - if you use a string, the only way for LV to know what to access is if that something is already "in memory" (sometimes also referred to as "being loaded"). In the case of standard libraries, that means the VI itself or one of its callers has to be loaded. In the case of classes and XControls, loading the library (as in having it in an open project) should be enough to also load all of its members.

 

What I usually do is use a static reference to a VI to get its name, because that ensures that it will be statically linked, included in executables, etc. That might not work for you if you want dynamic loading and then you will need to use some other means. Something I had done in cases where I needed something like this was to have a another VI which would always be in the same folder as the VI I wanted to load and then I got a relative path from that, but that brings you back to the same problem where you might move only some of the VIs.


___________________
Try to take over the world!
Message 2 of 3
(5,216 Views)

@tst wrote:

That should work, but you have to pay attention to something that's stated both in the help and in the error - if you use a string, the only way for LV to know what to access is if that something is already "in memory" (sometimes also referred to as "being loaded"). In the case of standard libraries, that means the VI itself or one of its callers has to be loaded. In the case of classes and XControls, loading the library (as in having it in an open project) should be enough to also load all of its members.


Hm, thanks, I am not advanced enough to know about classes and XControls, but I will check it out. My VIs are part of a library but obviously don't get loaded because, as you said, all their calls are dynamic.

@tst wrote:
 

What I usually do is use a static reference to a VI to get its name, because that ensures that it will be statically linked, included in executables, etc. That might not work for you if you want dynamic loading and then you will need to use some other means.


Hm, this actually gives me an idea! I could add an enable input to all these dynamically called VIs so that the logic runs only when enable is ON; otherwise the VI is called but does nothing. Then I call the VI first statically with enable=OFF just to load it in memory and then proceed with my dynamic call. A little ad-hoc, but should work and serve my purposes, I think.
Thanks!!
0 Kudos
Message 3 of 3
(5,197 Views)