Build Errors - VI broke during build

[BrianGShea@NGC]

When building an application and a VI misteriously breask, it would be nice to see what borke so that developers can have some idea of what to fix.

Currently we get this:

This would be nicer (please fill in the blanks on the graphics:

[AristosQueue (NI)]

I asked AppBuilder folks about this.

Developers worked on LabVIEW 2013 to improve the error feedback from AppBuilder, and for many errors, they succeeded, but there isn't much to be done about error code 1502 -- those tend to be rare and difficult for everyone to deal with. We are mainly hoping to track down how often they occur and with which build type(s) by looking at Customer Experience Improvement Program information. Each one that we have identified typically needs special, hands-on, intensive investigation, usually by several members of the development team. The CEIP information is the data that LabVIEW sends home to NI if you enable that feature when you install. That data has radically improved our ability to identify and solve complex bugs, so please enable it if you are able to do so in your work environment.

If you did not enable CEIP when you installed and decide you would like to participate, there is a separate app installed alongside LabVIEW: NI Customer Experience Improvement Program. Run the app to change your settings.

[BrianGShea@NGC]

AQ,

"Developers worked on LabVIEW 2013 to improve the error feedback from AppBuilder" - Thank you, but lets keep working to improve the help.

CEIP - Yes, I do. But that only works on crashes. Since LabVIEW is not crashing, there's no report to send.

Rare - Not sure how rare this is, maybe I'm not in the 80% use case. I'm sure 80% of the labVIEW developers are not CLA's so I guess i am excluded by certification.

This is the error that i battle with the most, after i get through other known issues. So far I'm going on 7 days to tracking down VIs that Break during building. 7 DAYS! that is 1 WEEK! I'm not kidding you you can as my local field sales rep. Its like chasing a ghost, fix a VI, find the next that breaks, and start pulling out code bit by bit, waiting 20 to 30 minutes for the failed build and circle back and pull more code out. Once fixed, i have to re-implement what worked just fine in the development environment.

Also, I know that enabling debugging will make this error go away and my app builds just fine, but fails to execute due to a broken VI error that pops up from the deferred load in the Actor Framework Launcher Screen.

I unchecked remove extra's, disconnect stuff and modify things (can't remember exact names) in hopes that the next time I won't have this issue. I even wrote an app to load LVLIBP's and test load all classes as a extra step to ensure that all modules and plugins are functional and can be loaded by the run-time engine before i build my main application.

So, tell me why, this can't be done?

The VI exists in memory, it's block diagram is still there, and so grabbing the block diagram as an image should not be too difficult. I believe that it is a method, right? Now all we need is an image display and a way to right-click and save to disk.

(Sorry if i sound fustrated, looming deadlines, no progress and lack of sleep make my fingers angry 😉 )

[AristosQueue (NI)]

CEIP and NIER are two different things. NIER sends in reports whenever there's a crash. CEIP logs various activities while you work and sends in periodic reports to NI about how you've been using LabVIEW. When we can correlate these activities against certain build errors, it helps figure out what a particular build error is.

I don't know why what you describe could not be done; in this I am just a messenger, but I will pass it along to the developers for a reply.

[Bob_Preis]

I think we'll need to take this over to the standard support channels and have a closer look at this specific problem.

[BrianGShea@NGC]

Apparently, I had it turned on. So hopefully my feedback is helping.

AQ Thanks for being the messenger, sorry to have taken a few shots at you, like i said, my fustration was comming out, please don't take it the wrong way.

[Bob_Preis]

Displaying what broke during the build may be of some value to a developer here at NI when debugging the 1502 error, however, it's not something a user could benefit from. The reason it's not something a user could benefit from is that whichever VI is breaking during the build actually started off not broken before the build, and then *became* broken because of something App Builder did to it (or one of its subVIs), not because of something the user has done. This is an important distinction from a 1003 error, where the VI started off broken before App Builder touched it.

A 1502 error is a generic, oversimplified indication of a broad scope of potential issues where LabVIEW has managed to break a VI after performing a safe operation on it (or one of its subVIs) that should *not* break the VI, such as disconnecting a typedef or removing a VI from a library. I do like this idea, but it's not a tool that a user could do anything with. It's more of an internal tool that *might* help someone at NI identify the root cause for a broken VI state caused by an operation that should not break a VI. The solution to a 1502 is almost always a fix to the LabVIEW source or App Builder itself.

[Darren]

Declined for reasons posted here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Build-Errors-VI-broke-during-build/idc-p/2924582#M2858...