Multiple instances of VI with uninitialized shift registers?

[Gregory]

Is there a way to easily run multiple instances of a VI that uses an uninitialized shift register? Take the Mean Pt by Pt function, for instance. If I want to keep a running average of 1 numeric data, I just put the VI in a loop and run it. If I want to have 2 numeric data, I just change the VI settings to "Preallocated clone reentrant execution", and copy the VI below. Now if I want to have 5 numeric data, it starts to take up a bit of real estate on the block diagram. I can put it in a For Loop with a case structure that changes each iteration. It is easy to make these cases, just duplicate the "0" case. But, if I decided to add something to the "0" case, or something is a teeny bit different in each case, then it becomes a real pain to do it this way. Is there a better way to handle this?

Edit: I realized that if something changes each iteration, I will either have to re-think my datatype or continue to use a case structure. But, if we could solve the first problem where I don't have to propagate a change from the "0" case to all other cases, that would be great!

Thank you!

[RTSLVU]

I do not understand your question nor I do not see any shift registers at all in your example.

But if you are worried about taking up space on the block diagram, just make it into a sub-vi.

[Sam_Sharp · Accepted solution]

Use the Call By Reference node where you open N VI references to your MeanPtByPt VI - each instance will then be a VI reference which will maintain it's own memory space.

Something like this:

Using the 0x8 flag means that each VI reference coming out of the open reference has its own data space. To be honest, you might need the 0x40 flag instead/as well - but I can't remember off the top of my head.

[altenbach]

If there are not too many, you can use a parallel FOR loop set to N parallel instances.
You can use the instance ID to Identify.

[Sam_Sharp]

Here's a working example to show the difference (and that it works!):

Of course, you would probably do something like index a single reference out of the VI references.

[Gregory]

Sam: Great, thank you for the help and example! Edit: Also I think you can put an array into "Close Reference" if you didn't know

altenbach: Can you explain your suggestion "You can use the instance ID to Identify."?

[Sam_Sharp]

---

@Gregory wrote:

Edit: Also I think you can put an array into "Close Reference" if you didn't know

---

I did know, but I had forgotten

[altenbach]

---

@Gregory wrote:

altenbach: Can you explain your suggestion "You can use the instance ID to Identify."?

---

You can right-click the parallel FOR loop and output the instance ID to make it available to the loop code. The main advantage is that several loop iterations can run in parallel, potentially speeding things up.

Personally, I would probably do my own single instance non-reentrant subVI that operates on the array directly. (Here is an example for a "multichannel mean ptbypt", but of course I assume you want to do some other computations)

[Kevin_Price]

As far as I've been able to figure, you have to do it the way Sam_Sharp illustrated.  This is one of those exceedingly rare cases where I'm doubtful of advice from altenbach, who said:

If there are not too many, you can use a parallel FOR loop set to N parallel instances.
You can use the instance ID to Identify.

I believe there's an important problem with this approach, given the kind of thing you're trying to do.  One of your inputs into the loop is an auto-indexing array of values.  You want to be sure that every time you come into this code, the value from index 0 of the array gets fed into the *SAME* reentrant instance of subvi inside the For loop, i.e., reentrant instance #0.  

The parallel instance # of the For loop isn't going to help you accomplish this.  Here's a pretty involved thread I got into when wanting to do a pretty similar thing.  In that thread, here's my posting of a snippet of test code to help illustrate.  The idea of the simple test code is to see whether the Parallel Instance # can reliably be used to repeatedly select the same item from a set.  It can't.  I make an array of ordered integers and extract values using the Parallel Instance #.  Not only do I not see every value get extracted (?!!!), but the sequence of the instance #'s changes from run to run.

If I were instead selecting from a set of reentrant subvi instances, they too wouldn't be selected in the same sequence each time.  Thus the state you're trying to maintain in their USR's would get cross-contaminated.  This is exactly the symptom I experienced when first trying to use Parallelism on a For loop in order to instantiate N duplicate instances of a reentrant subvi containing USR's.   The test code is just a simpler illustration of the same idea.

In sum, your problem (like mine) demands consistent correspondence between a specific reentrant instance's dataspace and the iteration # of the For loop.  The Parallel instance # will *not* consistently maintain such a correspondence.  The method Sam_Sharp illustrated is essentially the same as what I settled on too.  Note that the 0x08 code is exactly correct for opening a VI ref to a unique reentrant instance of the subvi.  0x40 doesn't apply.

-Kevin P

[Gregory]

Altenbach: I see, thank you for the clarification.

Yes, right now the VIs that I inherited for the algorithm are very messy and I'm kind of taking the "ain't broke don't fix it" approach. But, if I do get time to refactor into a single VI that would be desirable!