10-23-2013 02:16 PM
While trying to build a previously build exe I get the following error.
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_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: Cannot save a bad VI without its block diagram.
Solved! Go to Solution.
10-24-2013 02:13 AM
Hi Paul,
Could you provide some background what (if anything) you changed right before you are recieving the error, what version or LabVIEW you are using, and/or what toolkits you are using?
Also have you tried the steps in other forum posts about enabling debug and checking dependencies?
http://forums.ni.com/t5/LabVIEW/Build-error-1502-but-no-broken-VI/td-p/450498/page/2
http://forums.ni.com/t5/LabVIEW/bleep-you-error-1502-shakes-fist/td-p/1404652/page/2
http://forums.ni.com/t5/LabVIEW/Building-LV8-5-application-EXE-error-1502/m-p/2387406
A few of the reasons have been a constant wired to a case structure, unreachable code, dependencies loaded twice, and many other small reasons.
10-24-2013 07:35 AM
I don't know what changed between compling on Monday without the error and compling on Wednesday with the error.
Enabling Debug fixed the issue.
Paul
11-02-2013 09:50 AM
Thanks, I had a similar problem where I would get ERROR 1502 when trying to compile a perfectly ok VI, compiler claiming that there was a broken VI in the project (which there wasent). The VI's casing the problem were located in the httpClient folder. Enabling the debugger fixed the issue. Very strange. I am using LV2011 on this particular machine.
vi.lib\httpClient\POSTBuffer.vi
12-09-2013 12:25 PM - edited 12-09-2013 12:26 PM
had this same issue when porting to LabVIEW 2013. I was able to avoid the issue by unchecking the "Disconnect type definitions" exclusion option. It may have had to do with type defs associated with a OOP class, but I'm not sure.
12-12-2013 01:26 AM - edited 12-12-2013 01:33 AM
Same error appeared when I was trying to build an executable for >200 VIs project(LabVIEW 12.0f3). The error referred to the main startup VI to be the bad VI. In the code I used 2 case structures with constants wired to selectors: after I deleted the unused cases, and removed the case structure, the build was successful.
01-08-2014 10:34 AM
I have the same error. Turns out it has to do with the Matrix Math, AXB, Vis being clones. Once I removed the VIs the application builds fine. So I'm making my own AXB vi.
I requested help from NI about this and the sent me down a rabit hole.
01-09-2014 02:59 PM
Hi aml1138,
Were you able to get rid of the error by making a new VI? As mentioned in other posts, this error can be avoided by enabling debugging and disconnecting type definitions.
I hope this is able to help.
Anna L
01-09-2014 03:15 PM
Yep, I made a AXB vi and works fine. I use other Matrix VIs and they don't cause a build problem.
03-10-2014 06:28 AM
Hi!
First I have to thank you all for your comments and posts. I would not find a solution so quickly without this forum.
The same error (1502) occurred during the build process with an explanation: "Cannot save a bad VI without its block diagram.".
I read a few posts here on this forum and tried a few solutions.
I first check the VI "FP Initial View.vi" which was reported to be broken. It was not broken, of course.
Then I turned on debugging as suggested in the error message. This helped builder to finish its work but it did not remove (or hide) the error. When I ran the exe the top level VI showed its panel with broken arrow and a message window said something like : "The application can't start. A full development version of LabView is needed ... bla, bla ".
Next try: I disabled a part of so-called-broken VI with the Diagram Disable Structure. I disabled the part it changed after the previous working version. After a few minutes the builder reported the same error but it pointed to another VI: a small utility VI with Allow debugging option OFF and Inline subVI into calling VIs option ON.
Because I read a few comments about connecting constant to Case Structure I immediately changed the enumerated constant Interpolation method to a variable. I also removed Disable Structure from FP Initial View.vi and tried to rebuild the application.
It works now.
It's interesting that the solution by fredb is seven years old but it still deserves a kudos.
I'm using LabView Developer Suite, version 13.0f2 (32 bit) on Windows 7 Professional, SP 1, 64 bit.
Regards and thanks again.