"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

Similar Messages

I have Snow Leopard ver.10.6.8 and I have uninstalled iwork, because I don't have the equation writer on pages. So I re install it from the iwork's disk and when I tried to open any of the Apps, the system told me " check with the developer to make sure

I have Snow Leopard ver.10.6.8 and I have uninstalled iwork, because I don't have the equation writer on pages. So I re install it from the iwork's disk and when I tried to open any of the Apps, the system told me " check with the developer to make sure Keynote (for example) works with this version of Mac OS X "
iwork was running in my computer just a few moment ago !
Can anyone tell me what can I do? thanks

So I re install it from the iwork's disk
Did you repair permissions and restarted your computer after the installation? Check SU?

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

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

What is the logic for the behavior of LV9 when opening vi references?

I recently started using LV 9 and I can't figure out what the rationale is for the LV 9 behavior when opening references to vis. The way I understand it, LV9 looks up vis using the absolute path on the disk where they came from when opening references, even if they are in memory. If just a vi name is given, LV9 tacks on the path of the referring vi on disk when trying to open the reference. So, as far as I can see, either an application opening references to vis needs to specify absolute paths to the location on disk and be modified whenever a dynamically called vi's location on disk is changed, or a dynamically called vi has to be saved in the same directory as the vi doing the calling or in a rigid and inflexible directory structure.
Example:
I am trying to use a 3rd party library whose vis open a reference to a vi that I create, the name of which is obtained from those in memory using a name pattern. The library vis get the name of the vi I created and try to open a reference to it. Previously this worked because LV looked in memory for "my.vi" when opening the reference but this fails with LV9 because it apparently looks for, e.g., "D:\VI\3rdparty.llb\my.vi", not "my.vi". So, as far as I can see, I have to save my.vi in 3rdparty.llb in order to use it. And, if I want to use 3rdparty.llb in another application, I have to save other vis to 3rdparty.llb or create a new copy elsewhere and save to that copy for the new application. A similar situation would occur if I passed the name of my vi to the 3rdparty.llb vis - either I would need to pass an absolute path and modify my application if I ever want to move my.vi, or save it in 3rdparty.llb.
Another example:
I have a large application built into an executable that calls up to ca. 60 vis using references. Previously I could just specify the path to the executable, and I could easily open references to my vis. Now (if I try to use the LV 9 file structure), I can't figure out the paths I need to open references. Either I have to specify the absolute path to the original location in my development directories, or I have to store all my source vis in some particular directory structure. If I want to reuse my vis in other applications (which I do) things would get pretty complicated. Likewise if I want to optionally open references in other vis than my top level vi (which I do), it seems well nigh impossible.
Basically I am struggling with the concept that an application remembers the directory structure where the source files were located, and/or depends on a particular directory structure of the source files to work. Maybe I'm missing some tricks that would make things easier, but someone will have to explain to me why these are good things.

I appreciate the responses and explanations. I've certainly learned
some things. I have extensive experience using LV but over a fairly
narrow set of
applications so I'm certainly not aware of many of the possible
techniques. I clearly don't use LV in the same way as what appears to
be the mainstream for LV programmers.
I have some additional
comments on the various responses:
"But
with VI libraries and LVOOP this had the problem that multiple VIs could
end up with the same name..."
I'm not clear what this means exactly. My first response would be
that it doesn't seem like a good idea in general to use different
portions of code with the same name in a single application. I'm
surprised this is even possible. I don't think LV will even let me
build from a project in which it finds name conflicts for vis.
"In addition to what Rolf wrote, it should be
pointed out that LV should NOT be looking for files if you built your
app correctly. Each VI maintains a relative path to all VI it calls and
it should know exactly where to find them (assuming they're there).
I think this illustrates one thing I was talking about. The
assumption appears to be that the organization of your source files is
an essential ingredient in the application that is built, which is a
foreign concept to me. My project file knows where all my vis are, the
applications build correctly, and, using the 8.x and previous file
structure for my exe, they work, and have for some time. As far as I'm
concerned the main point of using a project that identifies my source
files is to be able to pull in code from different places - if I want to
use a different version of one of my dynamically called subvis, from a
different location, for example, I tell the project file to use the new
version and rebuild. In your scenario, as I understand it, I'm not sure
why a project file in which you identify source files is even needed,
if LV already knows everything about the components of the application
you're building. As I mentioned, my primary application uses ca. 60
dynamically called vis. Most of these control different subsystems of a
large distributed hardware control and data acquisition system. All of
these are used sometimes when the application is used, but pretty much
never all of them at once - typically something like 10-30 of the
user-interactive vis are run at once. There is some communication
between them using globals, queues, and semaphores and such, but for the
most part they are independent and I test them separately. Until the
application is built and used, there is no need to run the entire
application including all subvis, and I never do it. When I build my
application, the app builder finds all the vis I specify and constructs
the exe file including all the vis I've told it about. Before LV 9 it
never occurred to me that I might actually have to worry about being
able to find vis inside the executable.
"However as tst has mentioned having an
executable search for VIs is a VERY VERY bad idea as it can break your
entire app if it happens to find the wrong VI at some point."
I don't really follow this point at all. Where are these vis
masquerading as the ones I want that will break my application? The only
vis on the machines where my applications are used are there because I
put them there inside the executables. I certainly would never use
different vis with the same name in an application - as I said above, I
don't even know if it is possible, and don't want to find out. Search
paths to find components like shared libraries are a common thing. It
doesn 't seem like a stretch for the run-time environment to define a
default search path like "somewhere in the exe file containing the
application".
I don't want to make a mountain out of a mole hill here, as I said
before, I am happy as long as NI supports the 8.x file structure, but if
nothing else I have definitely learned to appreciate how different
executables built w/ labview are from executables constructed in other
systems.

How to get the SubVI(the virtual path is under .exe) reference in Run Time System

Hi everyone
The problem is about how to get the SubVI reference in Run Time System, when the SubVI is in .exe after building.
More details:
The top vi calls the SubVI by dynamic way, so the SubVI is included always, and the source object is the application.exe.
After the setup above, the SubVI will be in the application.exe. For example, SubVI's path is ...\application.exe\SubVI.vi
So, how to get SubVI's reference in Run Time System?
I can not get it when using "open VI reference" with the path ...\application.exe\SubVI.vi in Run Time System.
Actually, I can create a file to include the SubVI, instead of build the SubVI in application.exe , then I can get the reference convenintly. But it is not my favourate way.
Thanks
chenyin
Solved!
Go to Solution.

Here is the problem. Call a dynamic subVI means users could change it but it's also very attractive.
The dynamic call must be used within a user mastered but some parade can avoid problems.
It depends of why you use dynamic calls... => 2 main ways:
- Dynamic call are use to maintain an evolutive part of the code without acting on the executable => one unique VI distribution maintained by the administrator/developer
- Dynamic call are use to provide a collection of 'external' feature which could be enriched by the administrator/developer. For example, you provide to your customer a set of custom signal filters selectable in the executable.
In the 2 cases, you are only able to assess user skills to know if there is a risk of damage if there is modification.
So, to stay alone master a parade could be to provide dynamic VI without diagram but with the problem of maintenance because no modification in situ and more attention to manage distribution.
An other way is to hide the real distribution to user => call dynamic VI but unnamed it as *.vi but other (a repulsive name as OS system name ) or simply with no extension in order to not attract user... but it's questionable...
Another method more difficult but safer is to create a test of consistency ahead of your routine (version, user, modification date, ...)

VISA Write differs between TS Development System and LV Run-Time Engine

Hi all
I made an application on LabVIEW to test BERs (Bit Error Rates), and I used VISA Write between two COM ports to exchange data.
Everything works fine using just LabVIEW.
Afterwards, I used TestStand to call my application (VI). The LabVIEW adapters from TestStand were set to Development System by default, and everything works OK!!
Finally, I needed to disable the development system, and set the LabVIEW adapters from TestStand to LabVIEW Run-Time Engine and I notice that the speed of the data exchange between the two COM ports decreased dramatically.
The only difference was the speed...because all the data (changed slowly in this case) arrived correctly on the other COM port too.
The symptom was the same as decreasing the baud rate...but the baud rate and all the other configurations remained the same. The only difference was the change between Develpment System to Run-Time Engine to notice this decreased speed between the exchanged data using VISA Write.
Any solutions for this?
Thanks in advance
Joao
Solved!
Go to Solution.

Joao,
you state that using the LV Developement System as execution platform for your LV code modules result in faster datatransfer between the COM ports than using the LV Run-Time Engine.
So i am pondering: Does this refer to TS at all?
Please check the following:
Run you communication using a sole LV application in LV Developement System. This should be fast. Now build an executable of this application and run that one. Do you see the same behavior?
If there is no difference in a sole LV approach, there have to be some settings in the TS approach making this slow. So please let us know:
Are there different modules involved in that data transfer (which in fact points to the reply Christophe made)?
What about loading/unloading options of the modules?
How big is the hierarchy of the modules, e.g. is it necessary for the RTE to load stuff the Dev Env has already in memory due to loading a lvproj.......?
Could you provide a simple example sequence+modules showing this behavior?
What versions of LV and TS are you using?
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Error -17600 when switching from LabVIEW Development System to LabVIEW Run-Time Engine in Adapter Configuration

I receive an error message (code -17600) while loading my test sequence after switching from LabVIEW Development System (2009 f3) to LabVIEW Run-TIme Engine using the Adapter Configuration.
ErrorCode: -17600,
Failed to load a required step's associated module.
LabVIEW Run-Time Engine version 9.0.1f3.
When I switch back to the LV development system, everything is OK, and the sequence loads and runs perfectly.
My TestStand Engine Version is 2012 f1 (5.0.0.262).
I'd appreciate any help on this issue.
Roman

Hi Roman,
There are a couple of things you can try:
1) Determine if the LabVIEW RunTime Engine is corrupted in some way. Create a new simple VI with no sub-VIs, using the same LabVIEW Development system you used for mass-compiling the VIs. Create a TestStand step that calls this VI and ensure it runs correctly. Now switch your LabVIEW adapter to use the RuntimeEngine and choose the "Auto detect using VI version" option.
Check if the simple VI is loadable and runs without errors in TestStand.
If the step generates the same error, you should try a re-install of the LabVIEW development system.
If not, its most likely that there is some VI you are using that is not loadable in the LabVIEW Runtime Engine because:
1) Some sub-VI is still not saved in the right version or bitness. Open the VI heirarchy of the top-level VI that you are calling from TestStand and examine the paths of all the sub-VIs to check if they were in the folder you masscompiled and re-save any that are outside this directory.
Also, when you try to close the top level VI, do you get a prompt to save any unsaved files? If so, they could be the sub-VIs that are not saved in the right version. Save all of them.
Check if you are loading any VIs programatically and if these are compiled and saved in the right version as well.
2) There is some feature you are using in your LabVIEW code that is not supported in the LabVIEW RunTime Engine. To check this, add your top-level VI to a LabVIEW project and create a new build specification and create a new executable from this VI.
    Right-click "Build Specifications" and choose "New->Application(EXE)".
    In the Application Properties window, select Source Files and choose the top level VI as the start-up VI.
    Save the properties.
    Right-click on the newly created build specification and choose Build.
Run this executable (it will be run using the LabVIEW RunTime) and check if the VI has a broken arrow indicating that it cannot be loaded and run in the LabVIEW Runtime Engine.
You might need to examine your code and find the feature which is not supported in the LabVIEW RunTime and find an alternative.
Another thing i forgot to mention the last time around is if you are using 64-bit LabVIEW with 32-bit TestStand, then executing code using LabVIEW RTE from TestStand will not work since the 64-bit LabVIEW RTE dll cannot be loaded by the 32-bit TestStand process.
If none of the above steps resolve the issue, consider sharing your LabVIEW code so i can take a look.
Regards,
TRJ

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

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" with run time menue

Hello,
I met some problems with "open vi reference" in labview.i can't parallel run this vi with the run time menue.i can't load the any vi then the run time menue has activation.(the "open vi reference" can run after the run time menue release.). it's means labview is serial running for this both function.but now i want to parallel running in the program.so would you give the some idear?

Now I see what you are talking about. What you are trying to do is expected behavior. If you click on the menu while any state is running that doesn't lock the front panel, then the menu will halt the VI execution until you choose a menu item.
You should check the option in the event to "Lock front panel until event case for this event completes" Then you will not be able to click on the system menu until tthe VI is launched and running. If you wire a True like I suggested before, then you will fall out of the case pretty quickly in non-hoghlight mode, and the user most likely will not notice. If the VI you are trying to open is quite large, it will take a little bit of time for LV to load the VI into memory.
In highlight-mode, you just have to wait for the event to process before you select the menu.
Message Edited by Matthew Kelton on 12-03-2007 10:56 PM
Attachments:
edit events.png ‏27 KB

Open VI Reference asking save option

Hello,
I am opening a VI reference to analyze the state of the VI and closing it back and repeating this process for the bunch of VI's in a folder.
While closing the VI reference, it is throwing save dialog box for the some of the VI's, after closing the dialog only it is analyzing the next VI. To stop this behaviour I have set the Open VI reference Option to 0x20, but still it is coming. Please Give me some way to prevent this.

Are there any additional dialogs?
My assumption is, that those VIs are deriving from older LV versions and are not masscompiled to the current version you are using. Therefore, if you open the VI, LV developement environment will automatically recompile them, which will change the VI. So when unloading the VI, the developement environment will ask you to save unsaved changes (recompilation) of the VI......
Using the parameter 0x2 for opening the VI reference only effects the loading (supress the search dialog for subvis, do not mistake that with the "Browse for SubVI" dialog!), not closing the reference.
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

"Open VI Reference" slowly in development system

Similar Messages

Maybe you are looking for