Why do these two subVIs behave differently?

[DTaylor]

I am assisting a client with a code migration from LabVIEW 2009 to 2014 SP1. During regression testing, we found that some functionality had broken. The cause was that a counter was being held on a front panel indicator, but the indicator was clearing every time the VI ran. The clear indicators on run option was not checked.

 

Strangely, if I put the offending indicator on the top-level diagram instead of in the case structure, the issue goes away. I have attached VIs that reproduce the issue. Test.vi has a boolean that you can toggle, and the subVIs should count the rising edges. The counter in SubVI 1 resets every time it is run, but the counter in SubVI2 counts correctly.

 

SubVI 1.vi

SubVI 2.vi

Test.vi

[ak_nz]

Do you see you logic error in the SubVI1 False case?

[DTaylor]

Do you see you logic error in the SubVI1 False case?

 

I understand that nothing happens in the false case of SubVI 1. The problem is that the count indicator is incrementing correctly when the trigger is seen, but resetting to 0 the next time SubVI 1 is called when there is no code that sets it to 0.

[infinitenothing]

No. Something happens after the false case runs. The VI returns default data for all its unwritten indicators. The moral of the story is to not use controls or indicators as memory storage. The preferred memory storage unit is a shift register in the test vi. A feedback node in the subVIs is the next best thing.

[ned]

 The preferred memory storage unit is a shift register in the test vi. A feedback node in the subVIs is the next best thing.

A minor note: these are equally preferable, and as I understand it they're implemented the same way in the compiler.

[infinitenothing]

The distinction was where they were implemented. If the memory is implemented higher up, its easier to unit test the lower level VIs.

[ShaunR]

 The VI returns default data for all its unwritten indicators

 

Unwired, yes. Unwritten? Citation needed.

 

Seems odd behaviour since you wouldn't expect a FP display to show zero in the same circumstance. you would just expect it just not update. Additionally. If you probe the wire in the case statement. It will retain the value, so why not the indicator? This seems like an overzealous optimiser issue.

Edited April 30, 2015 by ShaunR

[infinitenothing]

I'm not sure where this is documented but it's pretty consistent. Here's a simplified diagram showing this behavior with a numeric. If you wire the indicators to the connector pane, they get defaulted at the end of the run.

 

Edited April 30, 2015 by infinitenothing

[DTaylor]

No. Something happens after the false case runs. The VI returns default data for all its unwritten indicators. The moral of the story is to not use controls or indicators as memory storage. The preferred memory storage unit is a shift register in the test vi. A feedback node in the subVIs is the next best thing.

 

I agree that it is not a good place to keep state. The problem is that it was relied upon in a legacy application in a LabVIEW version that did not have this behavior, and upon upgrading to 2014, the program compiled but did not function. I have not been able to find any documentation of this behavior.

 

Interestingly enough, the indicators retain their state if they are not connected to the connector pane.

 

I was able to write a script that searched the project for every place this design pattern was used, and we corrected every case. Thanks for the help in pinpointing the cause!

[infinitenothing]

I tried this in 8.6 and I got the same behavior. Not sure what's up with 2009.

[Rolf Kalbermatter]

Unwired, yes. Unwritten? Citation needed.

 

Seems odd behaviour since you wouldn't expect a FP display to show zero in the same circumstance. you would just expect it just not update. Additionally. If you probe the wire in the case statement. It will retain the value, so why not the indicator? This seems like an overzealous optimiser issue.

 

It's not an overzealous optimization but one that is made on purpose. I can't find the reference at the moment but there was a discussion of this in the past and some input from some LabVIEW developer about why they did that.

 

I believe it's at least since LabVIEW 7.1 or so like that but possibly even earlier. And LabVIEW 2009 doing it differently would be a bug!

 

Edit: I did a few tests in several LabVIEW versions with attached VIs and they all behaved consistently by resetting the value when the false case was executed.

 

LV 7.0, 7.1.1f2, 8.0.1, 2009SP1 64 Bit, 2012SP1f5, 2013SP1f5

FP Counter.vi

Test.vi