Run Dynamic VI Problem with LabVIEW2009,SP1

[LVTestek]

Hello All,

Please see attached program. If the dynamic VI is in memory, then I am not able to run the VI dynamically.

In previous versions of LabVIEW, it was possible.

Please let me know, if this is correct behavior.

I am aslo seeing LabVIEW2009,Sp1 is very slow with my application. Application was build  with LabVIEW 8.2.1, now I converted to LabVIEW2009,sp1.

Thanks,

[cirrusio]

Is there the possibility of running this VI as reentrant or does it maintain it's state from call to call?  If so, you can always set LoadVI.vi to reentrant and you should have no problems (but remember to set options on the Open VI Reference to 0x08).

Cheers, Matt

[LVTestek]

Thank you for your suggestion.

Reentrant is not possible in my application. It has to be normal VI.

[cirrusio]

From the help files:

 You cannot use this method to run a VI that is already reserved for execution by another VI.

So, I think that this should never been possible.  It surprises me that you were actually able to get this to work before.  Is there any reason you need to call this VI by reference AND as a subVI with in the same memory space?

Matt

[LVTestek]

Thanks for the message,

I was able to run with LabVIEW8.2.1

If the VI is already in memroy, then it will take lesser execution time. Otherwise it has to be load and execute.

VI has to be called with reference.

[LVTestek]

I prepared VIs in both versions (8.2.1, LabVIEW2009.sp1).

Please check and let me know why difference.

Thanks,

[LVTestek]

Sorry forgot to attach.

[ThHagel]

Hi,

It's interesting that the Load.vi's execution state is always "Running" and it doesn't matter when the direct vi call is executed (in parallel, before, or after the dynamic call). I can not try this with LV8.2 but I tried 7.1 and it's the same behavior. Does someone know why?

Are you sure this works with 8.2?

[LVTestek]

See in last attached zip.

I really do not know, why.

[cirrusio]

LVTestek,

Tried this in 8.6 and got the same results using your LV82 version (error at the invoke node).  One thing - in the LV82 version, the subvi Load.vi was not actually being called as you had the case set to false and the vi in true.

I believe that this behavior should be expected as once a VI is called by another, it will remain open in that particular memory space thereby requiring fewer calls to the memory manager resulting in more efficient memory usage.  To be honest, I can not see the reason to do this.  If you are planning on using this VI over and over again, why not just open the ref at config time when the response is not time critical and therefore having the BD loaded already when you actually call run?  Just my thought.

Matt