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

Similar Messages

  • Open FPGA reference - slow?

    I'm trying to do some data acquisition through a cRIO 9101 attached to DI, DO and AI modules. Right now, I have something like a Read AI VI in my cRIO application that opens the FPGA reference, reads the control (using the read control node), then closes the FPGA reference and returns the read value to the calling VI. My issue is that this seems mindbogglingly slow.
    I use this VI and the corresponding DI and DO VIs that are pretty mucht he same internally in a handful of places throughout my code and at least in one spot where I've timed it, it takes something like one full second to run this VI. The culprit seems to be the open FPGA reference VI.
    At this point, can anyone suggest what I'm doing wrong?
    Is this the right way to go about this, given that my access to the FPGA needs to be fairly scattered throughout my code?
    Should I perhaps just write the FPGA reference into a global variable and initialize it once at the start and use it everywhere from the global?
    An alternative that I've got going right now is to use the first call VI to only use the open FPGA reference once, then store the reference in a shift register.
    Both of these soultiuons create some issues with closing the FPGA reference. Can anyone comment if closing the FPGA reference is really all that necessary?
    Thanks,
    Chris

    My VI is fairly complex, I do single reads and writes in various locations throughout the code, but never repeatedly in rapid succession. To facilitate this, I had a subVI that just reads analog values from the FPGA and it is within this subVI that I had the sequence of Initialize FPGA ref. --> read --> close FPGA ref. This was the initial solution that was giving me trouble, each call to this sub VI would take a very long time.
    My solution right now is to initialize the FPGA reference once at the start of the application and store it in a global, then use that reference every time I do a read/write. This leads to not closing the reference until the application is done, which, in my application, really doesn't happen unless there's a system reboot, power failure, etc. So at the end of my application frequently, the reference will not get closed.
    I assume that opening the reference does not store any state information that would survive a reboot (i.e. storing something in flash), so not closing the reference shouldn't be an issue. If anyone has any information to the contrary, please let me know.
    Thanks,
    Chris

  • 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

  • "Open VI Reference" slowly in development system

    Hello,
    One of our programs has a plugin structure. We open more than 50 VIs over VI Server. This is fast in runtime system, but slowly in the development system. The problem is the function "Open VI Reference". If you try to open an Ref to a very small vi, it takes nearly 2s per VI. In runtime system this is done in 2-4ms.
    So the program takes ages to start in development system.
    Is there a way to speed this up?
    Thanks
    Sletrab
    Attachments:
    Bild348.png ‏99 KB

    Is it always slow or fast the first time? Could it be that you're not closing the ref afterwards?
    And/or debugging setting in the vi's,, which ofcourse is turned off in a .exe
    /Y
    LabVIEW 8.2 - 2014
    "Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
    G# - Free award winning reference based OOP for LV

  • Open VI reference for VITs and VIs

    Hi
    I have a VIT and I get the reference using the Open VI reference. When I change (rename) this back to a VI, and get the reference for it, its much faster. Does the open VI reference takes longer for VITs than VIs in obtaining a reference?
    Another question  is the same VIT, takes lesser time to get the reference using the Open VI reference in LabVIEW 8.5.1. It takes longer in LV8.6. Why is this happening? 
    Thanks
    Vaa San.

    The two main differences between a VI and a VIT are that   VITs are never run, but are templates that generate a VI instance immediately that has all the properties, attributes and limitations of a VI.  A VI on the other hand has only one instance (unless you make it reentrant)
    ·         A VI generated by a VIT is debuggable just like a VI in that you can trace the execution along the wires. In general, a VIT creates a copy of the VI in memory when you open a reference to it. Creating that copy takes time, which affects performance when doing recursion. That copy is then a standard VI in every sense, except it is not a file. Also, if you don't close these references, they will take up space in your RAM. Reentrant VIs can currently only do real recursion in 8.5 and if they are part of a class. If you open a VIT, you don't open the actual file, but a clone. This way you can open it multiple times. Each time you open it, you get a clone. This is especially useful when you open the VIT with VI Server. VIT's are useful to make an interface window once, and use it multiple times in your program. If the code should run multiple times, but doesn't have a user interface, use reentrant VI’s instead. As far as having the project open, a VI will reload all instances related to the project therefore causing the Vi to load slower. Best Regards,
    Juan Galindo
    Applications Engineer
    National Instruments

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

  • "Open Vi Reference" generates a Error 7

    Hello,
      I am getting "Error 7" from the "Open VI Reference" vi, the name of the vi is wired vi path input. The "Error 7" means that the vi cannot be found. So I went to "Tools ===> Options ===> Paths" and modified the Path so that Labview can find it. But for reasons I do not understand the vi I want to get a reference for cannot be found. So it leads me to beleive that the "Open vi Reference" does not use the path option to find a vi. Any ideas what is going on?
    Regards,
    Kaspar
    Solved!
    Go to Solution.

    Hello,
      Thanks for getting back to me. I have attached a file fo the screenshot of the Block diagram. The "Open Vi Reference" is in the upper left hand corner, which generates a error when I have updated the path options to point to where the file exists.
    Regards,
    Kaspar
    Attachments:
    vi_error.GIF ‏21 KB

  • Open VI Reference Error 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 error

    Hi all,
    I am using LabVIEW 2011 SP1. I am running such a vi which is calling another vi by selecting a boolean button. After opening the new vi, the previous vi will stay opened but being minimized and the new vi will stay maximized untill user forces to close the new vi. All the operations are going successful at the start. But if we keep running it for 12-13hrs, then an error is coming in open vi reference of the previous vi and the previous vi becomes maximized and above the new vi. I have attached the error message herewith. Please give me a solution.
    Attachments:
    error.txt ‏1 KB

    Error 2 is a memory full error. If you right-click on the error cluster you can select "Explain Error". The most likely reason is that you are not closing your references properly, or you are not closing them at all. It could also be something else, such as continously building an array until you run out of memory. Without seeing some code it's impossible to say what the real cause is. If you cannot post your code then you will need to look at your code to see whether you are auto-disposing the VI references. If you are not, then you are responsible for closing them. If it's not a reference issue, then you should use the performance tools to monitor the memory usage of your VIs to see which one is causing unbounded increased memory usage.

  • Why does my iPhoto open and run slow since upgrading to OSX 10.8.5

    Why does my iPhoto open and run slow since upgrading to OSX 10.8.5?  I have an Imac - Intel 2.5 GHz quad core I5 - with 20 GB of memory. Before the upgrade it was much faster.

    Why does my iPhoto open and run slow since upgrading to OSX 10.8.5?  I have an Imac - Intel 2.5 GHz quad core I5 - with 20 GB of memory. Before the upgrade it was much faster.

  • Quirk, Open VI Reference and LLB

    I found a strange quirk opening a VI Reference (on a PXI).  The "normal" method of doing this is to Open Application Reference (to find the remote site) then to Open VI Reference with the path to the desired VI.  Darren Nattinger pointed out (in 2006) that you can use just the name of the VI, provided the VI is on the same folder or LLB as the current VI.
    Caveat -- this behavior is present in LabVIEW 7.0 (I'm maintaining some "legacy code").  I suspect it will be present in later versions, but haven't (yet) tested it.
    Quirk 1 -- if the VI in question has been downloaded (or deployed) to the remote site, and hence is in memory, then the "path" information isn't used, only the VI name.  Thus if you have a path "C:\ni-rt\startup\MyVI.vi" specified in the Open VI Reference, but have absolutely nothing in the startup folder on your PXI, but have "deployed" your Project, this call will work, even though the "path" part of the argument is not valid.  Useful when testing.
    Quirk 2 (and the "real" reason for this post) -- if the VI is embedded in an LLB, it depends on whether or not it is a "Top-level" VI or not.  Suppose the path is C:\ni-rt\startup\MyLib.llb\MyVI.vi.  Consider two VIs in this LLB -- TopLevel.vi and SubVI.vi (where TopLevel is at the top level of the LLB, whereas SubVI is not).
    Case A -- the LLB has actually been downloaded to the remote site.  Doing an Open VI Reference, with either the full path or just the VI name, works, whether or not you are calling TopLevel or SubVI.  Nothing surprising here.
    Case B -- you are taking advantage of Quirk 1, and have not actually put the file on the Remote site (i.e. there is nothing at the path specified).  You have, however, downloaded the LLB to the Remote.  Doing an Open VI Reference with SubVI, whether with full path or just VI name, works fine.  However, trying to open TopLevel fails, with Error 7 (File Not Found), whether using full path or VI name.
    Summary -- Quirk 2 is that Quirk 1 has a quirk if the VI being referenced is a top level VI in an LLB.
    [My apologies if this is common knowledge -- I failed to find this behavior documented, but may have overlooked something].

    Bob Schor wrote:
    I found a strange quirk opening a VI Reference (on a PXI).  The "normal" method of doing this is to Open Application Reference (to find the remote site) then to Open VI Reference with the path to the desired VI.  Darren Nattinger pointed out (in 2006) that you can use just the name of the VI, provided the VI is on the same folder or LLB as the current VI.
    Caveat -- this behavior is present in LabVIEW 7.0 (I'm maintaining some "legacy code").  I suspect it will be present in later versions, but haven't (yet) tested it.
    Quirk 1 -- if the VI in question has been downloaded (or deployed) to the remote site, and hence is in memory, then the "path" information isn't used, only the VI name.  Thus if you have a path "C:\ni-rt\startup\MyVI.vi" specified in the Open VI Reference, but have absolutely nothing in the startup folder on your PXI, but have "deployed" your Project, this call will work, even though the "path" part of the argument is not valid.  Useful when testing.
    Quirk 2 (and the "real" reason for this post) -- if the VI is embedded in an LLB, it depends on whether or not it is a "Top-level" VI or not.  Suppose the path is C:\ni-rt\startup\MyLib.llb\MyVI.vi.  Consider two VIs in this LLB -- TopLevel.vi and SubVI.vi (where TopLevel is at the top level of the LLB, whereas SubVI is not).
    Case A -- the LLB has actually been downloaded to the remote site.  Doing an Open VI Reference, with either the full path or just the VI name, works, whether or not you are calling TopLevel or SubVI.  Nothing surprising here.
    Case B -- you are taking advantage of Quirk 1, and have not actually put the file on the Remote site (i.e. there is nothing at the path specified).  You have, however, downloaded the LLB to the Remote.  Doing an Open VI Reference with SubVI, whether with full path or just VI name, works fine.  However, trying to open TopLevel fails, with Error 7 (File Not Found), whether using full path or VI name.
    Summary -- Quirk 2 is that Quirk 1 has a quirk if the VI being referenced is a top level VI in an LLB.
    [My apologies if this is common knowledge -- I failed to find this behavior documented, but may have overlooked something].
    This will likely not apply at all to >= 8.0. LabVIEWs Open VI Reference will now distinguish cleanly between absolute path and just the VI name itself. If you use just the VI name the VI needs to be in memory or for a built application included in the app. The quirk about VIs in the same LLB as the currently active VI sounds very strange to me but it may still work.
    However if you specify an absolute path, Open VI Reference will bark with an error if the VI can not be found at that location or if the VI already loaded in memory with that name has not the same absolute path. This is supposedly to make it very hard to create cross linking even when using VI server.
    Rolf Kalbermatter
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

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

  • 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

  • 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

Maybe you are looking for