Running background VIs without halting the calling VI

[Riggy]

Hi all,
 
I've been programming in LabVIEW (currently using 7.0, 7.1 and 8.0 on three different machines!) for a few years and am having trouble working out a quick and simple methodology for programming the following requirement:
 
I have a VI which acts as a front panel, from where a user can call up other VIs that perform certain operations. On this front panel are a series of indicators which need to be constantly updated at a rate of approx' twice a second. The problem I have is: if a subvi is called, the calling vi (front panel) halts until this subvi is finished. However, the subvi makes changes to some of the values that the front panel displays, so the front panel must not freeze otherwise the indicators will not be updated. I know there are ways of calling subvi's by reference, and flagging the Do Not Wait for this vi boolean such that it then runs in the background in parallel, but there must be a simple way of coding the "frontpanel.vi" diagram so that it keeps updating regardless of running subvis?
 
Attached is an example of what I mean.  The values are updated to a Global, and the front panel reads the global every 500ms. When the subvi OperationA.vi is called, the front panel halts, and hence the changing Global value is not updated on the front panel indicator. This attachment is a LV 7.0 library. If anyone makes changes, please export as 7.0 if possible. I do have access to 7.1 and 8.0 on other machines if necessary.
 
Any help much appreciated :smileyhappy:
 
Many thanks,
 
Riggy
 
 


Update_demo.llb:
http://forums.ni.com/attachments/ni/170/220909/1/Update_demo.llb

[Riggy]

Hi Marc A,
 
Would this still halt the front panel vi? :smileyindifferent:
 
Plus I have about 50 indicators for many different things, it would a nightmare to send them all as references into each and every subvi I create.
 
Thanks for your advice :smileyhappy:
 
Riggy

[Marc A]

Yes, the front panel would still halt operation, but you can change the values of the controls without any code running in the front panel by using references. I understand what you mean though about having a lot of them. The other option is to use globals like you are doing, but calling the subvi dynamically so that it starts to run and your main VI continues to run as well. Although I wouldn't personally go this route if it's just for updating front panel controls. I try to avoid globals as much as possible.
If you aren't familiar with calling VIs dynamically, it's done by using Open VI Reference, then using an invoke node to call the Run VI method. Then just wire false to the "wait until done" input.

[Riggy]

Hi Marc A,
 
Again, thank you for your advice. Yes, I am beginning to see that I will have to do this, or somehow try using dynamic linking (as you describe). I will think on this overnight, and get on with some hard re-coding tomorrow :smileysad:
 
Thanks again,
 
Merry Christmas!
Riggy

[Marc A]

Good luck to you.
I have come to certain situations where I want to do exactly what you want. I have wanted to do it so that I could pass inputs to a VI by wire but have it run dynamically, however I never found a way to do it. I figured that if the subVI didn't return any values, there should be a way to have it run in the background.
Maybe we'll see this feature added at some point, but there might also be something that I'm not aware of which would create problems.

[Riggy]

Hi RExlter,
Thanks for the advice. In truth my application is far more complicated and parts of my code already use dynamic linking to call certain subvis and leave them running in the background on an internal loop without waiting for them to finish. These background subvi's constantly take measurements and monitor switches to ensure certain criteria are met etc. to allow the code to continue. Unfortunately, I don't want OperationA, as shown in my attachment, to be called this way if I can help it - which is why I was hoping there would be a simple method I hadn't thought of for calling it and continuing the main code. It seems I may have to re-write all the code to do either what you suggest or what MarcA suggests.  I'll think about it and work out what will be best.
Many thanks everyone for your assitance!
Best wishes,
and Merry Christmas!
Riggy

[Dennis Knutson]

I'm not sure where this discussion is going. The simplest way to run a subVI and not have the main VI pause is to simply have the subVI in a separate while loop.
A bit more complicated is the Run VI method and it's pretty simple to pass values to controls and get results while the VI is running without using globals variables, local variables, a modified subVI, or a special case statement. Along with the run VI method, there are Set Control Value [Variant] and Get Control Value [Variant].

[Kevin Price]

So in your main program, first call the subvi with Init set to true, and all of your variables wired to pass the data.  This sets the control values, but returns immediately.  Then create a reference to the VI and use the "Run VI" method with "Wait Until Done" set to false.  Then the subvi will run in the background with all the data you passed, but the main program will continue as nomal.  This works for me.


Micah,
Is this method really possible?  Is it something new in version 8.x?   I don't think this is possible in version 7.x.  If there were any "wired" instances of a vi in the block diagram, I found it impossible to dynamically run that same vi with an invoke node (the only method that supports WaitUntilDone = False).
-Kevin P.
 

[Marc A]

Kevin Price wrote:
Micah,
Is this method really possible?  Is it something new in version 8.x?   I don't think this is possible in version 7.x.  If there were any "wired" instances of a vi in the block diagram, I found it impossible to dynamically run that same vi with an invoke node (the only method that supports WaitUntilDone = False).
-Kevin P.

Actually I'm on 8.2 and I can't get it to work. The invoke node gives an error saying the VI is not in a state compatible with the method. I check the state before Run VI is called and it returns "running" even though the sub VI is not actually running.

[Kevin Price]

I'm curious now.  I've never tried using a static vi reference to call an invoke node before.  I know that separate instances of a reentrant vi on a block diagram actually become separate unique functions, so initializing one and then calling another wouldn't work.  I also know that separate calls to VI Server to open references to a reentrant vi will also generate references to 2 separate instances of the vi.  But I've never tried what you did in your screenshot.
Have you been able verify that the same instance runs in both frames of your sequence?  How?
I'm very interested in this sort of technique -- the ability to both send data through terminal wires AND launch the vi dynamically without waiting for it to run to completion.&nbsp; I've had some limited success with a <a href="http://forums.ni.com/ni/board/message?board.id=170&amp;message.id=144497#M144497" target="_blank">different method</a> that's more of a pain in the neck, and would like to find a better way.
-Kevin P.

[Kevin Price]

I'd like to know too.&nbsp; It has always seemed like such a kludge to have to make a bunch of calls to Set Control Value followed by a call to Run without waiting for completion.&nbsp; It'd sure be nice to have the best of both worlds&nbsp;where I could launch a parallel-running dynamic vi using wired inputs without having to wait for completion.
-Kevin P.

[napview]

Same here:smileywink: because of the limits of the physical&nbsp;viewing size of the computer monitor&nbsp;when set even at&nbsp;highest visible resolution, the diagram of a very big program would be very messy. So there would be a lot of use of sub VIs and the calling (or the main) VI often needs the real time (at least) updated variable values being passed from those sub VIs.&nbsp;The use of reference call, so far only this approach works:smileysad:, becomes very messy.
&nbsp;
It will be very NICE if NI can create a function pallete to embrace this important need for LV users. Basically this pallete has an input for the calling VI name with proper path, and another one for the sub VI,&nbsp;one or more&nbsp;input&nbsp;clusters with mixed data types (same for output clusters) that can be passed to the calling VI in real time or instantly.
&nbsp;