Five equal parallel processes. Which structure should I use?

[TakeANap]

An state machine tests an electronic device. There are a few analog measurements and a few digital I/O to be handled. 
There are no high sampling rates or other special measurements. Each test ends up in a reject/approve module that writes a result to a file and perhaps lits a LED. 

In the application I gonna construct, five such processes should run simultaneously. There is no communication between them except for a common start. 

Which structural elements should I use?  I thinking, a simple while-loop with a case that builds up the STM. Then copy this one to four more places?

Perhaps there is a better way?

[JÞB]

Sounds like a good use case for launching a single "test.vi" n times from a Asynchronous Call By Reference using Call And Collect method.

Look into the Shipping Examples and there is an excellent project demonstration for that.

[GerdW]

Hi Nap,

---

@TakeANap wrote:

Perhaps there is a better way?

---

Well, that sounds like you should use TestStand and its "Parallel process model": no need to copy the test sequence!

🙂

[TakeANap]

Using teststand can be to much for me to grasp right now. 

However, you gave me a hint of what to study.

[TakeANap]

I surely will. Thanx. I think this a way forward. 

BTW, If I save the STM in a separate VI I need to save it with the VI properties set correctly. In the submenu Execution you have the Reentrancy setup. Non-reentrant, Shared Clone or Preallocated... what should I use?

I would have chosen Shared or Preallocated.  

I the end, this application ends up as an EXE-file. 

[JÞB]

---

@TakeANap wrote:

I surely will. Thanx. I think this a way forward. 

BTW, If I save the STM in a separate VI I need to save it with the VI properties set correctly. In the submenu Execution you have the Reentrancy setup. Non-reentrant, Shared Clone or Preallocated... what should I use?

I would have chosen Shared or Preallocated.  

I the end, this application ends up as an EXE-file. 

---

Assuming you are looking into the ACBR method.

The VI properties don't exactly apply in th ACBR but, I'll explain.  Those saved Execution properties apply for static calls.  An example being having a main vi that calls "MyVI.vi" twice.  Shared Clone reenterancy means they operate in the same dataspace so things like Shift Registers maintain the same data between calls. Shared Clones are needed for recursive operations and are useful to reduce memory footprint when there is no internal state information. 

Preallocated clones do not share that dataspace (and require more memory) Preallocated calls launch parallel processes.

With the ACBR you expressly prepare the vi properties using the flags input to the Open VI Reference function overriding the vi saved settings.  The example project demonstrates the correct way to prepare your vi for execution.

[avogadro5]

If you don't need the caller to return (the five "test.vi" instances can all block) it would be simpler to use a parallel for loop and normal reentrant subVI calls. No need for async/by reference.

[JÞB]

---

@avogadro5 wrote:

If you don't need the caller to return (the five "test.vi" instances can all block) it would be simpler to use a parallel for loop and normal reentrant subVI calls. No need for async/by reference.

---

That would launch 1 Clone n times sharing dataspace.  You would need to launch vit instances in your loop. But that has real downsides..  It is not independently scaleable since Labview is going to request a group of threads and you have no control over how many parallel loop iterations launch per clump and the launch is very slow!

Of course, that type of call behavior is exactly why the ACBR was added to LabVIEW to replace launching vits. Vits must create their dataspace when called rather than preallocating them in a Clone pool of any size >= # of cores with the PreAllocateClones method.. And ACBR nodes have the ability to wait for completion, fire n forget, or call and collect.

[avogadro5]

---

@JÞB wrote:

---

@avogadro5 wrote:

If you don't need the caller to return (the five "test.vi" instances can all block) it would be simpler to use a parallel for loop and normal reentrant subVI calls. No need for async/by reference.

---

That would launch 1 Clone n times sharing dataspace.  You would need to launch vit instances in your loop. But that has real downsides..  It is not independently scaleable since Labview is going to request a group of threads and you have no control over how many parallel loop iterations launch per clump and the launch is very slow!

Of course, that type of call behavior is exactly why the ACBR was added to LabVIEW to replace launching vits. Vits must create their dataspace when called rather than preallocating them in a Clone pool of any size >= # of cores with the PreAllocateClones method.. And ACBR nodes have the ability to wait for completion, fire n forget, or call and collect.

---

I don't understand why a vit would be needed (assuming this refers to a template vi). When I call a reentrant, blocking subVI in a 5-instance parallel for loop I get all 5 at once.

[JÞB]

You are tricking yourself.

Stick a USR in your subvi and watch the dataspace collapse.   Of course 5 calls to create new panel creates 5 new panels. 1 CHUNK worth at a time and in any order.  With debugging off.

Another example that would demonstrate the dataspace sharing would be to simply drop the dice, PRNG, into a For loop.  Given the Same initial SEED, the loop generates the same PRN Values parallel or not.  But the Order is dependent on which calls start first because the PRNG holds internal state information on an internal SR (usually initialized by manipulation of mSec clock tick count on first call)  That nifty piece of trivia is actually WHY you get a compiler warning when you drop the dice in a parallelized loop