Open VI Reference

I have built an application with LabVIEW 7.1 and I randomly get Open VI Reference errors whey I dynamically load VIs. The application I created loops on a series of VIs, dynamically loaded them as they are called. The problem is that I randomly get the Open VI Reference errors even after executing a series of evens for 85 times. That means the dynamically load vi worked 85 times prior to getting an error.
Attachments:
Error 1124.jpg ‏202 KB

I think it will be impossible to help you without seeing your code, but I would start with some code that will document what happens when this error occurs (what path you're using to call the VI and so on). That will make it much easier for you to troubleshoot.
Additionally, you can try searching this site for the error. If you go to the top of the page and put 1124 in the search box, you will get several results (like this, for example).
Try to take over the world!

Similar Messages

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

"Open Vi Reference" generates a Error 7

Hello,
I am getting "Error 7" from the "Open VI Reference" vi, the name of the vi is wired vi path input. The "Error 7" means that the vi cannot be found. So I went to "Tools ===> Options ===> Paths" and modified the Path so that Labview can find it. But for reasons I do not understand the vi I want to get a reference for cannot be found. So it leads me to beleive that the "Open vi Reference" does not use the path option to find a vi. Any ideas what is going on?
Regards,
Kaspar
Solved!
Go to Solution.

Hello,
Thanks for getting back to me. I have attached a file fo the screenshot of the Block diagram. The "Open Vi Reference" is in the upper left hand corner, which generates a error when I have updated the path options to point to where the file exists.
Regards,
Kaspar
Attachments:
vi_error.GIF ‏21 KB

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

Open vi reference error

Hi all,
I am using LabVIEW 2011 SP1. I am running such a vi which is calling another vi by selecting a boolean button. After opening the new vi, the previous vi will stay opened but being minimized and the new vi will stay maximized untill user forces to close the new vi. All the operations are going successful at the start. But if we keep running it for 12-13hrs, then an error is coming in open vi reference of the previous vi and the previous vi becomes maximized and above the new vi. I have attached the error message herewith. Please give me a solution.
Attachments:
error.txt ‏1 KB

Error 2 is a memory full error. If you right-click on the error cluster you can select "Explain Error". The most likely reason is that you are not closing your references properly, or you are not closing them at all. It could also be something else, such as continously building an array until you run out of memory. Without seeing some code it's impossible to say what the real cause is. If you cannot post your code then you will need to look at your code to see whether you are auto-disposing the VI references. If you are not, then you are responsible for closing them. If it's not a reference issue, then you should use the performance tools to monitor the memory usage of your VIs to see which one is causing unbounded increased memory usage.

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

LabVIEW 8.6.1 Project causes slow Open VI Reference

I have an odd problem with "Open VI Reference.vi".
Case 1.
Open LabVIEW project containing "Main.vi"
Open "Main.vi"
Run "Main.vi"
Execution of "Open VI Reference.vi" take about 2,000ms
Case 2.
Open "Main.vi" - No LabVIEW project open
Run "Main.vi"
Execution of "Open VI Reference.vi" take about 100ms
I converted the project to 8.5 and the problem goes away. I don't have any machines with 8.6.0 to test if this is an issue with 8.6.1 only.
Has anybody else seen something like this?
Solved!
Go to Solution.

Good catch on the type def. It turns out that this is also key to the problem. I cleaned up my example VIs, removed the Type Defs and OpenG VIs. When I ran the cleaned up VIs the problem went away. So, I added a simple type def back to my called VI and the problem was back.
You misunderstand the reason for including gmath into the project. This has nothing to do with the time to load the project from disk. The problem is slow execution of "Open VI Reference.vi" when opening VIs that contain TypeDefs that are in large projects. By including gmath I was able to create a large project without attaching extra VIs.
Open Reference Test - No Project: 11 ms
Open Reference Test - small Project: 105 ms
Open Reference Test - large Project: 753 ms
Code in Zip file is LV2009
Message Edited by Gleichman on 08-21-2009 06:36 PM
Attachments:
Open Ref Test - II.zip ‏62 KB

Does "Open Vi Reference" work differently in 8.5 if a string input is wired to vi path?

SO I was reading the upgrade notes to labview 8.5 and I noticed a change in the "Open VI Reference" function. In 8.2 you can simply wire a string of the vi name to the vi path input of the function, and labview will open a reference to the vi already in memory. But in 8.5 the relative paths have to be the same.
So say I have a vi in memory called window.vi. Its real path is C:\test\window.vi. And let's say its already in memory and its reentrant so I can call it by vi server. I used to be able to just pass a sting containing "window.vi" to the vi path input of "Open VI Reference." I like to do that because I already know the vi is in memory, and it is a big pain to get all the relative paths right between developement and deployed executable. This way I don't have to worry about getting dozens of relative paths right for a bunch of support vi's when I build an installer. Does this mean if I upgrade to labview 8.5 I'll have to change this every single place I did it and then rebuild every installer to include support vi's with relative paths to the exe that are the same as their relative paths to the main vi in the development environment?
-Devin
I got 99 problems but 8.6 ain't one.

Well thank god for that. It is too bad the upgrade notes give no mention of how this impacts the executable environment, since it certainly seems like the executable the biggest and most likely part of the impact. I bet you'll still have a ton of people with relative paths that are wrong in the installed executable but right in development environment. Previously they would have worked even though the relative paths were wrong, but now you'll see errors. By the way, what will happen if they have a relative path in the development environment but in the installed executable they compiled all their vi's into a single exe. Will it error? Do they have to rebuild with those vi's included as support files?
tst,
Check out the notes. I don't know if there is enough there to understand or misunderstand, but I get nervous when they say stuff like this.
Open VI Reference Function
In LabVIEW 8.0.x and 8.2.x, if the name of the VI from the vi path input
matches the name of a VI in memory on that target, LabVIEW returns a
reference to the VI in memory and LabVIEW does not load the VI specified
in the vi path input. In LabVIEW 8.5, if the name of the VI from the vi path
input matches the name of a VI in memory on that target but the paths
differ, the Open VI Reference function returns an error.
Message Edited by billings11 on 09-05-2007 01:01 PM
-Devin
I got 99 problems but 8.6 ain't one.

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

Why does "open vi reference" wait for "mouse up"?

Hello,
I need to dynamically load a reentrant subvi as soon as the user hit's a button. I'm using an event structure which I dynamically register for processing a "value change" event. Inside the even structure I placed an "open vi reference" vi. I set it's options to "8" to prepare the subvi for reentrant run and the program steps into the event case as expected. The problem is, that "open vi reference" doesn't execute before the mouse button is released.
Is there any possibility to get "open vi reference" to execute while the mouse button is still pressed? (lock front panel... is disabled, "mouse down" event doesn't work either, static vi reference is not possible because I need several instances of the subvi).
Any idea would be welcome.
Thanks in advance,
C. Halbgewachs

There is something strange here, that has the smell of a bug...
The mouse down event is detected as soon as the event occurs, but the corresponding case is NOT processed entirely if the mouse button is kept pressed.
Most operations are immediately executed, EXCEPT the Open vi ref, or the File dialog vi, and probably some others...
For the File Dialog, this is normal, since a dialog window has to be opened (interaction with the operator) while the operator is still acting on the button.
But that's not normal for the Open vi ref.
First I thought that this hads something to do with file management or disk access. Wrong : Files are opened and read immediately.
The attached vi demonstrate this strange behaviour.
Enjoy !
Chilly Charly (aka CC)
E-List Master - Kudos glutton - Press the yellow button on the left...
Attachments:
Event Bug ?.vi.zip ‏19 KB

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

VI Server - Open VI Reference is using local path, not remote

First time posting to NI Developer Zone, so bear with me.
I have a PXI-1050 chassis with a PXI-8187 controller that runs LabView RT. I have set up this PXI system to utilize a VI server on port 3363 and opened access to my host PC which runs LabView 8.2 with the RT module.
I am having trouble openning a remote VI using the VI Server and the "Open VI Reference" function. I am fairly certain that the VI server is connecting using the "Open Application Reference" function, but it seems that the vi I wish to run cannot be found.
Here is the error that is thrown back to me
"Error 7
Possible reason(s):
LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux. Verify that the path is correct using the command prompt or file explorer.
=========================
NI-488: Non-existent board.
VI Path: D:\LabView_Projects\VI_Server_Test_Project\/ni-rt/startup/temp_1.vi"
You will notice that the "Open VI Reference" is prepending the local path 'D:\LabView_Projects\VI_Server_Test_Project\' to my remote path. If I specify the path using Windows style path, e.g. 'c:\ni-rt\startup\temp_1.vi', again the remote VI cannot be found. I think I am missing something trivial, but I don't know what it is.
Thoughts?

Several things:
1. When u open the vi reference u must use and invoke node to make the Run vi, if you dont make it the vi is loaded but not running.
2. Insert correctly the path on your RT and the IP of your RT target
3. is better to have the variables on your HOST than on your RT becoz of two things:
- Not to use resources of your RT system as memory etc... is better to use the host ones that are more available
- The library needs to be deployed when running the vi on the host. If you put it on the RT it would need to be redeployed, so it is better to leave it on the host becoz of that.
4. Then as the library is on the host it needs to be deployed with the proper invoke node inside a stacked sequence to ensure is the first thing you do.
5. The enable RT fifo on the variables is used only to pass data between different vi's or processes inside the RT, it has no sense to enable it when sharing data RT - Host coz it is not possible, Shared variable work with TCP/IP not as RT FIFO.
See the attached vi for extra info.
I give u these extra links for your info:
http://digital.ni.com/public.nsf/websearch/F4010DD5C8D1B13D862565BC007384E9?OpenDocument
http://digital.ni.com/public.nsf/websearch/04D9A85B6967EE87862571140065EEC6?OpenDocument
http://digital.ni.com/public.nsf/websearch/48D244EC86971D3986256BD4005CCC28?OpenDocument
Regards,
Jaime Cabrera
NI Applications Engineering Spain
Attachments:
Compartida.zip ‏66 KB

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 conversion from Labview 6 to Labview 2014

Is there a way that someone can help me convert this VI written in Labview 6.1 so that I can work en EXE in Labview 2014.
I succed to open this vi from 6.1 to 2014 but it does not run. The open vi reference those not work in exe program. Someone know how I can replace that function...
Thanks!
Solved!
Go to Solution.
Attachments:
to convert 2104.zip ‏17 KB

Error 7 is File Not Found. So your dynamically called VI is not in your executable.
In the build spec for the executable in your project, there is a section for "Source Files". On of the options for the VIs is "Always Include".
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Open VI Reference Function won't execute in multi process application

I have a sub vi with Reentrant execution, and it has
recursive call on some cases.
It is very similar to OpenG VI “Read Key
(Variant)__ogtk.vi”, my sub vi works without any problem unit LabVIEW’s Two
Button Dialog is opened in other process loop.
I have attached a Test VI, and would like to understand why
would Loop 1’s Dialog box have any execution impact on Loop 2’s process?
Why Open VI Reference Function won’t execute when Two Button
Dialog is opened in other process?
LabVIEW version 8.6
Thanks,
Attachments:
Test Vi.zip ‏17 KB

Broken Arrow wrote:
LabVIEW's native dialog box is Modal. It will not let anything else run which requires (or MAY require) user input. In the case of your code, LabVIEW can't open a VI with a modal process going.
Broken Arrow thanks for your reply, but not sure if I understand Modal dialog box would cause the problem.
I already had a work around by using Three Button Dialog VI, and it is s Modal VI.
I would still like to understand, why would DataFlow halt at Open VI Reference Function in Loop 2 when I use when Two Button Dialog?
Attachments:
Test Vi 2.zip ‏20 KB

Open VI Reference

Similar Messages

Maybe you are looking for