Is it possible to run a subVI in parallel with the caller VI?

[Riggy]

I have a front panel VI which calls numerous subVIs, one or two of which I would like to execute simultaneously with the calling VI. The front panel has time-dependant operations which are being prevented from running because it is waiting for the subVIs to finish, even though no data is required from them.
Is it possible to call these subVIs such that they run silently in the background allowing the front panel to execute unhindered?
I've looked at the Synchronisation features but is this what I need?

[LunaBlue]

You can use for exsample two while loops running parallel. One for
calling the sub vi's, the other one for your time dependent operations.

Niko

Riggy wrote:
> I have a front panel VI which calls numerous subVIs, one or two of
> which I would like to execute simultaneously with the calling VI. The
> front panel has time-dependant operations which are being prevented
> from running because it is waiting for the subVIs to finish, even
> though no data is required from them.
> Is it possible to call these subVIs such that they run silently in the
> background allowing the front panel to execute unhindered?
> I've looked at the Synchronisation features but is this what I need?

[Riggy]

Hi Niko,

If you put two while loops in parallel (i.e. side by side) on the diagram, they do not run in parallel, but one after the other. The while loop containing the subVIs will not finish until those subVIs have completed, and the second while loop does not execute at the same time as the first, but before it (or after it, depending on their relative positions in the diagram).
I have since inspected the NOTIFICATION features of LabVIEW. It seems subVIs can be caused to operate simultaneously, so with these I can execute the subVIs and still have the front panel running simultaneously.

Riggy

[Dennis_Knutson]

They DO run in parallel unless you have some sort of data flow connecting them. It also doesn't matter about the relative position of the two while loops on the diagram. What you've just stated is just the opposite of the whole LabVIEW design. See the attached example. If you don't like the parallel while loop idea, look into calling the subVI dynamically. Using VI Server, you can easily open and run a subVI without causing the main VI to pause.

[shoneill]

It's also very important to mention that the whole multi-threaded execution CANNOT be reliably observed in highlighting mode in the LabVIEW development environment. You need to let the VI run full-speed to see this.

Highlighting (to the best of my knowledge) forces single-threading, or acts like it does.

Shane.

[Riggy]

In all my experiences writing LabVIEW codes I've always found it impossible to get sections of code to run in parallel. For example, if I run a subvi, even without requiring any data from it, the rest of the caller's code halts until the subVI has finished.
I am using LabVIEW 6, does that make any difference? (Also this means I'm afraid I couldn't run your examples because they are LV7.0. Could you post them again in LV6 at all?)
I'm intrigued by this.... I wonder where I've been going wrong all this time.

[Dennis_Knutson]

Here's my simple example in 6.0. When you call a subVI normally, then yes, it does pause the main if the main only has a single while loop. Any code in a separate while loop will continue to execute though. Besides the two separate while loop method, the other technique is to start your subVI with VI Server as I mentioned. You use the Open VI Reference and then an Invoke Node with the method Run VI with a Wait Until Done set to false. You can pass and get values from a VI using the methods Set Control Value and Get Control Value.

[Riggy]

A profuse apology follows:

In all my time writing LabVIEW codes the multi-threading capability has been something I have always failed to achieve. I created the example described by Nikolai Maris and was astounded to see a subVI running simultaneously with the caller VI.
I was adamant that this was not a possibility but retract that statement and accept that I have been sorely mistaken.
I must now state that I am confused 😉
Is it very easy to position subVIs in such a way that they may not allow multi-threaded operation? I can only guess that all my previous codes have been written in such a way as to prevent this somehow.

Thank you all for your responses.

Richard Thomas

[Riggy]

Thank you, these vi's solved my query 100%.
I'm new to the VI Server capability, and shall study it in detail.
I would rate your answer 4 star but the ratings option seems not to be there?
Thanks again 🙂

Richard Thomas

[rolfk]

shoneill wrote:

> It's also very important to mention that the whole multi-threaded
> execution CANNOT be reliably observed in highlighting mode in the
> LabVIEW development environment. You need to let the VI run
> full-speed to see this.
>
> Highlighting (to the best of my knowledge) forces single-threading, or
> acts like it does.

This is simply a convinience by LabVIEW since humans are inherently
non-multi treaded. What you will see in parallel loops and which can
still be distracting is that LabVIEW seems to randomly switch between
different parts of your diagram. In fact this is also what is happening
in normal execution but the execution switch is so fast (each individual
operation typically taking microseconds it
seems they execute in parallel.

The nice part of LabVIEW since version 2.0 somewhere around 1988 already
is, that it provides this seemless multithreading on every single
platform even if the underlaying OS is not multithreading capable at all
(Win3.1, MacOS).

Rolf Kalbermatter