Open vi reference in executables

My application requires to run two sub vis in parallel , Even though the VI is running the executable is showing reference.
I am using open VI reference to open the sub vi from the main vi
please reply..urgent

I guess your problem is related to the vi path. You should create some indicators for debugging. One indicator for the path, and some indicators on the error output. Then you can build your aplication for testing.
Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)

Similar Messages

Open VI Reference to a LabVIEW executable.

Hello,
I haven't done this for a while and it's not working like expected. I'm trying to "Open VI Reference" from executable A.exe to B.exe. I'm trying to get a control value from B.exe in A.exe. Can someone send me an example?
Right now I'm at this stage: I have A.exe running as a LabVIEW executable. I'm trying to "Open VI Reference" to A.exe from LabVIEW development without success. Not sure what I'm doing wrong.
Don't hesitate to ask more info if you need some.
LabVIEW 2012, Windows 8.1.
Thanks,
Michel
Solved!
Go to Solution.

Bob_Schor wrote:
Once you have an Executable, does it matter that the underlying Development system is LabVIEW, rather than (say) Visual Studio, or Matlab? I suppose you could write an application that "knows" to, for example, listen to a TCP/IP port and interpret/execute commands, but that doesn't sound like the question being asked.
BS
LabVIEW-built executables still run as VI's in the RTE, though. Their identities have not been abstracted away into one single object or anything, and they still have name-based VI server access.
You can configure a build specification to include almost nothing, and require the VI files to be present in expected locations (i.e build specification's data or support directories). By default, all items in an executable application build specification are set to be put in the same location as their caller, which results in most things going into the .exe file, internally referenced in a directory-esque form like crossrulz mentioned, "MyExecutable.exe\MySubVI.vi".

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

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 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 by string in executable

Hi all,
Scenario: A top-most vi (main.vi) calls two subvis (subvi1.vi and subvi2.vi) separately such that they run in parallel. subvi1.vi has a front panel that appears when called, subvi2.vi does not.
subvi2.vi uses Open vi Reference to get a reference to subvi1.vi. It then uses this reference in a loop and continually polls the property FrontPanel.IsFrontmost to determine if the front panel of subvi1.vi is frontmost. When it is frontmost, it performs certain actions. When it isn't frontmost - it doesn't.
This all works great in the development environment, but as soon as I build this 'scenario' into an application I get the following error:
subvi2.vi is generating the reference to subvi1.vi using the string "subvi1.vi" as an input to the path terminal of the Open vi Reference function. Why does this cause problems in a built executable?
P.S. Clearly this scenario is actually a part of my much bigger project, hence I don't have any simple vi's to attach
Message Edited by Thoric on 04-27-2009 01:06 PM
Thoric (CLA, CLED, CTD and LabVIEW Champion)
Solved!
Go to Solution.
Attachments:
crash.jpg ‏28 KB

Thoric wrote:
Norbert B wrote:
Thoric,
it's disturbing that LV is crashing on your system due to this error. What version of LV do you use?
LV 8.6.1 at least (i don't know which version was the first one) creates the following error:
LabVIEW: Open VI Reference no longer matches VIs in memory by filename. A filename is no longer sufficient because the full name of a VI now includes any owning libraries.
This error occurs even in the developement system.
I asume that the crash itself is created by handling of invalid references.
hope this helps,
Norbert
Norbert,
I am using LV 8.6 (not 8.6.1). I am using strings to identify vis, not paths. I believe the error you are encountering only relates to using paths for referencing vis.
If your assumption is correct and my crash is due the handling of invalid references, then I need to generate a path to the vi, rather then using it's name. But generating a full (non-relative) path might be tricky? If within subvi2.vi I use the 'current vi's path' function and strip it to determine the executable path, then add subvi1.vi, should that get me the path to subvi1?
THis really depends on how you did your build. If VI1 ends up as dynamic file vs part of the app, the paths will be different. Easy enough to check. Look at where your exe is and figure out if VI1 is there in the support/dynamics. If not it is probably inside the exe to the path would then be "My.exe.VI1.vi".
But I am speculating thats the issue so try to get more info.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Open VI Reference Function in an Executable

Hi All,
Is it possible to call a sub-VI (which within itself calls other sub-VIs not included in the executable source files) from an executable (LabVIEW 2011).
I have no problems calling the sub-VI via "Open VI reference" when runing the main vi as is. As soon as i build the execuable, search for the intended subVI the exe"looks for a few items" then stalls.
The subVI controls a few comports, and prompts the user to take some actions. The SubVI requires an input from the Main VI and when completed outputs a cluster of for the Main VI to continue.
Solved!
Go to Solution.
Attachments:
vi ref.png ‏3 KB

Hi All,
Firstly the main error was "1031 ~ VI Reference type does not match VI connector pane."
Secondly, the subVI had a dependency on "Space Constant.vi" which is stored in the vi.lib, The Main executable did not have "Space Constant" in its vi.lib.
SOULTION
1. Added a "space constanst" to the executable project.
2. Ensured that the Refnum type was not "strict" (also ensure refnum matches VI pane)
becuase I am using a cluster, if the main cluster changes for any reason, you must update the inputs and outputs of your subVIs. This was achieved may making the cluster a control type def. However, because some subVIs are independent from the main, I have to ensure I use the lastest controls when building independent subVIs.
This allowed me to run the subVI.
Thanks.

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

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

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 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 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 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 blocks event loop

Run the attached VI. If you have the WORKS/DOESN'T WORK toggle in the WORKS position and hold down the HOLD ME button with the mouse, the ticking clock keeps on ticking. If you let go of the mouse and toggle to the DOESN'T WORK positions then hold down the HOLD ME buttong with the mouse, the ticking clock stops ticking. The problem seems to be that the Open VI Reference call either doesn't execute, hangs, or blocks for one reason or another. The state of the event structure "Lock the front panel ..." is irrelevant, i.e. doesn't seem to affect behavior.
Is this a known limitation of Labview? Is there a workaround to enable a call to Open VI Reference when the mouse is down?

> A "value change" event is when a value has
changed, I mean has finished to change ; if you're still holding the
button, its value hasn't finished to change yet and can not change if
the mouse up happens when the pointer is outside the button, no ?
Well, not really. Value change shoule be when the event is called, by definition, i.e. the event structure should only be called, process an event, if that event did happen. I didn't ask for "value is half way changing", I asked for "value change". In my original example the value has changed, as shown by the status field and boolean display. Also, when the case structure with the VI Open Reference is disabled by the toggle the event structure finishes and goes on to the next event, the timeout, getting the clock to keep ticking.
> If you change the even to a "mouse down?" event (the one in red) it works....
It should, but if the mouse moves out of the button and then it is released, one never gets a mouse up, which is needed to stop the action. (Well, there may be ways to globally track mouse up and know that we last had a mouse down on that button, but now we're talking very cumbersome and error prone.)

Open vi reference in executables

Similar Messages

Maybe you are looking for