Sequenced Parallel Loop Startup

[skol45uk]

Hi

I have a number of VI's that never return once called. They are each, effectively, separate but cooperating processes.

In order to keep things clean, I would like to start these parallel processes in a certain sequence.

How can I do this?

The problem is that if a VI does not return, a sequence-structure cannot move on to its next frame. But by design these separate VI's will not return.

Any ideas?

Thanks in advance.

[Kyle97330]

Asynchronously Calling a VI without Collecting the Results

Try that for each VI, possibly with a time delay between each one to allow them time to start up?

[Bob_Schor]

Let's assume that all of the sub-VIs you want to start have an Error In terminal.  Let's also assume that you want to start them first.  Finally, let's assume you want to start them "all at once".

• Arrange all of the sub-VIs in a vertical column.
• Take your starting Error line and wire it to all of the Error In terminals.  Do not wire anything to the Error Out terminal of any of these sub-VIs.
• Branch your starting Error Line to wherever it needs to go in the rest of your code.

Recall that LabVIEW uses Data Flow to determine order of execution.  Because the Error Line goes to (a) sub-VI before it goes to the rest of your Main, the sub-VI will start first.  Because the sub-VI outputs are not connected, nothing else has a Data Flow "dependence" on them, so they'll all try to run "at the same time" (and LabVIEW will do a pretty good job of making this happen).

Another way to do this is to use Start Asynchronous Call to individually start a sub-VI running "asynchronously" (meaning "not tied, timing-wise, to the calling VI").  I use this method, as it keeps my block diagram a little neater and has a few more "bells and whistles" that I occasionally exploit.

I didn't point it out, but I assume you can see how to use the first method I mentioned above to start an individual VI at some other point in the program (just keep it out of any loops, and don't wire its outputs), and how to stagger their starts (put a delay, in a frame, if necessary, before calling them).

Bob Schor

[johnsold]

Send commands to the subVIs via notifiers or queues telling them when to start processing. They will actually start running as soon as possible but the parts of the code which muct occur in sequence will wait for the command. The main VI can use time delays or a simple state machine to define when to send the start commands.

Lynn

[Ray.R]

I would have implemented what Lynn suggested.  You can also do a search on Dynamic VIs.

[altenbach]

---

@skol45uk wrote:

I have a number of VI's that never return once called. They are each, effectively, separate but cooperating processes.

In order to keep things clean, I would like to start these parallel processes in a certain sequence.

---

What is desired time delay between the calls (nanoseconds? hours?) Define what you mean by "clean". Maybe you are apporaching this from the wrong side.

If the processes are coooperating (your words!), they simply need to be designed in a way that the startup order does not matter at all. Can you define the kind of "cooperation"? How are the aware of each other's current state?

[skol45uk]

The delay between VI starts is kindof not my issue. I could put delays in somehow if I needed pauses.

The resilience of the VI's to each others existence (or not) is not the issue either.

Its more the real-time responsiveness.

If a producer is started up before a consumer, the producer may fill up a queue (say) and the poor old consumer will have to catch-up.

The consumer could flush the queue before getting into its main function, but that seems to be a means of compensating for just starting the consumer first, then the producer (as it should be).

What I am fishing for is a simple way of ordering the startup of VI's that do not return.

I was looking at the Stacked & Flat Sequence Diagrams, and I was hoping for something along those lines.

I could use the Asynchronous Startup approach, but it just seems awkward.

Given parallelism seems to be a very strong part of the LabVIEW paradigm, it seems a shame that some things like this are "difficult".

Thanks everyone for your help.

[altenbach]

You could just place each VI inside a single small sequence frame and wire the output of a wait to the edge of each seq8uence. The value of the wait will determine the order of starting. Still, this entire thing seems fragile.

[Gregory]

---

@skol45uk wrote:

The delay between VI starts is kindof not my issue. I could put delays in somehow if I needed pauses.

The resilience of the VI's to each others existence (or not) is not the issue either.

Its more the real-time responsiveness.

If a producer is started up before a consumer, the producer may fill up a queue (say) and the poor old consumer will have to catch-up.

The consumer could flush the queue before getting into its main function, but that seems to be a means of compensating for just starting the consumer first, then the producer (as it should be).

---

It sounds like you can just wire the same error line into both SubVIs. Sure, you don't "know" which one started up first, but if you've designed your producer/consumer correctly then the queue will not fill up.

Have you tried this already and ran into some problems? The producer should be creating bursts of information which the consumer can work through and eventually get down to 0 information waiting in the queue.

[Ray.R]

---

@skol45uk wrote:

What I am fishing for is a simple way of ordering the startup of VI's that do not return.

I was looking at the Stacked & Flat Sequence Diagrams, and I was hoping for something along those lines.

---

If I understand what you are trying to accomplish, I've implemented many such solutions.  The use of Flat or Stacked Sequences is not the way to go.  As a matter of fact, it may make things worse.

If I understood correctly, you have multiple processes that may start at different times, but some depend on others, such as a Producer in a Producer/Consumer arrangement.  If the processes may or may not be used, or may be triggered by certain events, you should consider Dynamic VIs.  You can pass values by tokens or queues depending on if one or more are to be passed/processed by the consumer loop at any given time.  To "coordinate" the start of the producer loop to provide or queue data, you can use a semaphone which will let the consumer or producer loop know that its adjacent loop is ready to send or receive data.

If it wasn't so late, I would write a quick example, but I am sure I've posted a few in the past.