Bug Report: lv2010; Inconsistent value returned from sub-vi

[Michael.Proctor]

>Oh, and that Extract Value block you are using... Is that new to LV2010?  Or it is a VI used for convenience?  If so, out of >curiosity, what is in it?

it is my vi:  It takes a cluster of two arrays one arrays is parameters names the other the value for that parameter

then depending on what type of value I wish to have returned I set the type.

I use it everywhere, as I do not need to track the order of parameters passed to vi.

Prizes for anyone who can improve it 🙂

The insert_value vi is used to insert in to parameter value pairs or update a particular value in an array type value.

BTW now I remember I did have trouble with this vi having the same issue, but I fixed in the lv2010 beta testing

michael

[Michael.Proctor]

> 

Have you tried to use the value property node instead?  It works slightly differently then the local variable.

that is something interesting to test

Michael

[Been bitten by LabVIEW]

Interesting, parallel arrays with use of a variant for output (and I asume input for the set vi?)  I made something similar (properties list) which was a single 2D array.  Didn't bother with variants as they seem to act kinda funny in LV7.0 and they don't do an autocast from a varient to another type.  Is your extract VI a polymorph VI controlled by the function input?

If I pushed mine farther, instead of just returning strings, I would probably use a polymorph VI to change the output, but for now it does me fine as strings as it is the most generic structure in LV.

A

[Michael.Proctor]

Here is a snippet of the code that has the problem.

Observe the value of TempTarget in the wrapper vi when run at full execution speed and then run at highlighted speed compared to the value in Get_Growth_Params simple.

I greatly simplified from the original to avoid 100+ other vis.

But it still showed the same inconsistent results.

NOTE I have work around fixed for this vi - the main point here is to show a bug or elicit an explanation why this is inconsistent.

Also note that previous versions of labview had no problems with this.

BIGGER NOTE:  IF I switch around the Terminal with the local variable ie now the local variable is not run as it is embedded in a none execute case, the results are as consistent.

Conclusion is definitely a BUG.

Tested in both XP and MacOS X

Have included bonus Extract_Value.vi

Do excuse some bad coding practices, these where written some years ago.

michael

[RavensFan]

How are we supposed to run your VI?

I assume Test_Get_Growth_Config_simple.vi is the main VI.  But when I run that, nothing happens.  Is the Run Parameters array on the front panel supposed to be empty?

[Michael.Proctor]

Yes run Test_Get_GrowthConfig_Simple.vi

and notice on its FP the indicator TempTarget  remains 0 or is set to 0

Now re-run with highlighted execution and it should show 300, ie the correct value.

For further fun open the sub vi Get_Growth_Config_Simple and swap the Terminal with the local varible and re-run the above tests.

It now works as expected.

michael

[RavensFan]

Okay, I see what you are talking about.

I remember reading a message thread a long time ago about issues with subVI's when a terminal that is wired up to the connector pane is located in a case structure.  I think that thread may provide some insight into what is going on here.  Unfortunately, I can't find that thread right now to link to it.

[Ben]

---

@Ravens Fan wrote:

Okay, I see what you are talking about.

I remember reading a message thread a long time ago about issues with subVI's when a terminal that is wired up to the connector pane is located in a case structure.  I think that thread may provide some insight into what is going on here.  Unfortunately, I can't find that thread right now to link to it.

---

Is it looking like a bug to you?

I can't bring up 2010 to test but I am still curious. I have seen the technique of repeatedly writing to a control "to make sure it gets in there" to fix race conditions that I am still hesitant.

Your opinion?

Ben

[RavensFan]

---

Ben wrote:

Is it looking like a bug to you?

I can't bring up 2010 to test but I am still curious. I have seen the technique of repeatedly writing to a control "to make sure it gets in there" to fix race conditions that I am still hesitant.

Your opinion?

Ben

---

I'll say yes, I think it is a bug.  Not so much for what it is doing in LV2010, but because it is definitely behaving differently than it does in LV2009.  I just backsaved Michael's files to LV9 and ran them, and saw that the result is 300 whether highlight execution is on or off.  Whereas in LV10, it is 0 at full speed and 300 with highlight execution on.  Different behavior in different LV versions hints at a bug.

My original suspicions were a user error of race conditions.  But looking over his files, I am not seeing the typical user-caused race condition of unordered writing to different local variables and terminals.

It is behaving like a race condition internal to LabVIEW where the subVI is ending and returning the default value of the terminal at the outgoing connector before the local variable updated the terminal/connector.

Ben, do you know which message thread I'm thinking of where it gives a reason it is not a good idea to put a terminal inside a case structure in a subVI?  I remember reading something like that, but now I just can't find it to figure if it somehow relates to what we are seeing here.

-Bill

[Ben]

---

@Michael.Proctor wrote:

Here is a snippet of the code that has the problem.

Observe the value of TempTarget in the wrapper vi when run at full execution speed and then run at highlighted speed compared to the value in Get_Growth_Params simple.

I greatly simplified from the original to avoid 100+ other vis.

But it still showed the same inconsistent results.

NOTE I have work around fixed for this vi - the main point here is to show a bug or elicit an explanation why this is inconsistent.

Also note that previous versions of labview had no problems with this.

BIGGER NOTE:  IF I switch around the Terminal with the local variable ie now the local variable is not run as it is embedded in a none execute case, the results are as consistent.

Conclusion is definitely a BUG.

Tested in both XP and MacOS X

Have included bonus Extract_Value.vi

Do excuse some bad coding practices, these where written some years ago.

michael

---

Hi Micahel,

I am slow to say bug because "boy who cried wolf" but based on Bill's gut feel, I have requested an App Engineer follow-up. It may take a couple of days for them to complete the work, so standby.

Bill,

Sorry I don't recall that bug.

Thank you,

Ben