Error 1003 At Open VI Reference

I'm calling a VI from a library using the Open VI Reference. The main program in an executable file. If I make a change to the *.llb and try to call it using the main program I get an error 1003 Open VI Reference is not executable. Now I've made changes to the *.llb in the past and never got this error before, but this time I can't run the *.llb anymore. What is my issue?

Are you able to call the VI in the .llb correctly right after you build the executable? In other words, do you get the error only after making changes to the VI?
As long as you don't change the name of the VI in your .llb, you should be able to make changes to it and still run it from your executable.
How are you referencing the VI from the code in the executable? Are you using the absolute or relative path? Is all of this happening on your development machine, or are you moving the executable and .llb to a different machine?
Robert Mortensen
Software Engineer
National Instruments

Similar Messages

Dynamically called VI becomes broken inside an executable. Error 1003 from "Open VI Reference".

Here's the problem. Dynamically called VI becomes broken inside an executable in debug executable mode Error 1003 is occuring from "Open VI Reference" Block. The computer has all of the necessary drivers, NI-VISA and NI-DAQmx. This executable is a new release of software that currently works on the PC in question. I can using NI-VISA Remote Server control the instruments from my PC using the executable. But when I put the executable on the PC I am getting this error. The only way I have been able to get this to work properly is to build the executable from the console I believe the project was created in, note that the project file has been moved to a network drive and it still works. All of the stations I have opened the project in show the VI that is being called is runnable. I've tried building the executable from the console I am deploying to and the same thing happens.
I am honestly at a loss for ideas why this is occuring. Is this something about the way LabView works internally that may be causing this problem?
I have trolled this forum for idea's and none have made sense to me.
Any input would be greatly appreciated.
-Nate

Two ideas:
Mass compile the project to ensure all linkages are ironed out
Include the dynamically launched VI's into the "Always Included" section of the build spec
Report back on if either of these actions solves your problem.
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

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

Error 1003 when loading a VI dynamically on LabView Run-time ini file configuration

hi all,
I have a problem with my runtime excutable.
On 4 systems, all running XP it runs fine.
On 2 systems ( one a new install of just LVRT 2011 SP1 ) I have:
Error 1003 when loading a VI dynamically on LabView Real-time
Or more spoecifically the error code is 1003 and the error source is Open VI Reference.
When the RT app runs correctly I get these paths:
Path Sent to Open Vi Reference: Yeast_Grower.exe\Tecan_talk_Control.vi,
Path Returned from Open Vi Refence: C:\Program Files\Yeast_Grower\Yeast_Grower.exe\Tecan_talk_Control.vi,
On a system that does gets the 1003 Open Vi Refence error I have the same Path Sent but of course no path returned as it does not open.
To be sure that the vi Dyanmically called vi is compiled and valid at runtime I also include a copy of in the main.vi.
To be extra sure I have also installed the runtime versions of VISA and DAQmx.
I have compiled it with and without the "Use LV 8 calling hiaracy"
My conclusion as this stage is that either the installation of LVRT 2011SP1 misses something the earlier LVRT installtions make.
or is there a MyApp.ini or LVRT .ini that controls how the RT dyanim calls are handled.
Help very welcome how to solve this puzzle.
thanks
michael

I understand that all the PCs (6 of them) have LV 2011 SP1, runtime or the development system installed. Right?
How many of these PCs have the source code available on them?
-> Only one of them has the source code.
I am not sure I understood 'I also include a copy of in the main.vi'. Does it mean you placed the subvi in the main.vi?
-> I meant I have included in main.vi the actual vi that is called dynamically - but only where it is not called.
Did you try including the sub vi which is called dynamically, as 'Always included' in the EXE build?
-> No, I did not know of this option - but the above I did this by default.
Edit: Did you verify the software versions of LV RT, VISA etc on all the PCs? Are they same?
-> I did verify even added DAQmx just in case
There is lots of material available on this forum for error 1003 and dynamic vi calling. Did you find anything useful to try among the forums threads?
-> I did view many of them.
I did finally find the answer.
I have a subvi (callNet.vi ) in the dynamically called vi (dynamic ) that calls .Net libraries.
Now the thing is that this subvi callNet.vi is coded out by enclosing it in a Disable structure.
In fact this subvi ( callNet.vi) does not even compile - ie it has a broken arrow
however if enclosed in a Disabled structure and disabled, the enclosing vi compiles OK.
However I have discovered that even with the .Net calling subvi (callNet.vi) in the Disabled state of the Disabled structure
the enclosing vi (dynamic.vi ) does NOT run - although it compiles just fine.
Once I installed the .Net libraries (I actually did include them with my app installer ) with the vender's supplied installer
then my app now successfully calls the dynamic vi.
So the Summary and warning is: Even if the dynamic called vi is included in Main.vi and Main.exe runs ( but does not call the dynamic vi - except when called dynamically at later some point ) and even if, in this case, the .Net calling subvi is disabled out ie no .Net calls are made the dynamically called vi will not run when called dynamically.
I hope that is not too confusing. In summary it seems the Disable structure does not entirely disable.
Michael

Error 1003 occured at Open VI Reference

This error occured when I want to used the LabView Report Generation Toolkit for Microsoft Office Example.
It's impossible for me to execute the example "Generate Report from Template(Excel)"
I suppose I have a problem with the Open VI Reference.vi function but I don't know where is that VI.
Could you let me know where are the VIs listed in the Application Control Pallette.
Do you know why I have this type of problem.
Thanks
Lucie

The VIs located on the application control palette are primitives and are part of LabVIEW itself. Therefore you can not look at their diagrams because they don't have one.
However the 1003 error means that you are trying to dynamically load a VI that is not executable. I would suggest turning highlight execution on and following the code to see what path is sent into the Open VI reference function.
Once you have the VI that is failing to open go manually open it.
Chances are that it is broken, so see why it is broken. If I remember correctly there is a linking issue in that example, so you can open the VI that is broken and hit ctrl-shift-Run Button, and that should relink it all and fix the issue.
If not take a look at this
Why Do I Get Error 1003 From Application Builder When I Try to Build Excel Macro Example.VI?

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

VI reference (error 1003) in executable

Hello all,
This is a branch-off from this thread.
Thank you for your reply Rob, I also suspect that the problem is related to "second-tier" subVI calls made by the first-tier subVIs. Here are answers to the questions you asked in your post:
-Yes, I am calling the VIs with absolute paths. To be more specific, I use the "VI Path" property of the VI (before exe) or "Directory Path" property of the Application (for exe).
-The three large subVIs that are called dynamically all share several subVIs. I suspect the problem is somehow related to this. To clarify, all three VIs use several specific VIs that I have written to open/read/write/close an industry-formatted file. I verified that the three main subVIs all call the common subVIs from the same locations on disk, i.e. the same subVI should not be included twice under different file locations. For a quick test, I dropped the file-editing subVIs into the 4th subVI (which never fails to open/close) and rebuilt the application. The results are the same: The 2nd, 3rd, and 4th VIs can all be opened and closed multiple times with no error. The first VI can be opened and closed once with no error, but then none of the first three VIs can be opened again (error 1003). Meanwhile, the trusty 4th VI can still open and close after the error begins, now with the several common VIs included in its code.
-I have the debug license, but I'm a little confused by what you suggested. At this point I am not running the subVIs (via invoke node) in order to produce the error, I need only try to open and close a reference to the VIs. I'm not sure if you meant to trace the execution of the subVIs when running them or if you had something else in mind. Can you please elaborate?
I am attaching an image of the block diagram of the top-level VI in case that helps. In the meantime I will continue investigating subVIs and attempt to identify any more useful symptoms. Thanks Rob (and anyone else!), I really appreciate your help.

Hmm... I thought I attached it. I'll try again.
Attachments:
080407_CompileError_BD1.jpg ‏81 KB

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

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.

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!

Error 7 occurred at Open VI Reference with Application Builder

Using Labview 5.1, I am building an application where all the vi's are placed in a single .LLB file. I have one top level vi (with sub-vi's), and one vi that is opened by the Open VI command. The program runs fine with labview installed. I want to make an executable file. I select the top level vi and select the vi that is opened by the Open VI command as a dynamically loaded file. I get an error when I attempt to build the file.
"Error 7 occured at Open VI Reference in Dist Build LLB Image.vi -> Dist Build App Image.vi -> Build application.vi"

Dear Sir;
There are two things that are good to try:
First, create the application in a folder that is closer to the root directory (e.g., c:\myApp). There is a limit to the length (or depth) of the path name to your application's target directory, so, if you are choosing a too long path you might get an error.
Second: The Application Builder reads certain information from the VI in order to determine how to build the executable. To avoid possible errors, either in the build process or in the built executable, make sure the VIs are LabVIEW 5.1 VIs. You can convert your VIs to LabVIEW 5.1 VIs by using the Mass Compile feature (File >> Mass Compile) in LabVIEW before you build your executable. The Mass Compile feature will allow you to select either a directory or a LabVIEW
.llb file to compile.
Regards

Error 7 occured at Open VI Reference in

The error is actually displayed after each and every Printer VI like SetMagins, PageSize, AddField, CloseReport but NOT after the NewReport.vi Call!

This error means that it can't find the file that you are trying to open a reference to. The file could either be missing or the path to it could be wrong.
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

高手快帮忙谢谢labview7打包后用到7中新的new report.vi的地方(选择的是word)都提示error 7 occurred at open vi reference in new report.vi

高手快帮忙谢谢
labview7打包后用到7中新的new report.vi的地方（选择的是word）都提示error 7 occurred at open vi reference in new report.vi。
下面提示的可能原因是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 UNIX.
我愿自己是个胡萝卜，可以自己自足啦!

我明白您的意思，也可以按您所说的作，
但是open vi peference这个vi是labview提供的标准new report.vi的子vi中使用到的，如果我手动修改open vi peference中的提供的word路径，也就是说labview提供的模块也要自己修改了??
我愿自己是个胡萝卜，可以自己自足啦!

LV 8.2.1 Error 66 or 1379 occured at open Application Reference. A LV 8.2.1

Hi,
LV 8.2.1 Error 66 or 1379 occured at open Application Reference. A LV 8.2.1
Using:
Application access an other LV application on an remote PC with Vi-Server Technology. (Based on MS OS Windows XP SP2 with all patches ...)
With LabVIEW 8.2.1 it is not possible (exactly: with one PC it works, with other PCs, (identical regarding configuration of LabVIEW-Components), the described errors occured ...
There is no problem with LV 7.1.1. ( If the VI-Server Configuration of the .exe will be done within the .ini -File...)
The differences between LV 7.1.1 are in the .ini-File of the application regarding the the access-List property.
Error 66 occures if ther is no entry in the access-List property.-> OK.
Error 1379 occures if i will use the copy of the LV .ini-File acl-property with allowed access from all clients (*) or special clients defined with IP-Adress ... -> BUG
The same behaviour is described in 2 threads in the discussion forum ..., but in my application/configuration the workaround acl.configuration: "allow access from all clients" will work only with one PC ?
So what is the solution ?
At this moment i gol back to LV 7.1.1, but this is surely not the solution ....
Thanks for help ....

Hi!
I have also found following discusion in the forum.
But the the problem for Error 1379 lies in LabVIEW 8.2.1 and VI Server.
This is a know Bug. This Bug should be fixed in a future version.
The problem is that the IP address in the could not be resolved into a machine name.
Workaround:
This program works in 7.1 so the only option right now is to use 7.1 instead of 8.2.1.
Plamen
Message Edited by Support on 10-31-2007 08:59 AM
National Instruments Germany
Application Engineer

Error 1003 At Open VI Reference

Similar Messages

Maybe you are looking for