From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

open vi by reference is very slow

Hi !

I have this main vi which is the user interface and it calls several subVIs sequentially (subvi 1, subvi 2, subvi 3 etc). the subVIs in turn have subVIs which belong to a DLL, I chosen to use CALL VI BY REFERENCE since my sequence is not fixed. when i run the main VI however, the time taken seem to be much longer than what it should be.

One observation which I made was that when I have one of these SubVIs opened. The main VI runs smoothly and can be completed in a matter of seconds. What can I do to run this Main VI smoothly and efficiently without having to open my SubVI ?

Goy
0 Kudos
Message 1 of 5
(2,931 Views)

The difference between calling a VI dynamically and not dynamically is than in a dynamic call the VI (and it's subVIs) only gets loaded when you call them and in a regular call they are loaded when you place them on the diagram. If your VI takes time to load (it's big, it has a lot of subVIs, it has a VI that's not in it's default location and needs to be searched for...), that's probably what's takes the time.

For a non-fixed sequence you can use a state machine. Search this site and the example finder for some example. There is also a template when you click File>>New. Alternatively, you can place your VIs in a non executing section of code of the top VI, which will cause them to be loaded, but not run.


___________________
Try to take over the world!
0 Kudos
Message 2 of 5
(2,921 Views)
In addition, you should also ensure that the dynamically called VI and all its subVIs have been saved in the current LabVEW version. How big is that VI? How long does it take to load when you open it manually?
0 Kudos
Message 3 of 5
(2,915 Views)
Hi

thank you guys for your reply.  I think that its a good idea to load the subVIs first by placing them in a non executing section. allow me to describe the program in a little more details simply for completeness

Layer I   Main VI (also the user interface)
-----------------------------------------------------------------------------------------------
Layer II  Sub VIs (a series of VI which are dynamically called)

These VIs are actually test cases. I made them dynamic because I have huge set of different tests and each time I run the main VI, I may only call a few of them to run. Thats why I chosen it instead of using a state machine. It works fine for me.
----------------------------------------------------------------------------------------------
Layer III  Hardware Drivers (VIs which interface directly to hardware)

These VIs are called by the subVIs in layer II. I had collectively put these VIs into DLL for easier organisation. I believe the additional time taken was actually due to loading the VIs from the DLL in this layer.
----------------------------------------------------------------------------------------------------

question : what can I do to let the Main VI in  Layer I to  know that I be using VIs from Layer III ? is there a way to include DLL into any VI to let it know it will be loading these VIs. As suggested, one way of coz is simply to put a VI which reside in the DLL into a non executing part of the main VI. I shall try next week when I get back to work.
0 Kudos
Message 4 of 5
(2,900 Views)

I'm not sure that will help you.

DLLs are basically supposed to be self-contained. I'm guessing (just guessing) that if you are using a DLL containing VIs, it will be executed by the LV run-time engine indepedently of the LabVIEW application. Hence - loading the VIs in LabVIEW will make no diffrence on the RTE.

I can't say I really understand why to save the VIs in a DLL. If you want them to be together, why not use the equivalent (in that sense) LLB?


___________________
Try to take over the world!
0 Kudos
Message 5 of 5
(2,882 Views)