Are reentrant VI dataspace instances static or dynamic?

[SPM]

Hi, all,

Still looking at the good ol' LED blink detector issue. Another member posted a solution that depended on shift registers to store the times when the LED changed state. This works fine for monitoring a single LED (after some debugging). But if put multiple instances down to monitor multiple LEDs, the last-change times in the shift registers are screwed up. The symptom is that, if any LED is in a different state than the others, all of them are sensed as blinking.

I've tried changing the blink detector VI to reentrant, but it looks like the dataspace is getting created dynamically (every time the VI is called) rather than statically (one dataspace for every descendant of the root VI.) Also, any initialization of the shift registers looks like it's happening on every invocation of the VI. Do I have this correct?

If so, is there any way to bind the dataspaces to static instances rather than dynamic ones, as described above?

Thanks,
- Steve.

[MikeS81]

Hi Steve,

if you want to use a shift register as a buffer (action engine), then you can´t make the vi reentrant. See the attached picture. Can this help you?

Mike

[TCPlomp]

For LabVIEW 8.5 there are three kinds of data-space.

Traditional non-reentrant
This is essentially everywhere the same VI and data-space

Shared clones
This reentrant setting calls at will a new data-space into memory, they are fast but the existence of the data-space can be shared.

Private reentrant
This reentrant setting allocates for every location a new data-space so you can use shift registers

All these settings are done in the VI Properties->execution dialog

Ton

[SPM]

Problem (possibly) solved!

Solution was:

• Every ancestor VI with multiple instances also has to be made reentrant (this shouldn't have to happen, according to the way I read the documentation, but it does.)
• Initialize using a "First Call" VI and a case block inside the loop rather than initial values outside the loop (this might not be necessary.)

Hoping this might help some other learner of the ropes,
- Steve.

P.S. to Mike: I'm not sure what you're getting at with your example, but I need to maintain one buffer per (static) instance of the VI -- and the above works, at least on first look.

P.P.S. To answer my earlier question, dataspace appears to be bound to static instances in reentrant VIs. But if an ancestor VI is not reentrant and has multiple instances, I think that it's possible that the dataspaces of the ancestors (and any reentrant VIs that are their descendants) are smushed together.

P.P.P.S. I have no idea why anyone would want to use shared clones, but maybe that'll become apparent later.


Message Edited by SPM on 05-20-2008 01:36 PM

[TCPlomp]

---

• Every ancestor VI with multiple instances also has to be made reentrant (this shouldn't have to happen, according to the way I read the documentation, but it
  

d


Message Edited by SPM on 05-20-2008 01:36 PM

---

This is absolutly expected behaviour.

A normal VI is just one data-space, every version of that VI shares it's reentrant children.
A shared clone is usefull if your VI uses a lot of memory and you call it a lot of times at different times, and you don't have a memory leak.

Ton

[SPM]

Well, it may be expected (though I never found any place in the docs that said it was), but for my purpose it causes definite maintainability problems. Changes to the call tree far away from the sub-VI can break its behavior. In fact, this nearly nailed me during a demo yesterday.

Is there any form of re-entrancy that is independent of context?

Thanks,
- Steve

[tst]

I'm not sure what you mean by that, but reentrancy is always indepedent of context, since it's limited to the VI itself. If you want reentrancy where the VI is not dependent on any other VI you should use the Private option (preallocate for each instance), which is the default for a good reason.

[GuenterMueller]

Hi Steve.

You should not use reentrant VIs to accomplish an LED change detection. To my opinion, the behaviour of the reentrant VIs in reentrant VIs you observe is by accident what you want to have.  The correct approach might be - as Mike said -  an Action Engine.
Ben has written a great Nugget on this issue. Here you can read out, what you can do with Action Engines. (And just one note before you start: The shift registers in these VIs are not connected from outside the loop ...)

Regards, Guenter

[SPM]

Hi, Guenther,

So one Action Engine per LED to detect blinking is a no-no? (That's what I'm doing now, and unless they're reentrant they start stomping on each other.)

- Steve.

P.S. I am preallocating for each instance (private option.) But if some ancestor has multiple instances and isn't declared reentrant, blammo!




Message Edited by SPM on 05-24-2008 08:54 PM

[tst]

SPM wrote:

So one Action Engine per LED to detect blinking is a no-no? (That's what I'm doing now, and unless they're reentrant they start stomping on each other.)

---

Essentially, that is correct, because an AE is inherently global - if you make it reentrant it becomes useless.

What you basically want is named reentrancy where you can determine the scope of where the VI starts becoming reentrant. There are some options for this. For example:

• You can use a named AE, either by duplicating the VI itself on disk (ugh  ) or by writing a wrapper which will select the AE data that you want to work with based on the name that is wired into the AE.
• You can use GOOP - there's a quick example here (the end of thread that was linked to earlier). One of the variants (OpenGOOP) actually uses reentrant VIs as the storage mechanism.
• You can use LVOOP (search for LV2OO).

P.S. I am preallocating for each instance (private option.) But if some ancestor has multiple instances and isn't declared reentrant, blammo!

Well, that's a design issue and you need to test that the VIs work as designed. I don't think there is any way reentrancy will help you get around that.