Bug discovered in LabVIEW 8.5.1 with reentrant VIs

[RichardBallantyne]

Hi NI,

I discovered a bug with the way LabVIEW handles the state of front panel controls for reentrant VIs that have the front panel open during execution.  Essentially, what is happening is that the Boolean text on the FP button is not getting updated properly.  Sometimes it will update correclty, other times it won't.  This makes the bug intermittent.

Please see the attached example code for a demo.

Doing the following does NOT make the bug go away:

reentrant_gui.vi --> VI Properties --> Execution --> Check "Clear indicators when called"

Doing the following does make the bug go away:

reentrant_gui.vi --> VI Properties --> Execution --> Select "Preallocate clone for each instance"

However, in theory it should not be necessary to preallocate a clone since the FP values are wired into the vi before it is called (see the simple demo code).  Plus, for my application, I need to minimize the amount of RAM occupied by my program, so I don't want to preallocate clones for each instance.

Cheers,

Richard

[RichardBallantyne]

I think the point I'm trying to make is this:

Shouldn't the reentrant vi's front panel object states (like the text on a button) be set back to their defaults whenever that reentrant vi is called?  For example:  If the boolean text in clone:1 defaults to "OK", but is changed to "Continue", then when I re-instantiate the vi and LV decides to re-use clone:1, then the default boolean text in clone:1 should be set back to "OK", and not remain "Continue."

[RichardBallantyne]

Here is some new code that illustrates what I'm getting at...  This problem exists even if the clone is preallocated.  The front panel state is not getting set back to the default when the VI is called.

[ThHagel]

Hi Richard,

your illustration VI behaves exactly like I would expect it to.

You are using two instances of your reentrant VI and they have their own space in memory where they also store their property information.

As soon as you change the property of a control or indicator, it will remain changed for the specific instance of the reentrant VI, as long it doesn't get changed again and as long the VI instance is in memory ready for execution.

That's how I understand a reentrant VI. I hope I'm not wrong with this.

So, I guess this is not a bug.

[RichardBallantyne]

Thanks for your reply.

So how to I explicitly force LV to reset all of the FP object states back to their defaults?  The "Clear Indicators when called" option doesn't make this happen (at least not for the Boolean text on that button FP object).

Thanks,

Richard

[CoastalMaineBird]

For REENTRANT VIs. there is a disconnect between the visible panel and the real controls, simply because of reentrancy.  If it's reentrant, it might be called from several places at once, and you don't know which instance you're looking at.

For the same reason, you cannot step thru a REENTRANT vi.

I wouldn't depend on anything I saw on the FP on a REENTRANT vi.

If you need to debug it, make it non-reentrant, and debug it. 

[CoastalMaineBird]

I'm running 8.6.1, and I see what I would expect, when I run your code

Your instance:

1. copies NUMERIC IN to NUMERIC OUT
2. Copies its BOOLEAN's property BOOLTEXT.TEXT to STRING OUT
3. Sets its BOOLEAN's property BOOLTEXT.TEXT from STRING IN
4. Reads the BOOLEAN  (no effect)
5. Waits 100 mSec

You call two of these in a loop, one fed with the loop counter "i", and a string of "i", the other called with 0.0, and "blah"

The first time up, I don't know what I'll get from the STRING OUT, it depends on what the BOOLTEXT.TEXT property is set to.

The NARRAY 1 is labeled "should contain 0 to N", and it indeed should contain 0 to N-1, and it does.

The NARRAY 2 is labeled "should contain all 0s, and it indeed should, and it does.

The SARRAY 1 is labeled "should contain all OKs". but it really should  contain the strings "X","0',"1","2","3",... where X is indeterminate the first time up.

The SARRAY 2 is labeled "should contain all OKs, but it really should contain all "blah"s, and it does.

I don't know why you are expecting "OK".

I see no bug at all. 

[Ben]

---

CoastalMaineBird wrote:

For REENTRANT VIs. there is a disconnect between the visible panel and the real controls, simply because of reentrancy.  If it's reentrant, it might be called from several places at once, and you don't know which instance you're looking at.

For the same reason, you cannot step thru a REENTRANT vi.

I wouldn't depend on anything I saw on the FP on a REENTRANT vi.

If you need to debug it, make it non-reentrant, and debug it. 

---

That has changed as of about LV 8.0. You can single step into an instance of a re-entrant VI. One warning though, do not attempt to stop the VI if you setp into a recursive call of a re-entrant VI. LV will crash (It think I last saw the crash under LV 8.2 and not sure if that has been fixed). The work-around is to back out of the re-cursive calls before you hit the stop button.

Ben

[RavensFan]

Clear indicators when called affects the values of indicators.  The boolean text is a property node.  The only thing I can think of is that you programmatically set it back to whatever value you want the same way you programmatically changed it.  Perhaps even put a "Reset?"  boolean connector on the subVI's connector pane so that you can tell the subVI when to set it to the original property node value and when to leave it alone.

Richard, please post your user icon to this thread. and have it point to that rather than a 3rd party server.  We can't see your 3rd party server, so your icon just shows up as a red X.