build application error

[gone4fishn]

i am now getting a build application error.  i tried a vi that had been build previously, stilll get the error.  the program runs ok in labview.

Problem Description :
Hello, i never had a problem 'building application' before.
now i get an error and message:
Visit the Request Support page at ni.com/ask to learn more about resolving this
problem. Use the following information as a reference:

Error 1502 occurred at AB_Source_VI.lvclass:Close_Reference.vi ->
AB_Build.lvclass:Save.vi -> AB_Build.lvclass:Copy_Files.vi ->
AB_Application.lvclass:Copy_Files.vi -> AB_EXE.lvclass:Copy_Files.vi ->
AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi ->
AB_EXE.lvclass:Build.vi -> AB_Build.lvclass:Build_from_Wizard.vi ->
AB_UI_Frmwk_Build.lvclass:Build.vi -> AB_UI_FRAMEWORK.vi ->
AB_Create_Build_Application.vi -> EBUIP_Global_OnCommand.vi ->
EBUIP_Global_OnCommand.vi.ProxyCaller

Possible reason(s):

LabVIEW:  Cannot save a bad VI without its block diagram.

NI Software :  LabVIEW  version 2011
NI Hardware :  Select one if your issue is related to hardware device
Driver Version :  
OS :  Windows 7

Thank You

[BrianInTheForest]

Try renaming the VI that is giving you the issue and see if you can build the application.

[gone4fishn]

Thanks, i tried renaming, building on a different pc... still 'build unseccessfull'

[Timmar]

I get this a lot,

I mean an awful lot.

Caused when Labview Corrupts a project VI, usualy by one of it's ever so frequent crashes.

It won't tell you it's broken but it is,

Solutions,

Roll back to a previous version,

Delete Start again.

[gmart]

This error indicates that during the build a VI needed to be recompiled after its block diagram was removed. A workaround is to keep the block diagram of the noted VI or to enable debugging for the application if a VI is not referenced. There is no "corruption" of a source VI during the build. If possible, please attach or submit to support a copy of the code that demonstrates this issue so it can be further investigated.

[Timmar]

George,

  if my vi's aren't being corrupted, and I am not removing the block diagrams, how come I keep recieving these errors.

The problem co-incides with one of the all to requent Labview Crashes.

I am doing a build right now, and the only way I can make it work is to unmark seperate compiled code in all the vi's in the project.

[gmart]

Without knowing the specifics our your setup, I can't provide an answer to your particular issues. I would try to reproduce the issue with a set of code you can provide to support. With this code, R&D can attempt to reproduce and indentify the problem.

[User002]

---

@Timmar wrote:

I get this a lot,

I mean an awful lot.

Caused when Labview Corrupts a project VI, usualy by one of it's ever so frequent crashes.

It won't tell you it's broken but it is,

---

Indeed, there is an inconsistency between what's shown on the BD and what actually is there in compiled form. Specially obvious with XControls. The BD's can be completley empty, but still LV searches for the XCtl reference when you open the empty FP and void BD???

Several tricks:

1. Save the VI with another name, close the old one, overwrite the old VI by renaming the new one.
2. On the block diagram press: CTRL-A -> CTRL-X (select all and cut it out) Create a new vi and paste in the code. Overwrite the old broken VI with the new one.
3. Only do class name and move path's when the projects are in memory. Not always feasible if you have a lot of re-use, some projects end broken searching for old paths. So that is a bit painful to update all your projects, specially with some ref's are correct and other's not.
4. CTRL-SHIFT->Run VI, forces a recompilation of the VI hierarchy
5. Mass compile to find broken stuff.
6. Good version control is a must to revert if things go haywire and badly out of control with LV.

Br,

/Roger