08-04-2010 10:27 PM
In LabVIEW 2009, can a sub-VI of a reentrant VI contain a reentrant sub-VI?
I have heard the sub-VIs of reentrant VIs should not be reentrant, but nothing is said about lower levels in the hierarchy.
I have an application that has significant replication of functionality. Many of the components that are replicated should be reentrant so that each call runs in its own memory space. Unfortunately inside those is some functionality implemented as sub VIs that are also replicated and should run as reentrant.
Example:
S1 S2 S3 S is reentrant
| | |
B B B B is not reentrant
/ \ / \ / \
P1.1 P1.2 P2.1 P2.2 P3.1 P3.2 P is reentrant
Is this possible? What is a better way to construct this?
Why can't sub-VIs of reentrant VIs be reentrant?
08-04-2010 11:24 PM
There's nothing preventing you from making any subVI reentrant (unless the VI needs that functionality). It's simply a tradeoff between parallelization (so your code might run faster) and resource allocation (RAM, etc., which might hurt your performance).
08-05-2010 07:55 AM
Yair's comments are correct.
Prior to LV 8 that restriction was valid. Since LV 8 we can now mix re-cursive calls.
In my Control Reference Nugget found here I posted some example code that exploits this ability.
I wanted to be able to handle arrays of clusters within cluster within arrays ... lal la la...
Sine I did not know the structure of the data at development time I wrote code to handle array and clusters sepearately so that the cluster parser could call itself to handle a sub cluster. Of course we can do arrays of arrays but the array version is similar.
JP Drolet pointed this feature out in post number 49 of that thread.
Have fun,
Ben
08-05-2010 08:09 AM
Ben wrote:
I wanted to be able to handle arrays of clusters within cluster within arrays ... lal la la...
I had to draw this out to understand...
08-05-2010 08:26 AM
Just see figure 15 from that Nugget.
Ben
08-05-2010 09:26 AM
Of course, one issue that you're going to have with the setup shown in the example is that the B VI is not re-entrant, so the higher level VIs would be effectively blocked at the B calls.
08-05-2010 09:51 AM
@smercurio_fc wrote:
Of course, one issue that you're going to have with the setup shown in the example is that the B VI is not re-entrant, so the higher level VIs would be effectively blocked at the B calls.
Good catch!
I just saw LVOOP throw a recusion detected error a couple of weeks ago for that same issue when a child method was calling the parrent while it was still running and was the the original caller in the first place.
It waws a bad day for the Fuzz Bear until after I figured how to make it work.
Ben