How to control data scope of sub-vi of a reentrant vi?

[Matthew_Williams]

I would like to have a top level vi template (top.vit) that includes a sub-vi action engine (ae.vi) where

calls to ae.vi within a single instance of top.vit will share data but different instances of top.vit

will not corrupt each other's ae.vi data.  In other words, the scope of ae.vi's data is limited to the

parent's data space.

Is this possible?  I don't want ae.vi from different loops talking to each other, but ae.vi data must

persist across calls from within the same top.vit.  I have tried various combinations of reentrancy

for both top.vi and ae.vi without success.

Thanks.

Matt

[Ben]

Two idea come to mind.

1)

VI server Invoke node call by reference to get at the right AE for your vit.

2)

Toss the AE ( yes this Ben saying that) and;

a) Use LVOOP and create methods for each action you would have invoked on the AE.

b) Keep the data that you would have in the AE, in a SR of the vit and pass it to the LVOOP methods.

The second approach will keep the data seperate for each instance while the methods let you do everything you would have done with the AE.

now if your vit's are complicated and have many sub-VI trying to hit the same AE but you still want to keep them straight then a Singleton based on a Named queue that is derived from the vit name would fill in the gap.

Note:

The above is what I have kept stached away in the event anyone ever asks, so there obviously may be something missing.

Take care,

Ben

[Ben]

Running each vit from a sepearte project will create seperate address spaces as well.

How to create sepearte project to pull this off programatically...?

Can't say off hand.

Ben

[Matthew_Williams]

Thanks Ben.  I was hoping I was missing something simple.  The AE actually

has some NI sub-vis (not primitives) that I don't want to muck with, so I think

I'll back up a bit and try a little re-architecting.  Appreciate the pointers.  The

'reasons to LVOOP queue' is getting pretty deep.

Matt

[Matthew_Williams]

I was thinking something similar to the projects, use distinct executables.  Easy enough

to copy then trigger and expose via vi server.  Have to review the Rube Goldberg factor

vs. simplifying.  Thanks for the suggestions.

Matt

[TCPlomp]

Your question is exactly the basis for my 'One reentrant instance per parent VI' idea.

And much better explained.

Ton

[Matthew_Williams]

Yes!  What Ton said!  A reentrant setting for the top level vi that says 'make all data spaces from here on down restricted to this top level vi'.  That

way we can use things like NI library .vis as sub-vis in .vit instances without creating blocking or corruption issues.

Thanks.

Matt