Argh, Exe builder says my VI is broken, but it's not

[Aristos Queue]

Well... "Development Environment is required to fix error" and "Dynamically launched VI cannot run because it is broken" (or whatever) are cases where LabVIEW is not descriptive enough in my book.

I don't know what to do about the first one, but the second one I do know about. You loaded a VI dynamically and tried to Run it, but the VI is broken. That's pretty much the sum total of the problem. What more information would you want to see?

[Jon Kokott]

I've had this problem as well. Enabling debugging on the built executable (I blindly do it on all VIs) seems to allow the build to work properly. I think my problem had to do with what AQ mentioned earlier where I dynamically launch VIs using a static VI reference where the dynamic VIs are class members with the class on the connector pane.

[Tim_S]

I don't know what to do about the first one, but the second one I do know about. You loaded a VI dynamically and tried to Run it, but the VI is broken. That's pretty much the sum total of the problem. What more information would you want to see?

The situation where I've run into this error message is when I try and load plugins from an executable. Typically it's a missing/misplaced DLL, but determining which can be a major pain. Switching to source code doesn't help as the plugin source isn't broken since everything is found where it's expected to be. The why the VI is broken would be of value to me.

I've also been able to "fix" some DLL builds by turning on debugging and not had the time to go back and determine why.

Tim

[CharlesB]

Got it here too. Strangest is that it happened twice. In the same week.

I build the executable quite frequently (not continuous integration though) and never got it before.

The project is quite big (700 VIs not counting vi.lib and OpenG), so finding the error was a pain since building Exe takes 10 mn.

First time was solved by replacing a subVI (which was just updating a cluster) by its code and deleting the subVI.

Second time (happening on a simple VI with a global variable) was solved by unchecking "disconnect typedefs" and "remove polymorphic VIs"

I'm source-controlled so I can give the snapshots of my project when the bug happened, if NI guys want it for repro no problem.

This problem needs to be fixed for real, it's giving pain to a lot of large projects, from what I saw on NI forums

I realize that the thread had diverged on different errors, so just to precise that this is about error 1502 (cannot save VI in bad state)

Edited June 7, 2011 by CharlesB

[Val Brown]

I maybe wrong about this but I think part of the challenge may be that you're using LV2009 sp1 and not 2010 sp1. I had several build related pbs (no pb with pb btw) in 2009 that were related to porting code that had its origins way back in 5(!) but which has been updated through each subsequent release. In the end the shift to 2010 sp1 finally resolved the problems but it was a real challenge to sort out because the "errors" weren't actually errors in 8.6. The became errors in 2009 because -- IMHO -- non one at NI thought to test legacy project builds to detect the kinds of errors that could pop-up. And, no I don't use classes, DVRs or anything really "exotic". Still pretty much old school LV.

[Jordan Kuehn]

I have complained before about Error 6 but am still of the opinion that it is better than having files outside of the build.

I would be nice if NI could do the build in a temp directory (as close to the root as possible) to avoid this, then copy it back to the dist location - all transparently (I currently have to use a script to do this manually).

Care to submit to the Idea Exchange? I would love this feature. Often times when giving RT code to a coworker for testing builds fail because his folder structure is much deeper than mine. Building and deploying on the desktop before moving into the final destination is a complete PTA.

[jjbloomfield]

Using LV 2012 SP1, I had this exact error too.  A previous post that mentioned type defs jogged my memory that one of my most recent edits was changing a "strict type def" cluster to a "type def".  This cluster was nested twice in other strict type def controls.  I made the change by directly opening the control rather than opening it though the nested structure of clusters.  This seems to have broken the build spec.  I went back and opened the control through the nested structure of clusters, made a cosmetic change so that it could be saved, and re-saved each level of the nested control.  The build then worked.

 

So the lesson for me was if you have nested type defs, be careful to access and save all affected controls through the nested structure.

 

[Rolf Kalbermatter]

I have complained before about Error 6 but am still of the opinion that it is better than having files outside of the build.

I would be nice if NI could do the build in a temp directory (as close to the root as possible) to avoid this, then copy it back to the dist location - all transparently (I currently have to use a script to do this manually).

 

Technically there would be a way to solve this in LabVIEW for almost all instances. The Windows API has generally ANSI functions and Unicode functions for all File IO functions. If they would choose to use explicitedly the Unicode variant internally and make the LabVIEW path to Windows path function a tiny bit smarter they could have solved that years ago for all OSes since Win2K.

 

Since Paths are in LabVIEW a distinct datatype the entire modification could have been done transparently for LabVIEW diagrams without compatibility problems. Why they didn't do it back in LabVIEW 8.0 when they modified all file functions to work with 64 bit file offsets to allow for file access for files <2GB is still not clear to me. It would have been an invasive chance in the LabVIEW source code only with almost no chance for any negative influences for LabVIEW applications.

 

Changing the File functions to use Unicode paths internally would IMHO have been a less involved exercise than supporting 64 bit file offsets throughout. Not to say that 64 bit offsets are not important (they are) but allowing paths to go beyond 260 characters is also a pretty important feature nowadays (and would have been a great opportunity to support 10 years ago when this generally wasn't a real issue for most computer installations).

[jgcode]

Just had code that worked in development but returned a 1502 build error (cannot Save A Bad Vi Without Its Block Diagram)

Hunted it down and turned out to be a privately-scoped VI in a polymorphic API 

Changed to public and all good 

[GME]

I had the same issue when my application was running fine in development mode, but gave error 1502 when attempted to build an exe.

Found the reason being a broken VI in an instrument driver class that I used in my project. The broken VI was an "Example.vi" in the driver class, however this "Example.vi" was never used in my application, it was used as a standalone VI to test driver functionality.

Somehow having that broken(but unused) VI being part of the class that I used in my application caused the build to fail. By fixing the broken VI and build became successful.

The same issue does not occur if the broken VI is inside a library.

To prevent this from happening again to see the error after a long build process, I have created a VI to search for broken VI(s) within my project dependent classes before the build process.

Cheers,

Jimmy

 

[Antoine Chalons]

with what version of LabVIEW is this?

I remember seeing a slightly similar issue, but the build would fail if a VI in a class had a broken wire in a disabled subdiagram of diagram disable structure.

but I think that was when 2013 came out, it was then fixed in the SP1.

 

Nice example!

[Fab]

13 hours ago, GME said:

To prevent this from happening again to see the error after a long build process, I have created a VI to search for broken VI(s) within my project dependent classes before the build process.

Cheers,

Jimmy

 

Jimmy,

This is a good alternative if you don't have access to the VI Analyzer Toolkit. I believe the toolkit is included in the Developer Suite version of LabVIEW. 

Check out: https://forums.ni.com/t5/VI-Analyzer-Enthusiasts/List-of-VI-Analyzer-Toolkit-Tests/ta-p/3510239

The test is called "Broken VI" and it is listed under VI Properties. 

Granted, the VI Analyzer test looks for any broken VIs, regardless if they are in a library or not. 

At Delacor we run a suite of VI Analyzer tests before building to find this and other nuisances (some times show stoppers) that could jeopardize a long build. 

You could convert your test above into a Custom VI Analyzer test and run it in conjunction with other tests that already ship with the toolkit.

Here is a short video describing what our Delacor VI Analyzer Tests package does. We have created customized versions of this toolkit for our customers. Perhaps you could create something similar.

 

[GME]

@Antoine, I'm using LV2016

@Fab, yes it is a great idea to include this as a customised test in the VI Analyzer. As you've mentioned, the reason why I didn't run the VI analyzer was because it will find any broken VI, which may not relate or affect to my build process.

Regards,

Jimmy

[rgood]

I recognize this is an old posting, but I have been struggling with this same issue when building my application into an executable.  I have a strange case where I am using the executable on the development computer, so all software is installed.  I traced the issue down to a piece of commented out code that had a missing subVI.  I found this and removed it and then the build worked again.  

 

I find this so strange because the application compiled fine yesterday, with the missing dependency.  I cleaned up the project a bit (inherited code with lots of obsolete code still in the project), and this launched the issue.  It is strange that the missing code was also missing yesterday, but it decided to break the executable today only after having cleaned up other missing dependencies.  

 

Just wanted to share as this post was the most useful I found.  

 

Thanks! 

 

Ryan