Error code 1502 when building application

[Tim_S]

This is a long shot, but hoping someone here has run across this issue. I am trying to build an executable and keep getting the following message:

An error occurred while saving the following file: <file name here>

 

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_Item_OnDoProperties.vi -> AB_Item_OnDoProperties.vi.ProxyCaller

Possible reason(s):

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

 

I check the VI and it is not broken. I've had instances where opening the VI then performing the build works, but it does not for this issue.

 

The only way I've managed to build the application without error has been to set the Enable Debugging flag. I'd rather not have this set, so I've been playing with settings of all kinds (Additional Exclusion flags, setting so block diagrams are kept, etc.), clearing compiled cache, mass compiling, binary compiling... I'm pretty sure NI tech support is going to have me wave a dead chicken next.

 

One of the odd things I've run into: If I go into the build properties, then changing the reported file's source file settings so that the block diagram is not removed and then reattempt the compile, then I will get the same message with a different file. I can do this for the new file name which leads me down a rabbit hole of files until I start getting to files in the user.lib. I stopped when I got to a VI template file that is part of a lvlib used in the application (the .vit is not used anywhere in the project).

 

Any thoughts and suggestions (particularly those that keep me from summoning the elder gods) would be greatly appreciated.

[hooovahh]

Not a long shot at all, I've seen this plenty of times and I know others that have too.  Here are several links:

 

http://forums.ni.com/t5/LabVIEW/Error-while-building-an-executable-from-vi/td-p/1907753/page/2

http://forums.ni.com/t5/LabVIEW/1502-error-previous-solutions-not-working/m-p/1489838/highlight/true#M561789

http://forums.ni.com/t5/LabVIEW/Build-Errors-1502/m-p/1301220/highlight/true#M536545

http://forums.ni.com/t5/LabVIEW/Error-1502-occurred/m-p/1712466/highlight/true#M604492

 

Looks like it was a bug that was fixed in 2014.  When ever I see it I just close LabVIEW completelly, usually resulting in an error on close, with a soft crash of some kind.  Then re opening the project and hitting build before running the VI usually results in a normal build.  There was also a VI posted by a user somewhere on the NI forums that replaced a VI in the build process that fixed this.  I am not a fan of replacing system VIs so I recommend the restart of LabVIEW.

[Neil Pate]

Sometimes this error message could occur if some other code in the project is broken. Very often it is a class VI that is not actually used in the main code (say a test VI that has been broken as the API changed, and the dev was a bit too lazy to go back and re-run all the tests).

 

When I get these errors I start pruning the main VI until the build works again, however this is very timeconsuming (and frustrating process) and I would say that most of the time the error is related to one of the recent things I changed.

[Tim_S]

Not a long shot at all, I've seen this plenty of times and I know others that have too.  Here are several links:

 

Looks like it was a bug that was fixed in 2014.  When ever I see it I just close LabVIEW completelly, usually resulting in an error on close, with a soft crash of some kind.  Then re opening the project and hitting build before running the VI usually results in a normal build.  There was also a VI posted by a user somewhere on the NI forums that replaced a VI in the build process that fixed this.  I am not a fan of replacing system VIs so I recommend the restart of LabVIEW.

I appreciate the links. Unfortunately, I've tried all of the settings referenced without success. Clearing the compile cache and rebooting the PC didn't help either. My company is in the middle of moving offices, so my changes of getting the LabVIEW 2014 disks from IT are zero.

 

Sometimes this error message could occur if some other code in the project is broken. Very often it is a class VI that is not actually used in the main code (say a test VI that has been broken as the API changed, and the dev was a bit too lazy to go back and re-run all the tests).

 

When I get these errors I start pruning the main VI until the build works again, however this is very timeconsuming (and frustrating process) and I would say that most of the time the error is related to one of the recent things I changed.

I have some libraries with templates (.vit files) that are part of the project. I will have to look at this.

[ShaunR]

Basically to echo what Neil is saying. I've recently been building and resolving these errors (I always get it with the package manager).

 

Orphaned VIs or those in a conditional disable are usually the culprits. Sometimes VIs that are referenced on a diagram but not in a lib or project. If you get the VI search dialogue popping up (and you're fast enough) you can click on the dialogues' title bar to freeze it so you can see the VI its trying to load  A failed search during build will always cause this error.

Edited January 27, 2015 by ShaunR

[Tim_S]

Update...

I've been working with NI tech support to try and resolve the error. I trimmed my code back to a splash screen before the issue went away. I've waved the dead chicken and NI R&D has been looking at what's going on. In between emails from NI, I started rebuilding the code from the ground up with a lot of copy paste and some changes with the benefit of hindsight. I've built back up the application to nearly the same functionality and have not had the same issue when compiling. While I have made some changes, I've had an issue with a different piece of code that appears to be corruption in a class, so I'm highly suspicious I have the same issue with this code.

 

Lessons (re)learned:

1. Compile often

2. SCC

3. SCC

4. SCC

[Mike Le]

I ran into this same issue recently. It happened right after I added a DVR containing a typedef to the private data of one of my classes. Do you know if you did anything like that beforehand? What do you think fixed your code before and after the rewrite?

[odoylerules]

Does this happen at the very end of the build or when it starts?  I've recently had a strange build error, unfortunately i didn't right it down, but it would occur at the very end of building an application.  

I tracked it down to a "read only" file SEH-RTEH-errors.txt located in C:\Program Files (x86)\National Instruments\Shared\LabVIEW Run-Time\2013\errors\

 

For some reason after every build this file was being set as "read only" and the build would not complete unless i manually unset this file back to non Read Only.  In the end i had to write a script that i run before i build now.

 

I have no idea if this helps with your issues but this was a strange one and thought i would share.

[Tim_S]

I ran into this same issue recently. It happened right after I added a DVR containing a typedef to the private data of one of my classes. Do you know if you did anything like that beforehand? What do you think fixed your code before and after the rewrite?

I had enable debugging turned on for quite a while, so it's possible that could have broken things and I wouldn't have seen it. The original code has one DVR of an object that gets passed into multiple loops. The rewrite eliminated that DVR and creates multiple objects for each loop. This seems small initially, but is a huge difference in the code. (This was a decision made after spending some time trying to comprehend the Actor Framework.) There was a lot of copy/paste from old to rewrite; I've fixed code by just copying it to a new VI before.

 

I believe I had several files (not necessarily VIs) that have become corrupted in some fashion. I have had other projects that would compile, but displayed behavior akin to pushing a doorbell and the house turns green. One project I fixed by performing copy/paste into a new project that is (at least to me) identical in every way (file names and all).

 

NI tech support is still looking into this issue along with R&D. My last email to them was to send pre-build, post-build, icon and custom configuration files. The pre-build deletes the contents of the temporary build directory and the post-build moves the temporary build to the final directory.

 

Does this happen at the very end of the build or when it starts?  I've recently had a strange build error, unfortunately i didn't right it down, but it would occur at the very end of building an application.  

I tracked it down to a "read only" file SEH-RTEH-errors.txt located in C:\Program Files (x86)\National Instruments\Shared\LabVIEW Run-Time\2013\errors\

 

For some reason after every build this file was being set as "read only" and the build would not complete unless i manually unset this file back to non Read Only.  In the end i had to write a script that i run before i build now.

 

I have no idea if this helps with your issues but this was a strange one and thought i would share.

 

This happens in the middle of the build as the status shows processing each VI in turn.