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

Similar Messages

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.

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

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

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

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

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.

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?

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

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!

Open VI reference freezes

Open VI reference seems to run in the user interface thread. If you open a user dialog all the open vi reference functions halt until the dialog has been closed (even though they run in paralell loops etc, no data flow explanation).
MTO

> Loading and holding the references at startup is the solution I
> suggested to the developer who ran into this, for some reason I've
> never discovered this limitation myself. So it's not a big problem,
> but one (too) easily overlooked.
>
True, this limitation has been there since LV5. It is a temporary
ordering of things that resolves itself as soon as the modal VI goes
away, so it very rarely affects an application.
> We do however more and more develop application where there are
> parallell independent (should be that is) operations going on all the
> time, and this seems to introduce problems that are not always what
> one would expect. The memory leak described in the following is one
> example:
>
This looks a bit like a sneaky way of asking me to look at your "memory
leak" problem. I modified it a bit, changed the delay to 20ms instead
of 50, and made the button be a switch instead of latched, so I could
just let it clone all by itself. Running it in a normal version of LV,
I let it create and then I'd delete. All total, I created and destroyed
about 300 VIs, and the memory on my LV for OSX would go up a few megs,
then back down, then back up bit. I then tried it with a debug version
where I can look at the amount of memory that LV thinks it has allocated
at any point in time.
My quick diagnosis? It isn't a leak, but the extra memory usage is due
to fragmentation. Basically this stems from the fact that loading a VI
means bringing quite a bit of stuff into memory. To do this LV asks the
OS for some allocations. When tearing down the VI, LV frees the
allocations, if it didn't, this would cause a leak.
But, just because allocations are freed doesn't mean the system will
show them as free to give to another app. Here is why. If a program
asks for one byte, the OS will add one page of memory to the app -- that
is 4096 bytes. If the app asks for another byte, the OS doesn't have to
do much, it returns one of the 4095 reserved bytes that belong to the
app. After the 4096 bytes are used, the OS will give the app another
page for 9192 total. Interestingly, if the app starts deleting bytes,
the OS will only be able to take back a page and make it available for
other apps when no allocations are on that page. So leaving the first
byte allocated and say the 5000th byte allocated are enough for those
two bytes of allocation to use up 9192 bytes of memory.
This effect is caused by fragmentation, and it is there largely because
memory is cheap, so the OSes don't do any compaction. 4096 bytes on
even a 64Mb machine is a tiny drop in the bucket, so the OS trades space
for time and wastes memory to increase performance.
So, this isn't a guarantee that this isn't a leak. You did the right
thing in reporting it, and another person in R&D will spend more time to
verify that there isn't a leak, especially in the new AutoClose Refnum
feature. But my quick diagnosis is that as the app loads up a new VI,
some of its lists and arrays grow and are moved to some of the new pages
leaving behind holes. When the VI leaves memory, some of the pages
can't be freed because even though the arrays and lists have shrunk
back, they stay on the new pages. After a few of these chaotic
operations take place, an equilibrium is reached and the app will stop
growing. The pattern it takes, and the amount it grows is highly
dependent on the OS and the heap manager in use. So, on OSX mine may
only grew 3M, whereas one version of windows may grow 4M and another
10M. At any point, it is largely out of LV's control and isn't a true leak.
I hope this helps.
Greg McKaskle

No VIs listed for VI option in "Configure Open FPGA Reference"

I have a cRIO and I was using the Open FPGA Reference function to load a bitfile by specifying the VI name. This was working fine.
I have been compiling all day, and I just deleted a control and then changed a DMA FIFO datatype. When loaded and ran calls to the FIFO returned an error. So I tried refreshing the VI specification, but now when the dialog comes up, there are no VIs listed.
No idea what's wrong here.
Solved!
Go to Solution.

1) I commented out the FIFO when I compiled (forgot to switch it back on); so that's why the error occurred. Whoops.
2) I still don't know why I could not browse for the VI, but I was able to drag and drop.

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

Similar Messages

Maybe you are looking for