Our online shopping is experiencing intermittent service disruptions.

Support teams are actively working on the resolution.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI became broken during build process

I have a project in LV 8.2.1 that I am trying to build.  When I build, I get all the way through the build process to the last (top level) VI, and then get the Build Unsuccessful/The VI became broken during the build process error (see attached).

So I followed the "enable debugging to include the front panel and block diagrams" suggestion that shows in the error message, and my application builds correctly and runs fine without needing to use the Operate -> Debug Application tool in the Dev environment.

Any idea why?  This application builds and runs fine without the debug flag in LV 8.0.1 (I am in the process of trying to port it to 8.2).  Building with the debug flag makes the application run quite a bit slower, so this is not an optimal solution.

Message Edited by Joe Gerhardstein on 06-15-2007 09:46 AM

Joe Gerhardstein
Viasat
Certified LabVIEW Architect
Certified TestStand Developer
Certified Professional Instructor
http://www.viasat.com
0 Kudos
Message 1 of 17
(3,606 Views)
Is there anything unusual or unique about the subVI that it's throwing up on? Any external code being called?

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 2 of 17
(3,583 Views)
The top level VI is the one that breaks on build.  There is a lot of external code (mostly in .NET), but not called directly from the top-level VI.  There are VI Server calls as well from the top level VI.
Joe Gerhardstein
Viasat
Certified LabVIEW Architect
Certified TestStand Developer
Certified Professional Instructor
http://www.viasat.com
0 Kudos
Message 3 of 17
(3,538 Views)
Have you enabled the debugging features like the error message suggested? Did that tell you anything?

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 4 of 17
(3,527 Views)
As I mentioned, when I enable debugging, the application builds without error into an EXE and runs perfectly fine by itself (e.g., whatever including the debugging does, it also fixes the broken VI problem).
Joe Gerhardstein
Viasat
Certified LabVIEW Architect
Certified TestStand Developer
Certified Professional Instructor
http://www.viasat.com
0 Kudos
Message 5 of 17
(3,524 Views)
What's the error number you are seeing?  Is it error 1502?  It should be under the Details box when you receive the error.
There a two bugs with similar symptoms, and I'm trying to figure out if the problem you are seeing falls in either one of those issues.  Are you using .NET calls in classes?  If that's what you are doing, it seems that using any .NET constructor, .NET method, or .NET property node within a LV Object Oriented class VI will cause this error upon building the application.  This was reported to R&D (#47KGBBG0), and the fix will be in place for LabVIEW 8.5 put any . One thing that does seem to work as a (not very elegant) workaround is to wrap .NET contructor, method, or property nodes in a subVI that is NOT part of an OOP class.  This subVI, even when used by a OOP VI, seems to allow the application to build.
Another bug that has also been fixed for LabVIEW 8.5 is related to having polymorphic VIs in your main VI.  You need to have the front panel of the main top level VI open when the project is built, and have to have the polymorphic VIs replaced.
Please let me know if this information helps, or if your problem doesn't fall into either one of these catagories, please strip down your code and post the project that reproduces the issue, and I will investigate further.  Thank you!
Message 6 of 17
(3,504 Views)
Yep, it's a 1502 error.  We use .NET calls heavily in LabVIEW 8.0-style classes (.lvlib with public/private sections) that have been moved to 8.2, but do not use all the power of the 8.2 classes (e.g., no custom data-types and wires, no inheritence, etc.).  These .NET calls are all burried down in the application, not at the top-level, but most are marked as public for other compatibility reasons.  I have some polymorphic VIs as well, but these are mainly limited to NI's VIs (I might have 1 or 2 I wrote).

I could not find any info on RD#47KGBBG0.  Do you have more details on this?

I have 8.5/beta and will try to do the build in there and see if this works.



Joe Gerhardstein
Viasat
Certified LabVIEW Architect
Certified TestStand Developer
Certified Professional Instructor
http://www.viasat.com
0 Kudos
Message 7 of 17
(3,486 Views)
Bug information is internal, and you will not be able to find that information online.  You can call in support/post on the forum inquiring about the status of the bug, and we typically do not release specific information about the bug except for the work around.
Depending on the version of the beta, it might or might not be fixed.  I do recommend trying to compile in 8.5 beta.  Let me know how it works.
0 Kudos
Message 8 of 17
(3,468 Views)
Same issue in LV 8.5b14.  VI opens fine, but is reported as broken when building.

Message Edited by Joe Gerhardstein on 07-10-2007 06:58 AM

Joe Gerhardstein
Viasat
Certified LabVIEW Architect
Certified TestStand Developer
Certified Professional Instructor
http://www.viasat.com
0 Kudos
Message 9 of 17
(3,367 Views)
Hi Joe,
I'll update the bug report with that information.  Meanwhile, please try the work around mentioned above.  Thanks!

Yi Y.
Applications Engineer
http://www.ni.com/support
0 Kudos
Message 10 of 17
(3,336 Views)