Bug In Builder LV2012 - VI reported BAD when building - Need a workaround ASAP

[gregstoll]

---

@DanyAllard wrote:

That interesting, but I tougth that the compiler slider is just to improve compile time at edit time. Is it supposed to affect compile of a EXE build?

---

 The compiler slider always affects the compiler, whether it's at edit time or when building an EXE. If you're interested in building your EXE to be as optimized as possible, see the help topic Optimizing Execution Speed for Built Applications.

[DanyAllard]

---

@gregstoll wrote:

---

@DanyAllard wrote:

That interesting, but I tougth that the compiler slider is just to improve compile time at edit time. Is it supposed to affect compile of a EXE build?

---

 The compiler slider always affects the compiler, whether it's at edit time or when building an EXE. If you're interested in building your EXE to be as optimized as possible, see the help topic Optimizing Execution Speed for Built Applications.

---

Great, Thank you Greg for this Link. In the option dialog in compiler section, maybe it would be more clear to say that will affect build application. In the option dialog it said that this will increase editor responsivness.

[DanyAllard]

Ok - I will need help to find a solution. The problem occur again and now my workaround don't work. I tried on different PC and I got the same result. I played with the Compilation Optimization cursor and that don't change anything.

A littler more detail on my project:

There is 1500 vi's, 55 lvclass, I'm using VST, but in this project I don't have the FPGA build specification, it's a separated project.

When my project and all VI's are in memory, LabVIEW take 400M in memory. And when I build the application LabVIEW memory grow to 960M and after 12 min of build it stop with the error I described in previous post.

I have observed a strange behaviors maybe it's related to the problem. When I load the project and I open "Error List" it report that some VI's are broken. But when I open the top level VI all error disappear.

So there is any way to track what can be the problem?  Any secret key I can use to help to trouble shoot that? If so you can PM me

Any help will be appreciated

Thank you

[DanyAllard]

bump

[CarstenPXI]

I have encountered the same problem repeatedly  the last couple of days in LV 2012 on a very small project with less than 10 VIs.  Even the smallest change in the main VI will give the build error: 1502 cannot save a bad vi without its block diagram.

Mass compile is OK, have checked all VIs for Warnings, and find none of relevance. 

Historically, this could be due to constants wired to a case structure.  However, has been fixed according to NI.

My workaround is to Duplicate the Build specification, and try again.  This seems to work most of the time.  A bit harder is to delete the build spec and then create it from scratch.

As a random act of desparation, after a failed build I changed the target filename to be without spaces and this worked.  But whether this is a random effect or not, I don't know.  Maybe it just triggers a re-build of the XML files behind the scenes. 

I then go back and change the label of a front panel control in my main VI, and build again.  Get the same error message.

Now I try to change my target file name again (put spaces back in), but it still gives an error in the build.

Then I enable de-bugging in the build, and it builds OK. I then turn debugging OFF and get a build error again.

I now make a duplicate of the project, and build successfully.

However, the second time build without changing anything, I get an error.

Then make another duplicate, and build error free.

Second time I build, get an error.

So what is fairly reproducable is that I can only use a build one time!

Next part of the wild goose chase, look at the Sound and Vibration Toolkit.

Mass compile it, and while it is mass compiling, check that it is activated.  It is not, so I successfully Activate it.

None of this makes a difference.  However, the mass compile catches a bad VI ""SV Signal Property Note.vi". 

Go back to working around by Duplicating project:  This works half the time, if I don't succeed I make a new duplicate until it works.

But can only build it successfully one time.

So no solutions, but workarounds that work some of the time. 

Just to make sure there wasn't some system problem on my machine, I went back a successfully build a large project from last week.

Carsten

[CarstenPXI]

Just fiddling with Compiler settings.  When I change from Default 5 to 0, it will compile successfully, but only first time, and sometimes also when changing back to 5.

Carsten

[gregstoll]

Hi Carsten -

---

I now make a duplicate of the project, and build successfully.

However, the second time build without changing anything, I get an error.

Then make another duplicate, and build error free.

Second time I build, get an error.

So what is fairly reproducable is that I can only use a build one time!

---

This sounds like a problem with the App Builder Cache.  I bet if you get in the bad state, then to go Tools->Advanced->Clear Compiled Object Cache... and select "Application Builder" and press Delete, and then build again it will work.

To work around this more easily, you can add the VI Server call to ClearAppBuilderCache to a pre-build VI in that build spec.

Sorry for the trouble! Would it be possible to send me a copy of the project?

[DanyAllard]

Hello Greg,

I found that compiling in debug mode work all the time, and the application work, I don't have broken arrow.

But I can't distribute my application in debug mode because that potentialy expose my source code to the cutomers.

What can cause a VI to be reported broken in normal mode and not in debug mode?

[gregstoll]

---

@DanyAllard wrote:

Hello Greg,

I found that compiling in debug mode work all the time, and the application work, I don't have broken arrow.

But I can't distribute my application in debug mode because that potentialy expose my source code to the cutomers.

What can cause a VI to be reported broken in normal mode and not in debug mode?

---

Hi Dany -

Usually when we see issues like this, the reason is that in debug mode we automatically include all front panels and block diagrams, whereas we try to remove these in release mode.  I believe the usual cause is that a VI thinks it needs to recompile during the app build, but if we've already removed its block diagram, that can't happen and so the VI becomes broken.

So you might have luck turning off debugging and trying to include block diagrams for some VIs (through the Source File Settings page in the build specification), and see if you can figure out which VI is having a problem that way.

Another thing that might help is turning off any Additional Exclusions you have set - this reduces the number of things that happen during the app build.

Sorry to be vague - these sorts of issues are hard to track down unless we have a copy of the project and can debug it here...

[DanyAllard]

Thank you Greg,

I currenly building a version with the VI causing this error without removing is Front and Block Diagram.

I let you know the result.