BUG (?) with simple while loop in LV2011

[EWiebe]

Hello all,

I have found a very strange behaviour in LV2011: A While Loop is not executed when running as EXE (in Development Environment it works)

While Loop:

(OK, its not the best way to check if button was pressed, but the WHILE Loop itself should be executed)

How to reproduce:

1. download attached file

2. open built EXE file

3. Look at numeric indicator. At my PC, the values are not increased->this means: while loop is not running

4. Open Project (lvproj)  (I hope I havent forgotten anything)

5. Start running the VI from whithin LabView (debug) -> now it should run

6. Try to build EXE

7. Try with new EXE. Still not executed While Loop?

BTW: I have saved the code for LV2010. There it is running. Strange.

Thanks

[Yamaeda]

If the button is True when you start the loop will stop immediatly.

[EWiebe]

OK, but the button is not true

[P@Anand]

Just place an indicator of the OK button and check it and also give a +1 increment to the Iteration indicator if that is not setting to 1 then the loop is not executing. OK is the only option I can see there that is able to start the loop. Is it a sub VI? In that case are you sure that the sub VI is executing. I don't see any bug with while loop as we have developed .exe for even large application.

[altenbach]

I agree that something is fishy, the loop counter should increment in the executable.

(Of course I have no idea why you are doing this "local read-unbundle-rebundle-local write" dance. All you need is unbundling the boolean from the cluster terminal, no locals needed. Since you are disabling the cluster one frame earlier, you will never be able to press the button to stop the loop. How is this supposed to work? Also the visible property belongs after the loop, you don't need to rewrite the same property 20x per second over and over.)

Also note that if you uncheck debugging on the advanced build page, the build generates an error and is unsuccessful. I do not understand why debugging needs to be checked for the build to complete.

Also note that if you delete the HP... subVI, the loop will correctly run in the build application.

[EWiebe]

Hello altenbach,

you are right, it is not the best way with this "read-unbundle-rebundle-local write".

I have simplified it:

STILL THE SAME RESULT: While loop NOT RUNNING:

"Also note that if you uncheck debugging on the advanced build page, the build generates an error and is unsuccessful"

You are right. This should not be

"Also note that if you delete the HP... subVI, the loop will correctly run in the build application"

It seems that it has to do with the HP driver..

Langsam fange ich an, an LabView zu zweifeln ... (sorry, I cant say it in english. It means like: I doubt in Labview)

BR

EWiebe

[Norbert_B]

Ok, after digging into this a bit, i followed Altenbach's hint regarding the HP-SubVI.

It is definetly connected to it, more specific:

If you remove the VIs i marked, the application will run "properly" (had to change the BigWnd property node in the main VI in the first sequence frame to be "Enabled"....).

It seems that:

- Building the exe does not properly identify the "True" case in the sub VI as dead code hence NOT removing it correctly (as we would expect it)

- Using a diagram disable structure instead of the case structure (or disabling/removing those two VIs in the "True" case) will result in proper functionality

I concur that this is unexpected behavior, but having dead code in the VI is always a bad idea.

If this issue occurs with other code segments comparable to this (having dead code within case structures), i concur that it is a bug. Otherwise, i would say it is a case specific failure generated by the code design.....

hope this helps,

Norbert

[EWiebe]

Could anybody from NI create a CAR #  ?

This small unused code sequence made my whole big project unusable.

Please correct this.

Thanks.

[Yamaeda]

If you place the disabling constant inside the error-case, will it work? It's ofc. prettier to use the Diagram Disable, but this might be a code interpretation/optimization issue.

/Y

[Ben]

---

@Norbert_B wrote:

...

I concur that this is unexpected behavior, but having dead code in the VI is always a bad idea.

If this issue occurs with other code segments comparable to this (having dead code within case structures), i concur that it is a bug. ... 

hope this helps,

Norbert

---

Hi Norbert,

I'm hair-splitting as normal.

Re Dead code

Please cite a reference.

1) There is an old school of thought that code should never be removed only replaced with a new version. This allows quickly switching back to the old version if the new version seems wacky.

2) Diagram disable is new and we used to use a boolean to disable old code. Apperently there is some noob loose in R&D that never imagined anyone would use a constant and this bug fell through the testing cracks. I have recently logged a call >>> CAR about a case with a constant preventing a build.

3) THe useage of a boolean constant to disable a code segment was knowan at one time becuase there was mutation code imlemented to convert constant to controls when open in a new version.

4) A diagram disable will force an ignore of the code in the disabled state. A constant driven case did NOT have that behaviour and we used to use it to ensure dynamic VI's were included in VIs.

So please cite the reference that I apperently missed.

Ben