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

[Michael.Proctor]

LV2010 WIndows XP

I have a vi that always writes to a variable via a local variable.

In the next sequence frame the variable maybe written to if that case it is embedded in is true.

In lv2009 when I called this vi it also returned the expect result.

In lv2010 if I run the calling vi in slow-mo debug it alway returns the correct value

If run at realtime execution speed, it returns 0 if the case with the embedded write is NOT run.

The value in the indicator on the front panel of the sub vi is always correct, even if the value returned to the calling vi is not.

If I alter the vi to write to the variable for every case, the value returned is consistent.

It is worrisome that I now need to check every vi to see if I have unique case embedded variable writes

The calling vi are run as re-entrant with multiple instances running - but all but one the vi are idling.

I have not check if this is relevant ie does it also happen in a non renetrant caller

As my vi is complicated I need to see if I can reproduce it with a simpler version.

michael

[RavensFan]

Use of local variables

VI runs differently with highligh execution vs. full speed.

Both things are symptoms of a race condition.  You need to figure out how to do what you are trying to do without using local variables.

[Michael.Proctor]

There are no race conditions. That is the first thing I checked.

The variable is written to in seperate sequence frames.

The highlighted execution is for the calling vi, the called vi ( where the variable is updated ) is run at full speed.

and I probed the value returned immediately it is returned to the caller.

The problem is the returning of the variable to the calling vi - not - the code in either vi.

Remember this ran consistently and as expected in lv2009.

michael

[Ben]

I am in the same camp as Raven's Fan Except on Sunday's durring footbal season, GO Steelers! taht this sounds like a race condition.

LV 2010 has had some enhancement to its back-end letting it produce faster more efficient code. With that change the actual execution order may have changed from the LV 2009 version so a Race Condition may now have reared it head.

Without seeing your code it is hard to offer a suggestion but I would look to using a Shift Register to main the value rather than the control. Just use the control for updating the GUI and use the SR to hold the data.

If you post an IMAGE of your code we can take a look and advise further.

Ben

[Michael.Proctor]

yes I understand the that lv2010 has a lot of back end improvements

the problem is not to make the vi work.

I have already modified it to run consistantly, ie create a seqeunce local and pass that to the next frame and update every case

- the issue here is that lv2010 executes differently from lv2009 and it is the caller who has the problem receiving the correct value.

As I wrote early the called vi indicator value is always correctly written it just that value does not make to the caller

Posted are images from the original version

michael

[Michael.Proctor]

ps what might be interestin gto test is if I exchange the lcoal varialbe with the actual varialbe

ie the terminal is always written and the local variable only for the case.

However the main point for any other vi I have that have the same format of only writing the variable in a certain case

I might be getting the same inconsistent behaviour.

michael

[Been bitten by LabVIEW]

I know that you are running a newer version of LV than I, but this is very reminiscent of a problem I had too in 7.0.

When you have a reentrant VI, the FP is not exactly valid.  This is because (I think) the FP is used to pass data to the VI, but if you have a reentrant VI, you can basically have as many FPs as you have immediate callers to the VI (or for that matter, they may be shared, causing other problems, or the data is sunk, causing yet other problems).  This means, that VI *might* get confused as to what FP it is writing the local variable to making the data go off into never never land, never to be heard from again.  Note: this is my own explanation of the issue, whether this is true or not is unknown by me, but I couldn't figure out any other reason for it.

Why it would work if you set the local var in each case is something different, but may be related to this crazy FP business.

Try turning off reentrance, and use reentrance only in very localized VIs.  If you need multiple copies, try a VI template.

Hope this helps.  Good luck.

A

[Been bitten by LabVIEW]

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?

A

[Been bitten by LabVIEW]

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

A

[Michael.Proctor]

Many thanks for the helpful replies:

however it  not the called vi that is reentrant, it is the calling vi that is reentrant, ie the vi that receives the 0 value back from the called vi.

So no problems with the updating of the FP on the called vi.

As I wrote I do have a solution and that is writing to the variable for every case, or better yet through a tunnel to outside the case statement..

- so it is a work around that works - but it is still a bug see posted image

- but does not help my code base if I have other vis that work like this that are also producing inconsistent results

Michael