How to call a reentrant subvi for each member of an array parallel.

[Elktro]

I have a subvi A which takes as an input an arbitrary sized array of double values. The subvi A calls a subvi B which is a reentrant.

Now I would like to call the subvi B for each double member of the input array. This would be no problem if I could use for loop.

However I want call the subvi B for each double member simultaneously. The subvi B has an output value.

A parallel for loop could be a solution, but that is only available in LabVIEW 2009.

Is there anyway to do this with labVIEW 7.1? Sounds something that could maybe be done with dynamically called subvis, but Is there any neater way?

[PaulL]

Are you sure there is no way VI B can't operate on the array?

If not then I think you will have to put n instances of B on A's block diagram. (This is annoying and even more trouble since you don't know the array size ahead of time. If you at least can bound the array size you can use case structures, but this is ugly.) If there is any way to operate on the array that is the way to go!

[mje]

I'd be surprised if a parallel loop would be ideal for this case since you can't define the array size.

I'd use VI Server to launch up to N versions of the VI asynchronously. SubVI A takes the array, iterates on each element. Each iteration opens a reference to the VI, supplying the proper argument to prepare it for re-entrancy (Options |= 8), sets the appropriate control values via an invoke node, then the VI is started (also via an invoke node) instructing it to not wait for a return. Return values could be handled via a queue, which SubVI A would have to properly reassemble in the correct order before it returns.

Ugly? Depends on your point of view. The only thing I don't like about this method is how you have to pass parameters by setting control values via an invoke method. Slow and clumsy, I don't know how well it would work in a tight loop. What I've always wanted was the ability to do stuff like this directly via the Call By Reference primitive, but that can't handle asynchronous calls.

[Rolf Kalbermatter]

I'd be surprised if a parallel loop would be ideal for this case since you can't define the array size.

I'd use VI Server to launch up to N versions of the VI asynchronously. SubVI A takes the array, iterates on each element. Each iteration opens a reference to the VI, supplying the proper argument to prepare it for re-entrancy (Options |= 8), sets the appropriate control values via an invoke node, then the VI is started (also via an invoke node) instructing it to not wait for a return. Return values could be handled via a queue, which SubVI A would have to properly reassemble in the correct order before it returns.

Ugly? Depends on your point of view. The only thing I don't like about this method is how you have to pass parameters by setting control values via an invoke method. Slow and clumsy, I don't know how well it would work in a tight loop. What I've always wanted was the ability to do stuff like this directly via the Call By Reference primitive, but that can't handle asynchronous calls.

The Open VI Reference function is a very bad function to call in a tight loop. Don't do that ever as it needs to execute in the UI thread and will slow down your loop tremendously.