BUG (?) with simple while loop in LV2011

[Norbert_B]

Ben,

i like your hair-splitting 🙂

I stated this like this since it is obvious that the issue is created by segments of code within "dead" structure areas.

I do concur in two points:

a) This should not create an executable which obviously "hangs"

b) Having to delete all "potential code" before building an executable is not suitable when trying out different approaches for the content of the exe

Digging more into this specific issue, i refuse to file a CAR though.

It is obvious, that the issue is created by a corrupt subVI called "SGS_HPE3631A (SubVi).vi"

Disabling debugging in this VI will result in a broken EXE:

Allow debugging again for the VI and disabling "Enable Debugging" for the EXE-build script will result in error 1502 during the build process:

It is obvious that the algorithm of LV which detects and removes dead code does remove too much from this VI in the "as is state". But since i never encountered this before, i would think that we cannot determine any pattern of occurrance here.....

A potential workaround is to replace the "False" constant with a control in the "SGS_HPE3631A (SubVi).vi". It even doesn't need to wire to the connector pane.

hope this helps,

Norbert

[Norbert_B]

@EWiebe: Is your issue solved with the information Altenbach and i provided?

thanks,

Norbert

[EWiebe]

I removed the not used case and now it is working.

But it is a LabView BUG.

I hope, the guys from NI will correct this

[altenbach]

---

@Norbert_B wrote:

Digging more into this specific issue, i refuse to file a CAR though

---

---

EWiebe wrote:

But it is a LabView BUG.

---

 I agree. There should definitely be a CAR filed.

[Ben]

What is there a new goal of "How many CARs didn't I file today?

G-wiz! (Note: I usually resrve such strong langauge for situations that make me want to scream)

If we are still talking about the build failing when a constant is used to drive a case structure then I fully agree this is a bug that should be fixed!

I can't be certain since the App engineers seldom include enough details to be sure what they are talking about but I have this e-mail that was part of SR# 1807011 where I recieved this message.

---

Hi Ben,

Sorry I can't change the subject line, but this is regarding the code you sent in about the LabVIEW compiler in 2011.

R&D is already aware of this issue so I didn't file a CAR on this. However, I did pass along your code so they will have the option to use it to test new compilers in the future. Thank you for passing this along to us Ben and have a great afternoon!!

Thank you!

Regards,

---

So this bug may alreadt have a CAR but I don't know what it is or am I sure.

Ben

[Norbert_B]

Ok guys,

since two well known LV enthusiasts stood up in favor for this issue, i won't let you down with just telling you, that no new CAR will be filed.

So i spent some more hours investigating this but i was not able to set up any combination of VIs and lvlibs to reproduce the issue except if i used components from the "Agilent E363X Series".

Nevertheless, Ben is correct that a CAR already exists for a 'similar' issue, the ID is 255617.

During my investigations, i found out that removing the checkmark in the option "Modify project library file after removing unused members" in the Additional Exclusions Tab is also a valid workaround.

This is my guess what happens:

- The app builder tracks the dead code and evaluates which component is to be removed, which is to be kept.

- There are subVIs within the dead code which are also used in "normal" code (e.g. Error Queue.vi). So the app builder does not remove the VI itself from the build process.

- It seems that, due to some issues i cannot reproduce with different setups, the lvlib-file for the exe will get the subVI removed. The result: The VI requires the lvlib (name spacing), but the lvlib does not accept this VI as component anymore. This results in the fact, that this subVI is not executable anymore passing up the issue to the caller containing the dead code.

So all in all, three valid workarounds are available:

1. Remove the code in the dead code segment.

2. Instead of using a boolean constant, using a control works as well. Just define the appropriate default value on this control in order to "skip" true or false case. This will result in the build process to add all VIs and dependencies (since the control *could* be modified during runtime).

3. Uncheck the option "Modify project library file after removing unused members" in the Additional Exclusions Tab in the build script.

hope this helps,

Norbert

[Ben]

Thanks for the CAR number.

I found this bug in an app with over a 1000 VIs and the message displayed when the build failed gave me no clue as to what I did wrong.

At the very least the app builder should display an icon of Nedry (from Jurasic Park) wagging his finger at me telling me no boolean constants allowed.

Ben

[Jeff-P]

CAR 425753 discussed in this thread was fixed in  LabVIEW 2014.  For a more complete list of bugs fixed in LabVIEW 2014, check the LabVIEW 2014 Bug Fixes. You can download an evaluation copy of LabVIEW 2014 at http://www.ni.com/trylabview/ or if you have an earlier version of LabVIEW installed and an active SSP subscription, you will be able to download the latest version of LabVIEW through NI Update Service.

Note that there are still other ways to encounter error 1502, see this KnowledgeBase Article for steps to troubleshoot this error.

Regards,

Jeff Peacock 

Product Support Engineer | LabVIEW R&D | National Instruments | Certified LabVIEW Architect