LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Running background VIs without halting the calling VI

That's pretty clever, Micah. I'll have to give it a try next time I want to do that. I never really tried to come up with a way to do it. I just figured since it wasn't built in, there was a good reason. Maybe NI will add an option for running a sub vi like this in the future.
0 Kudos
Message 11 of 28
(2,050 Views)

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

0 Kudos
Message 12 of 28
(2,046 Views)
Dennis' answer about the VI server "Run VI" method is the one I recommend. It allows programatically loading a VI, setting it's run-time variables and then running it.  It's like manually opening a VI, initialising the FP and running it, just done programatically.

This VI then runs in the background fully de-coupled from the main VI.  You can even stop the main VI without affecting the background task.

Attached is a LV 6.1 VI which demonstrates this.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 13 of 28
(2,033 Views)
Yes, that makes sense. However wouldn't it be nice to be able to place a sub vi normally in a diagram, pass it values through wires, and simply check a box that set it running in the background if it didn't return any values?
0 Kudos
Message 14 of 28
(2,018 Views)

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.

 
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 15 of 28
(2,015 Views)
Thanks everyone, it's been good to see some useful and thoughtful discussion about this.

I can see the usefullness of Marc A's comments, it would be great if we could just 'tick a box' to set subvis as background vis, but as this option isn't available yet, I'll have to use the example as shown above, calling using VI references.

Thanks all!

Riggy
0 Kudos
Message 16 of 28
(2,014 Views)


@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.
0 Kudos
Message 17 of 28
(2,009 Views)
Wow that got some discussion going.  In the subvi you want to call, you have to change the execution type to "allow reentrant execution".  At least that's what got it to work for me.  I think this method is also a bit simpler than using a whole bunch of variant stuff mostly because I am lazy.  I think you can also stop the main VI and the subvi should keep running.

One strange thing...  If you double click on the subVI in the blcok diagram, it actually opens a clone of the subVI.  You have to double click on the reference to open an editable copy of the subVI.

Micah
0 Kudos
Message 18 of 28
(1,998 Views)

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.  I've had some limited success with a different method that's more of a pain in the neck, and would like to find a better way.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 19 of 28
(1,978 Views)
It certainly isn't working for me Kevin. Both instances run correctly, but when I call the reentrant dynamically, it doesn't have the value that I passed it previously.
0 Kudos
Message 20 of 28
(1,971 Views)