Open VI reference, problem on RT target

I'm having problems opening references to VI's on my RT target (cRIO 9074 with NI-RIO 3.1.0, VI server enabled). I'm using Labview 8.6.1
What I'm doing is opening the reference using an absolute path ("c:\ni-rt\temp\test12.vi") to the VI I want to run (path is the only input that is wired). "Open VI reference" throws error 1124 (VI not loadable).
The VI that should be loaded only contains a while loop toggling a boolean indicator, no subVI's.
If I remove the VI from the specified path I get error 7 (File not
found) when I run the code, so the path doesn't seem to be wrong.
I've tried running the"open vi reference" function on my host computer and on the target (both as an .exe and directly deployed) but the result is the same.
No error is thrown if I build an .exe and include test12.vi in the build, but I assume that in that case the VI has already been loaded when "open vi reference" is called. This is not a solution for me.
If I move both VI's to my host computer everything works.
Does anyone have any ideas about what could be wrong? I've searched to forum but found no solution.

Hi Sterlind,
Have you tried building a source distribution, the VI might depend on some VI:s from VI.lib or such.
This KB seems to suite your error description,
http://digital.ni.com/public.nsf/allkb/10F1D411ACBAD3D9862572FF0064C801?OpenDocument
Regards,
Klas Andersson
National Instruments
AE, Sweden

Similar Messages

Open vi reference problems in labview 7 after building an application

I have a vi with an Open VI Reference vi in it.
This works fine. But when I build an application of it and run the vi it gives problems.
I get an Open VI Reference error. Why?

If you have strict typedefs for the dynamic loaded VIs you need to include the line "BldApp.RemovePolyVIsandTypedefs=False" into your LV ini file. See this discussion.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

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

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.

Open VI reference in RT

I'm opening dinamically some VIs with "Open VI reference" on a FieldPoint 2210.
I did it many times with 7.1 and 8.2, but now with 8.6 i get error 1124:
LabVIEW: VI is not loadable.
In a built application, this error might occur because the VI being loaded was last compiled for a different OS, in which case you must save the VI on the current platform. [then it talks about polymorphic VIs, but i'm not using any]
But the VIs are under the FP target in the project, have been saved for 8.6 and work on RT when launched directly from the project.
The problem is the same if i call Open VI from an exe or from a vi.

Make sure that you've installed the latest Fieldpoint driver sofware available. I also had the problem that a VI was not loadable when inside the exe, but worked OK in dev mode.
Regards,
André
Using whatever version of LV the customer requires. (LV5.1-LV2012) (www.carya.nl)

Reference problem in TFS build

Hi
I am getting reference problem in TFS build.
how to update nugget package in command prompt in TFS server.
Please advice.
Primary reference "EntityFramework".
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "EntityFramework". Check to make sure the assembly exists on disk. If
this reference is required by your code, you may get compilation errors. [C:\Builds\1\ACIS\ACISApplication\src\ACIS.Model\ACIS.Model.csproj]
          For SearchPath "{HintPathFromItem}".
          Considered "..\packages\EntityFramework.6.1.1\lib\net45\EntityFramework.dll", but it didn't exist.
          For SearchPath "{TargetFrameworkDirectory}".
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\EntityFramework.winmd", but it didn't exist.
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\EntityFramework.dll", but it didn't exist.
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\EntityFramework.exe", but it didn't exist.
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\EntityFramework.winmd", but it didn't exist.
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\EntityFramework.dll", but it didn't exist.
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\EntityFramework.exe", but it didn't exist.
          For SearchPath "{Registry:Software\Microsoft\.NETFramework,v4.5,AssemblyFoldersEx}".
          Considered AssemblyFoldersEx locations.
          For SearchPath "{AssemblyFolders}".
          Considered "C:\Program Files\Microsoft SQL Server\110\SDK\Assemblies\EntityFramework.winmd", but it didn't exist.
          Considered "C:\Program Files\Microsoft SQL Server\110\SDK\Assemblies\EntityFramework.dll", but it didn't exist.
          Considered "C:\Program Files\Microsoft SQL Server\110\SDK\Assemblies\EntityFramework.exe", but it didn't exist.
          Considered "C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\EntityFramework.winmd", but it didn't exist.
          Considered "C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\EntityFramework.dll", but it didn't exist.
          Considered "C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\EntityFramework.exe", but it didn't exist.
          Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\EntityFramework.winmd", but it didn't exist.
          Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\EntityFramework.dll", but it didn't exist.
          Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\EntityFramework.exe", but it didn't exist.
          Considered "C:\Program Files\Microsoft SQL Server\MSAS11.MSSQLSERVER\OLAP\bin\EntityFramework.winmd", but it didn't exist.
          Considered "C:\Program Files\Microsoft SQL Server\MSAS11.MSSQLSERVER\OLAP\bin\EntityFramework.dll", but it didn't exist.
          Considered "C:\Program Files\Microsoft SQL Server\MSAS11.MSSQLSERVER\OLAP\bin\EntityFramework.exe", but it didn't exist.
          Considered "C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\EntityFramework.winmd", but it didn't exist.
          Considered "C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\EntityFramework.dll", but it didn't exist.
          Considered "C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\EntityFramework.exe", but it didn't exist.
          Considered "C:\Program Files\Microsoft.NET\ADOMD.NET\110\EntityFramework.winmd", but it didn't exist.
          Considered "C:\Program Files\Microsoft.NET\ADOMD.NET\110\EntityFramework.dll", but it didn't exist.
          Considered "C:\Program Files\Microsoft.NET\ADOMD.NET\110\EntityFramework.exe", but it didn't exist.
          For SearchPath "{GAC}".
          Considered "EntityFramework", which was not found in the GAC.
          For SearchPath "{RawFileName}".
          Considered treating "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL" as a file name, but it didn't exist.
          For SearchPath "C:\Builds\1\ACIS\ACISApplication\bin\".
          Considered "C:\Builds\1\ACIS\ACISApplication\bin\EntityFramework.winmd", but it didn't exist.
          Considered "C:\Builds\1\ACIS\ACISApplication\bin\EntityFramework.dll", but it didn't exist.
          Considered "C:\Builds\1\ACIS\ACISApplication\bin\EntityFramework.exe", but it didn't exist.
Primary reference "EntityFramework.SqlServer".

Hi Narasimha,
I'd like to know whether you can build locally with MSBuild. You need to make sure you can build successfully in local with MSBuild before you can use TFS build, since TFS build use MSBuild as its default compiler.
However, from the error message, seems you don't have entity framework installed properly. Please have a try to reinstall entity framework for the needed version, also get the assemblies stored in GAC. If you have any other related concerns, you can
open a new thread in entity framework forum for a better response.
Best regards,

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

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

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 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 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 prevents execution of other parallel threads

I am using splash screen to start an application. I use dynamic loading of the Main.vi and an animation during the loading, both in parallel threads (see image below). However, when the Open VI reference VI is called everything else stops executing (the animation stops running) until the Open VI reference is done. I must call the Main.vi dynamically, because it takes some time to load and I want to notify a user that the application is loading (using animation). Is there an option to prevent the Open VI reference to block the execution of other threads? Or should I use some other approach?

andrej wrote:
But the problem is not in the Run.VI method because the Open VI Reference blocks the execution of the top loop and I need the Open VI Reference to call the Get VI Dependencies method. Other approach could be to create a static array of dependencies and then to use this array to load VIs from bottom up.
The only question now is if the Get VI Dependencies method returns dependencies in top to bottom order? If it does then I can just load VIs in reverse order from the array.
Well the problem is the Open VI Reference! This executes in the UI thread, as several people have explained already (and really can't be made to do otherwise without causing a number of possible and nasty race conditions, some of them even related to the underlaying OS and not just LabVIEW itself), just as your two Property Nodes in the upper loop have to use the UI thread too.
Once Open VI starts it only returns if it has loaded the required VI fully into memory (and that includes any dependencies that aren't already in memory) and linked them all properly together or runs into an error during loading. For this duration, NO UI Property Node can execute, which is what stalls your upper loop. If you would use local variables or terminals instead the upper loop would happily run along while Run VI loads the entire VI hierarchy but it would still not show on the UI, because in order to draw the new data from the diagram passed to locals and terminals LabVIEW has to catch the UI thread to do the UI drawing.
So first fix is to kick out any property nodes from the upper loop and the second part of the solution is to load your VI hierarchy in chunks instead of simply loading only the top level VI directly. It would be nice if Open VI had an option to allow UI thread release between loading of chunks of VIs, but the implications are not that nice. It would be quite easy for an uncareful LabVIEW programmer to create a lockout situtation then, where two functions are in fact waiting on each other to release some locks so that the program gets hang up. And a simple warning in the documentation to watchout as this option can allow to create such lockout situations is not very useful as nobody reads them anyhow.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

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, problem on RT target

Similar Messages

Maybe you are looking for