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

Similar Messages

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

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

  • 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 for a Project Library VI

    Hi,
    my code calls some subVIs by reference by using "Open VI Reference" and "Call by Reference" VIs. Now, "Open VI Reference" expects a path to the VI:
    When the SubVIs sit in the same folder as the calling VI, it is easy to simply supply the name of the SubVI. However, I would like to call a SubVI that is part of a project library sitting somewhere else on the disk. I could give the relative path, but this make the code pretty inflexible and if the relative path changes all the paths would need to be ammended. Ideally, I want to utilize the fact that I am using a project library. The help for Open VI Reference states that
    vi path accepts a string containing the name of the VI that you want to reference or a path to the VI that you want to reference. If you wire a name string, the string must match the full delimited name of a VI in memory on that target. If you wire a path, LabVIEW searches for a VI in memory that you previously loaded from that path on the same target.
     I thought that the underlined path was my ticket and tried something like this:
    but this did not work and I got
    "Error 1004 occurred at Open VI Reference in MainVI.vi:
    Possible reason(s):
    LabVIEW:  The VI is not in memory.
    To load a VI into memory with the Open VI Reference function, a path must be wired for the VI Path input."
    Wiring a path is not desirable as per reasoning above. Is there a way around the issue?
    Thanks in advance!
    Solved!
    Go to Solution.

    tst wrote:
    That should work, but you have to pay attention to something that's stated both in the help and in the error - if you use a string, the only way for LV to know what to access is if that something is already "in memory" (sometimes also referred to as "being loaded"). In the case of standard libraries, that means the VI itself or one of its callers has to be loaded. In the case of classes and XControls, loading the library (as in having it in an open project) should be enough to also load all of its members.
    Hm, thanks, I am not advanced enough to know about classes and XControls, but I will check it out. My VIs are part of a library but obviously don't get loaded because, as you said, all their calls are dynamic.
    tst wrote:
    What I usually do is use a static reference to a VI to get its name, because that ensures that it will be statically linked, included in executables, etc. That might not work for you if you want dynamic loading and then you will need to use some other means.
    Hm, this actually gives me an idea! I could add an enable input to all these dynamically called VIs so that the logic runs only when enable is ON; otherwise the VI is called but does nothing. Then I call the VI first statically with enable=OFF just to load it in memory and then proceed with my dynamic call. A little ad-hoc, but should work and serve my purposes, I think.
    Thanks!!

  • Open vi reference 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, 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

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

  • Open VI Reference LAN Help

    Hi! 
    I have a LAN/TCP connection. On the side A, I have a simple VI, and I would like to call it from side B. How can I do that?
    +++ In God we believe, in Trance we Trust +++
    [Hungary]

    Hi Durnek,
    The best is to use the Application Control palette, create a VI server on side A, on side B open a reference to the VI server with Open Application Reference Function, then you can access the VI with Open VI Reference and using the Invoke and Property nodes from the same palette you have access to a lot of information and settings.
    Let us know if you have more questions!
    Have a good day!
    Patricia

  • Open VI reference 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.

  • Use of "Open FPGA VI Reference" function --- Build Specification vs VI vs Bitfile

    When using the "Open FPGA VI Reference" function in a LV2012 cRIO application, there are 3 options: Build Specification, VI, or Bitfile. What would be the reasons for selecting one over the others? Does it affect the resulting startup.rtexe when the cRIO application is built? I searched through the help and in these forums, but I don't see criteria for selecting one over the others; maybe I missed it.

    Hello Chris,
    Apologies in advance for a long reply.  
    The reference method won't change the functionality of your rtexe.exe.  They all end up dropping a bitstream, based on a bitfile, onto the cRIO's FPGA.
    To a degree, the method used to reference the FPGA code is a matter of taste, but there are situations where one method is better suited than the others.
    Reference by VI:
    Setting the configuration options to open reference by VI is helpful during development when you are making changes to an FPGA VI often and building/testing using the same spec.  When this option is used, a bitfile is selected based on the default build specification for the project.  A project may have only one default build specification.  You can make any build the default by checking the option under the Source Files category in the build properties.  The default build is indicated in the project explorer by the green box around the builds icon.  
    Reference by Bitfile:
    This option references a bitfile directly.  Through the configuration window, you can select one specific bitfile to open a reference to (this is not dynamic and does not change unless you physically go make a change to that path).  If you're using this method, it helps to give your bitfiles more meaningful names than the ones that are automatically generated by LabVIEW.  When you run subsequent compilations off of the same build specification and do not change the bitfile nname or path in the build configuration, the old bitfile is overwritten and replaced with the new one.  When you are using this option, it is critical that you keep up with which bitfile is the one you want to be using.  There is an option now that will help alleviate any problems referencing by bitfile through the Open FPGA VI Reference function.  There is a new VI called Open Dynamic Bitfile Reference.  It is typically used when you want to chose a specific bitfile to load depending on something in your host code (a configuration option etc) - but it allows you to dynamically reference a bitfile on the block diagram by path.
    Referency by Build Specification:
    This option is good for when you want to always use a bitfile that is associated with/compiled with the same build configuration.  Say you have two options for top level FPGA VIs in your project (each with its own build spec).  Both of these VIs have the same interface (read/write controls, DMA) but they run different algorithms or something.  This is nice because you can easily switch your host application between them by picking the build spec associated with the FPGA VI you want to use.  In this type of sutation, referencing by VI is no good because you can only have on default build spec.
    cheers.
    Matthew H.
    Applications Engineer
    National Instruments

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

Maybe you are looking for