What is the cause of the apparent delay when calling a sub VI dynamically?

[pegatron]

I have wroten a sub VI for DAQ first, and then dynamically call this sub VI in the main VI.

I run the program on a PC which has LabView development software installed on it, and it turns out quite well.

But when I run the same program on a PC which only has a LabView run-time engine installed on it, it delays apparently, about 2-3 seconds for each calling compared with the previous PC.

Has anybody ever encounter such a problem ?

[altenbach]

If the VI is not in memory it needs to be loaded first. This is not instantaneous. IT will take even longer if your HD needs to spin up first.

Are you calling it by filename? Maybe you should call it via a static VI reference instead. Hard to tell what the solution is unless you give us more details.

[Dirk_H.]

I am having the same problem.  I updated software from LabVIEW 7.1 to LabVIEW 12.  I have a GUI that calls scripts built with file names to dynamically load test VIs.  In 7.1, I had to create a VI that was loaded that was a "Top Level" VI just to get the VIs in memory during testing and before the dynamic calls were made to speed things up.  Now I have tried with and without the "Top Level" VI loaded in memory and still get the 2-3 second delay when running a test VI.  Everything is built from the same project so I'm at a loss here.  Is this a LabVIEW 12 known problem?  Has someone found a solution to this delay other than changing software to static calls?

[billko]

---

@Dirk_H. wrote:

I am having the same problem.  I updated software from LabVIEW 7.1 to LabVIEW 12.  I have a GUI that calls scripts built with file names to dynamically load test VIs.  In 7.1, I had to create a VI that was loaded that was a "Top Level" VI just to get the VIs in memory during testing and before the dynamic calls were made to speed things up.  Now I have tried with and without the "Top Level" VI loaded in memory and still get the 2-3 second delay when running a test VI.  Everything is built from the same project so I'm at a loss here.  Is this a LabVIEW 12 known problem?  Has someone found a solution to this delay other than changing software to static calls?

---

It's a known problem for anything that loads executable code from the hard drive.

[pegatron]

---

Dirk_H. 已写：

I am having the same problem.  I updated software from LabVIEW 7.1 to LabVIEW 12.  I have a GUI that calls scripts built with file names to dynamically load test VIs.  In 7.1, I had to create a VI that was loaded that was a "Top Level" VI just to get the VIs in memory during testing and before the dynamic calls were made to speed things up.  Now I have tried with and without the "Top Level" VI loaded in memory and still get the 2-3 second delay when running a test VI.  Everything is built from the same project so I'm at a loss here.  Is this a LabVIEW 12 known problem?  Has someone found a solution to this delay other than changing software to static calls?

---

Did you run your program on a PC installed with the entire Labview 2012 software or just the run-time engine? I tested my program under both circumstances , and it turned out quite different.

[billko]

I failed to notice that you said it was the same whether or not you pre-loaded them with the top level VI.  Now I'm a little perplexed.  Is this a direct port or did you try to recreate the architecture?

[Dirk_H.]

My fear is that this is a known problem.

I am running this as an executable but on a PC that has the Professional version of LabVIEW 2012 installed on it so I could test source first before doing the build.

My dynamically loaded VIs are in a LLB built without block diagrams.

This was a direct port.  I did have some other issues along the way.  The most notable was with my .INI file read/writes.  I had to make them all read/write strings to get my dynamically loaded VIs to run.  Otherwise, I got a dialog that said the dynamically loaded VIs were not executable (forget the entire text) even though I could run them directly.  So some changes have been made to accommidate the update to 2012.

Same whether I did a preload of the files or not.  My version of preload is to call a VI that contains all of the test code in an infinite loop without actually calling the test code.  I did notice that TestStand has a way to preload scripts.  Perhaps this is what I need to do in LabVIEW.

[billko]

I'm hoping that maybe this helps?

http://digital.ni.com/public.nsf/allkb/387EF1BC4762A96C8625713B007E0032

[Dirk_H.]

Thanks but I tried this one already with no luck.  I am interested in knowing what different results were had between a PC with only a runtime library on it vs a PC that had a development install.