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

[imtisal]

Hello,

This is very helpful for me. But, I have one question, I want to get the data from the called VI (That one running parallel to main VI) to the main VI , like , its also keep executing and keep providding data to main loop (Somewhat like FEEDBACK loop).

Kindly, help as soon please.

[billko]

I thought that one of the highlighted features of LV 7.0 was multithreading?  Maybe LV versions eariler than that didn't run in parallel?  I don't really know because I've never used LV earlier than 7.1.

[stevem181]

Hi Imtisal,

-------------------------------------------------------------------------------------------

This is very helpful for me. But, I have one question, I want to get the data from the called VI (That one running parallel to main VI) to the main VI , like , its also keep executing and keep providding data to main loop (Somewhat like FEEDBACK loop).

Kindly, help as soon please.

--------------------------------------------------------------------------------------------

There are several ways to send data from a subvi to a main vi (Queues, Action Engine, Notifiers, User Events, DVRs)

User Events are a good choice If your main vi has an Event Structure.

In this example, the lower loop represents your "called VI".

(This is a LabVIEW 2015 snippet. Save the image then drag it onto a block diagram to get the code.)

steve

[imtisal]

In this case... If the lower vi is FEEDBACK vi then it will keep running while the main vi is running.

[stevem181]

> In this case... If the lower vi is FEEDBACK vi then it will keep running while the main vi is running. 

I would call the lower loop a Producer Loop. It could be made into a subvi.

In any event, it runs in parallel with the main vi and every 100 ms

it will send Data to the main vi.

steve

[Bob_Schor]

The short answer to your question "Is it possible to run a subVI in parallel with the caller VI?" is "Yes, I do this all the time."

The trick to doing this is to avoid data dependency.  Your sub-VI cannot depend on data produced by its caller.  I think others have discussed having two VIs running in parallel While loops, but if I understand your question correctly, you want Caller VI to say (at some point) "OK, subVI, start running but don't depend on me directly for anything, so we can "share" CPU time and run at the same time, in parallel".

The way I do this is via Start Asynchronous Call, found on the Application Control Palette.  You wire a reference to the VI you want to run to it, and it starts it running in its own memory space, "disconnected" (as it were) from its caller.  Note that this has some implications, including that it can keep running even if the caller VI stops (so you have to have a "stopping mechanism").

Here's how I set this up.  The steps I'm showing here I usually "bury" inside a sub-VI, so in my Caller VI, there's only a little 32x32 pixel box that says "Spawn Event Spooler", or something like that.  So in this case, I have a sub-VI called Event Spooler that I want to start and have run asynchronously (meaning "in parallel with") the caller.  It has a single input, a reference called DIO Refnum.  Here's the relevant code (the functions shown are all on the Application Control Palette):

1. The first thing I do is drop a Static VI Reference.  I right-click it, choose Browse for Path to find the Event Spooler VI (note that having an Icon for this sub-VI makes the code "self-documenting"), and click it.  See the Red Star on top?  That's because I then chose to make this a Strictly Typed VI Reference (another right-click option).
2. Next, drop a Property node on the Error Line, and wire the Strict VI Reference to it.  Select the Name property.
3. Next comes Open VI Reference.  Wire the Name to the VI Path input, wire type VI Reference (which now contains Type information) to the Type Specifier input, and wire Option 80 (Call and Forget), as shown.
4. Finally, drop the Start Asynchronous Call function on the Error Line and wire the VI Reference to it.  When you do, it will adopt the input connections of the Called VI -- wire any required inputs at this time.
5. When your code executes this series of commands, the Called VI, here Event Spooler, will start to run, but in its own memory space, so it will not "block" any other action of this calling routine.

We've had programs where multiple sub-VIs were spawned.  In one instance, we were taking videos of animal behavior and had 24 video stations available to us.  We typically spawned 2-4 sub-VIs per station -- they all co-existed quite happily.

Bob Schor

[mikeporter]

This article goes into a bit of detail on how to do what you want:

http://www.notatamelion.com/2014/10/07/build-a-proper-labview-produceconsumer-pattern/

Mike...

[imtisal]

Thanks for such a great trick. I understand it but have little confusion.

I have attached the picture and I explain in this way.

There are two sub vi's running in the FOR loop. The loop executes 128 times (for 128 pixels). but when the MOVE Y sub vi executing, the feedback is waiting for MOVE Y sub vi to fnish its execution so that FEEDBACK execute. which is not the purpose of FEEDBACK as it should be independent of any subvi. What I am thinking that FEEDBACK loop should be outside of FOR loop but need little help how can I do this.

kindly help me.

Imtisal

[altenbach]

First you are adding to a 12 year old thread with a question that still makes very little sense to me. Now you are attaching a picture of a diagram fragment peppered with local variables, coercion dots, and unknown subVIs. We need more to help. Where does the data come from? Where does it go? What else is there? If the two subVIs should run asynchronously, maybe use two FOR loop instead, one for x and one for y. 

The word "feedback" (as e.g. in "feedback node") has a very special meaning in LabVIEW, but you seem to be talking about about your own subVI when you use that word capitalized. Why that name? What is is feeding back to where exactly?

Please attach your VI and subVIs so we can get a better feeling what you are actually trying to do. Why don't these subVIs not return immediately to the calling VI? What are they actually doing?

Thanks.

[imtisal]

Hello Sir,

I am glad to have a response from your side.

Let me give a little introduciton what I want to accomplish.

I am working on ATOMIC FORCE MICROSCOPY in which the motion on micron scale is required to scan the surfce. I am using the tubescanner to make motion on micron scale.

When scanning the surface of sample, the tip (of AFM) should have maintain the constant distance from the sample (using feedback loop). For that purpose, feedback loop should work independently. 

I want to run the FEEDBACK loop (attached) work independent to MOVE Y subvi.

If the distance is large as comapred to the setpoint, FEEDBACK adjust its height to get closer to sample and the value (how much Z axis is moved) is recorded to plot.

Its like the RASTER SCAN along XY direction and Z is the height in feedback loop.

The MOVE Y sub vi simply make motion along Y axis with the step provided to CY.