Quirk, Open VI Reference and LLB

I found a strange quirk opening a VI Reference (on a PXI). The "normal" method of doing this is to Open Application Reference (to find the remote site) then to Open VI Reference with the path to the desired VI. Darren Nattinger pointed out (in 2006) that you can use just the name of the VI, provided the VI is on the same folder or LLB as the current VI.
Caveat -- this behavior is present in LabVIEW 7.0 (I'm maintaining some "legacy code"). I suspect it will be present in later versions, but haven't (yet) tested it.
Quirk 1 -- if the VI in question has been downloaded (or deployed) to the remote site, and hence is in memory, then the "path" information isn't used, only the VI name. Thus if you have a path "C:\ni-rt\startup\MyVI.vi" specified in the Open VI Reference, but have absolutely nothing in the startup folder on your PXI, but have "deployed" your Project, this call will work, even though the "path" part of the argument is not valid. Useful when testing.
Quirk 2 (and the "real" reason for this post) -- if the VI is embedded in an LLB, it depends on whether or not it is a "Top-level" VI or not. Suppose the path is C:\ni-rt\startup\MyLib.llb\MyVI.vi. Consider two VIs in this LLB -- TopLevel.vi and SubVI.vi (where TopLevel is at the top level of the LLB, whereas SubVI is not).
Case A -- the LLB has actually been downloaded to the remote site. Doing an Open VI Reference, with either the full path or just the VI name, works, whether or not you are calling TopLevel or SubVI. Nothing surprising here.
Case B -- you are taking advantage of Quirk 1, and have not actually put the file on the Remote site (i.e. there is nothing at the path specified). You have, however, downloaded the LLB to the Remote. Doing an Open VI Reference with SubVI, whether with full path or just VI name, works fine. However, trying to open TopLevel fails, with Error 7 (File Not Found), whether using full path or VI name.
Summary -- Quirk 2 is that Quirk 1 has a quirk if the VI being referenced is a top level VI in an LLB.
[My apologies if this is common knowledge -- I failed to find this behavior documented, but may have overlooked something].

Bob Schor wrote:
I found a strange quirk opening a VI Reference (on a PXI). The "normal" method of doing this is to Open Application Reference (to find the remote site) then to Open VI Reference with the path to the desired VI. Darren Nattinger pointed out (in 2006) that you can use just the name of the VI, provided the VI is on the same folder or LLB as the current VI.
Caveat -- this behavior is present in LabVIEW 7.0 (I'm maintaining some "legacy code"). I suspect it will be present in later versions, but haven't (yet) tested it.
Quirk 1 -- if the VI in question has been downloaded (or deployed) to the remote site, and hence is in memory, then the "path" information isn't used, only the VI name. Thus if you have a path "C:\ni-rt\startup\MyVI.vi" specified in the Open VI Reference, but have absolutely nothing in the startup folder on your PXI, but have "deployed" your Project, this call will work, even though the "path" part of the argument is not valid. Useful when testing.
Quirk 2 (and the "real" reason for this post) -- if the VI is embedded in an LLB, it depends on whether or not it is a "Top-level" VI or not. Suppose the path is C:\ni-rt\startup\MyLib.llb\MyVI.vi. Consider two VIs in this LLB -- TopLevel.vi and SubVI.vi (where TopLevel is at the top level of the LLB, whereas SubVI is not).
Case A -- the LLB has actually been downloaded to the remote site. Doing an Open VI Reference, with either the full path or just the VI name, works, whether or not you are calling TopLevel or SubVI. Nothing surprising here.
Case B -- you are taking advantage of Quirk 1, and have not actually put the file on the Remote site (i.e. there is nothing at the path specified). You have, however, downloaded the LLB to the Remote. Doing an Open VI Reference with SubVI, whether with full path or just VI name, works fine. However, trying to open TopLevel fails, with Error 7 (File Not Found), whether using full path or VI name.
Summary -- Quirk 2 is that Quirk 1 has a quirk if the VI being referenced is a top level VI in an LLB.
[My apologies if this is common knowledge -- I failed to find this behavior documented, but may have overlooked something].
This will likely not apply at all to >= 8.0. LabVIEWs Open VI Reference will now distinguish cleanly between absolute path and just the VI name itself. If you use just the VI name the VI needs to be in memory or for a built application included in the app. The quirk about VIs in the same LLB as the currently active VI sounds very strange to me but it may still work.
However if you specify an absolute path, Open VI Reference will bark with an error if the VI can not be found at that location or if the VI already loaded in memory with that name has not the same absolute path. This is supposedly to make it very hard to create cross linking even when using VI server.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

Open VI Reference and Stand-Alone

Hi!
Using LabView 7.1 under XP I made a vi which creates a report in Excel format.
The vi runs correctly but, If I do a Stand-Alone application of that vi, an error 7
(problem occured at Open VI Reference in New Report.vi) appears when I launch the exe. Why ?
Someone has any idea ?
Thanks

I my particular case, I only add the vi's that are dynamically called in the Source Files list of the Build Application (see attachment). I did nothing else !
On the other hand, I have Oslo observed that the "Current Vi's path" gives for example:
c:\directory1\directory2\Library.llb\viName.vi
when testing within LV while it gives
c:\directory1\directory2\Application.exe\viName.vi
when running the EXE. I have first expected to get
c:\directory1\directory2\Application.exe
when running the EXE and thought it was a bug of LV. However, there is no bug (here) and "Current Vi's path" works as described in the documentation:
"...If you build the VI into an application, this function returns the path to the VI in the application file, and treats the application file as a VI library.".
Regards,
Frédéric
Attachments:
ScreenShot.jpg ‏149 KB

Open VI reference and paths problem

Hi,
in my project I need to have a VI running independently from the calling VI so I use VI Server and "Open VI reference" to run the VI. However this is not without problems. The VI that I run is not in the same folder, as the caller VI and also not on a fixed location on disk, so I use relative paths (something like "..\subfolder\myVi.vi"). This works in the project and .exe but not e.g. in a .llb file where there seems to be no folder structure anymore.
Actually I'd prefer if this would not use paths on disk at all but if I could somehow create a reference to another VI in my project and it would even work if the VI's location on disk changed (and is updated in the project). I think it is quite confusing that I have to care about physical location of the VI here when I use the project browser for everything else. Is there a way to accomplish this? Or is there even a better way to start a VI that keeps running even after the caller stopped?
Thanks,
Tobias

As far as I've seen, every VI has the path ../Application.exe/currentvi.vi when you are running in a build. Therefore, to open another VI you have to strip the current vi's path once, and add the other vi.
I have written a VI that determines whether or not I'm running from a build, it is attached. It returns true if you're in a build, and also the current vi's path stripped once giving you ../Application.exe.
The way I use the VI is pictured below. I send the stripped path Is Executable returns and the relative path (minus the vi name) into a Select icon which is wired to the boolean Is Executable returns. Then I add the other VI name to the path.
Message Edited by elset191 on 04-21-2009 10:43 AM
Tim Elsey
LabVIEW 2010, 2012
Certified LabVIEW Architect
Attachments:
Is executable.vi ‏8 KB
untitled.JPG ‏7 KB

Open VI Reference for a Project Library VI

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:
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:
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!
Solved!
Go to Solution.

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!!

Using Open VI Reference to run a VI, on an RT target, with sub-VIs not loaded

I've been using Open VI Reference and Call By Reference Node to remotely run VIs on my RT controller. I
usually wire string data to the vi path input, but this
requires the VI to be in memory. I understand (from LabVIEW help) that I can wire a path to this terminal and specify a VI that is
not in memory, but is on the disk. NI has an example that
confirms my understanding. I get errors when I attempt to do the same
with VIs that have sub-VIs; I suspect that the problem is that
the sub-VIs aren't in memory and that the top-level vi doesn't know where to
look for them (because the paths aren't specified). All of the sub-VIs are on the RT system (in the same directory), they're just not in memory.
Is there a way to get LabVIEW to look for sub-VIs on the disk? I don't want to rely on using a startup application and rebooting to get my VIs into memory.
Thank you,
Jim Carmody
Software Engineer
G2 Technologies
www.g2tek.com
Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice

Hi Jim,
It sounds like you are going about calling VIs remotely the correct way. It would be very helpful if you could post the errors you are receiving. I also wanted to know if you saw the note at the bottom of the article that says your VI library must contain everything your top level VI calls.
Eric A.
National Instruments
Distributed I/O Product Support Engineer

Open VI Reference LAN Help

Hi!
I have a LAN/TCP connection. On the side A, I have a simple VI, and I would like to call it from side B. How can I do that?
+++ In God we believe, in Trance we Trust +++
[Hungary]

Hi Durnek,
The best is to use the Application Control palette, create a VI server on side A, on side B open a reference to the VI server with Open Application Reference Function, then you can access the VI with Open VI Reference and using the Invoke and Property nodes from the same palette you have access to a lot of information and settings.
Let us know if you have more questions!
Have a good day!
Patricia

Open vi reference slow

Hi,
I have developed a packed library *.lvlibp with a few analysis vis which shell be called dynamically by an external exe. I call this vis via the open vi reference. Unfortunately this call (wait until exit of vi) takes very long. My test shows that when I call this vi via the vi-ref it takes 33 seconds - with integration into the external application via sub-vi only 400ms. Is there a way to accelerate this dynamic call? The values to the vi ref are set/get via the control-value attributes.
Any hints are appreciated.
Best Regards,
Joachim

Hi Joachim!
Maybe your vi is simply taking 33s to be loaded.
Try the following:
- embed your analysis vi in the main vi, in a section of code that is NEVER executed (e.g. FALSE case of a case structure, with a constant TRUE wired to it)
- try again to use "open vi reference" and check if this time is "quicker" (since the vi should be already loaded).
Regards,
Marco

Open VI Reference Error 1000

Here is the problem:
I am opening a VI (we will call SubVI) through "Open VI Reference" and running the VI in parallel with the VI (MainVI) that I am opening it from. When I run the MainVI using "Run when Opened", I get a Error 1000 and the SubVI freezes. I break out using ctrl-period. Then I start it up from within LabVIEW and the Error 1000 does not appear. Does anyone have an idea of what is going on? Thanks.

I'm a bit unclear as to what your setup is. I suggest you post an example which will help clear it.
As a guess, error 1000 means "The VI is not in a state compatible with this operation". If the subVI is the one set to be run when opened, maybe calling it dynamically is what causes the problem.
Try to take over the world!

How can I open a vi and show the block diagram?

Hi,
I am opening an vi using "Open VI Reference" and "Invoke Methodpen FP", but I want to open the vi and show the block diagram, but I haven´t found any method (Invoke Method) to do that and any property.
Any idea?
Thanks!
Gracinda

OK, I can come up with a reason. I have written a program that will search the entire VI Hierarchy of a program and update all of the descriptions for all VIs with the top level program part #, the name of the top level program that the VI is used in, the company copyright info, the ITAR notice, company address, the name of the engineer performing the update, along with the date and time. This will also place as a background image on all the VIs, a watermark of the company name, legality stuff and the copyright. It works very slick in that if there are thousands of sub-vis, such as what I'm working on now, it goes through all of them, makes sure the data is there as per company policy without having to open every one of them look at them and update or not whichever the case may be. The one portion that is tough is that the program will detect if there is a description written about what funtion the VI performs and if there is not a description, then it pops up a dialog requesting the user to write a description. The problem is that without looking at the block diagram for the VI, it can be nearly impossible to write a description for the functionality of the VI. So is there a way to programmatically open a VI, show its block diagram (this would only be in the case of a missing description) and then upon completion of the updates, close the block diagram? (I already open and close the VI programmatically in order to read the VI DESC and update as needed, but that is in the background and of course you can't see the block diagram).
Thanks,
Dan

Error 1003 occurred at Open VI Reference in Dist Copy Non-VI Files.vi- Dist Build LLB Image.vi- Dist Build App Image.vi- Build Application.vi

When trying to build an application using labview 7.1 and windows XP, I get the error
Error 1003 occurred at Open VI Reference in Dist Copy Non-VI Files.vi->Dist Build LLB Image.vi->Dist Build App Image.vi->Build Application.vi
I've tried the crtl-shift-run as well as a mass compile and I still get the error.
Any ideas?
Thanks,
Mike

Hopefully this thread, or this KB article might help.
It seems like this could come from a lot of things, but there's suggestions in those which might lead you in the right direction
Message Edited by Day on 09-22-2006 02:07 PM

Open VI reference for VITs and VIs

Hi
I have a VIT and I get the reference using the Open VI reference. When I change (rename) this back to a VI, and get the reference for it, its much faster. Does the open VI reference takes longer for VITs than VIs in obtaining a reference?
Another question is the same VIT, takes lesser time to get the reference using the Open VI reference in LabVIEW 8.5.1. It takes longer in LV8.6. Why is this happening?
Thanks
Vaa San.

The two main differences between a VI and a VIT are that VITs are never run, but are templates that generate a VI instance immediately that has all the properties, attributes and limitations of a VI. A VI on the other hand has only one instance (unless you make it reentrant)
· A VI generated by a VIT is debuggable just like a VI in that you can trace the execution along the wires. In general, a VIT creates a copy of the VI in memory when you open a reference to it. Creating that copy takes time, which affects performance when doing recursion. That copy is then a standard VI in every sense, except it is not a file. Also, if you don't close these references, they will take up space in your RAM. Reentrant VIs can currently only do real recursion in 8.5 and if they are part of a class. If you open a VIT, you don't open the actual file, but a clone. This way you can open it multiple times. Each time you open it, you get a clone. This is especially useful when you open the VIT with VI Server. VIT's are useful to make an interface window once, and use it multiple times in your program. If the code should run multiple times, but doesn't have a user interface, use reentrant VI’s instead. As far as having the project open, a VI will reload all instances related to the project therefore causing the Vi to load slower. Best Regards,
Juan Galindo
Applications Engineer
National Instruments

I have a VI A. I want A to call another VI B and execute. After B executes, I want it to close automatically and go back to A. Is this possible ? I tried using open reference and those methods, but I am not able to do it. Can someone help me ? Thanks !

Thanks !
Kudos always welcome for helpful posts

Re: I have a VI A. I want A to call another VI B and execute. After B executes, I want it to close automatically and go back to A. Is this possible ? I tried using open reference and those methods, but I am not able to do it. Can someone help me ? Thanks !Hi Stephan ! Thanks ! I guess I explained my question not so right. I've created a customized menu and at the instance of me selecting a menu, a VI should load itself dynamically. I am using call by reference. Sometimes it works and sometimes it won't. In short, what I want to achieve is load VIs dynamically and close them dynamically once they finish executing. Thanks !
Kudos always welcome for helpful posts

Error 7 occurred at open vi reference in New Report.VI

Hello!
I use the report generation toolkit on LabView 7.0 to create a report in Excel. The program works fine until I make an executable version. I the get the error:
Error 7 occurred at open vi reference in New Report.VI
I use the New Report.VI, Bring Excel to front.VI and Save Report To File.vi
Can you pleace help me!!!

Most likely, you did not include the required libraries in your build script. When building an executable in which you use the Report Generation Toolkit, you must include the _Word Dynamic VIs.vi from _wordsub.llb and _Excel Dynamic VIs.vi from _exclsub.llb as dynamic VIs on the Source Files tab.
Check this article for more info.
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/86256a47004e16d186256a84004cb883?OpenDocument
Daniel L. Press
PrimeTest Corp.
www.primetest.com

Open VI Reference Error in the executable version only

Hello folks! I am having a strange issue since I updated to Labview 2014: I have a vi that uses "Open VI Reference" in order to programmatically open the desired vi. It worked flawless also in the compiled version (.exe) of the program until yesterday, when i compiled it again for the first time since my update to Labview 2014. It compiles with no problem, but when i start the exe and load the first vi it already gives me an error "Built Application or Shared Library (DLL): Missing".
The point is that all the VIs that i want to open are inside an LLB that is supposed to be compiled inside the .exe: infact the path that i use to open is:
D:\LabVIEW Data\builds\Sequenzer\Sequenzer2.0.exe\com_lv_sequenzer\trunk\Sequenzer_Functions.llb\Seq_Connect_to_Database.vi
And i get error number 7:
Open VI Reference in Seq_Function_Interface.vi->Sequenzer_Main_2.0.vi<APPEND>
VI Path: <b>D:\LabVIEW Data\builds\Sequenzer\Sequenzer2.0.exe\com_lv_sequenzer\trunk\Sequenzer_Functions.llb\Seq_Connect_to_Database.vi</b>
Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library.
LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets.
The vi Seq_Connect_to_Database.vi is included in my built (as you can see in the attached screenshot and as it has always been).
Do you have an idea of why it is not working anymore?
Thanks a lot in advance!
Dario Cassaniti
Solved!
Go to Solution.
Attachments:
sequenzer.png ‏86 KB

OK, here is where I am confused. You talk about including the llb in the build, but in the screen shot you show a bunch of individual VIs being included. Next, in source file settings where are you telling the app builder to store all those individual VIs? Because they are VIs LabVIEW will, by default, want to put them in the executable somewhere.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Vi path in "open VI reference" function

how do I specify a vi in a vi library when using the "open VI reference" function.
thank you very much

You can think of a library as a directory
So the path would be C:\MyFolder\MyLibrary.llb\MYVI.vi
If you are using either a path constant or control you can set the browse options so that the file dialog will allow you do browse into libraries and select the VI. Right click on the control and select Browse Options. You can then select existing file (use LLBs).

Quirk, Open VI Reference and LLB

Similar Messages

Maybe you are looking for