Error while creating executable - Error 1502

[AlexanderKhodarev]

I've recently got the same 1502 error. Because of that i couldn't build executable where as everything was working fine while in development mode. Since it was really frustruating and i have to spend about an hour to debug this problem and since this problem was not related to a constant wired to case structure (as others have reported) i've decided to share the solution.

So in my case it turned out to be "Std deviation and variance.vi" (which comes in a standard labview package). I don't know why but somewhere down the road it decided to cease working. The funny thing about this vi is that it is very simple and doesn't contain anything that can get broken. So i've just copy/pasted it's contents to a new VI and saved it. Works perfect no problems. I've also noticed that some other VIs from probability and statistics stoped working (i don't use them in my project and checked it out of curiosity).

Now few words about debugging. Since my application contains one main VI, 20 top level (dynamically loaded) VIs, 300+ custom made VIs (which i initially blamed)  and many more standard VIs finding the right (broken) one was tricky. IT WAS TRICKY BECAUSE APPLICATION BUILDER SOMEHOW FORGETS TO NOTIFY IN WHICH EXACTLY VI ERROR OCCURS.

So first step was to figure out which of the "dynamics" is dead. One by one i've been adding them in application builder and making executable. Once i found the bad one i went into looking which exactly function is wrong (from then on i've been making executable only from that "bad" VI). I figured that good tool to use is "disable/enable" structure from the "Structures" palette. (Deleting code can also work but i don't think it is really good idea because there is no really easy way of going "one step back", where as in disable/enable it is super easy.) So once i found bad top level vi i've disabled the entire block diagram to see if it fixes the problem and it did. Then i enabled everything and started to disable one state at time (this top level VI was a state machine) till i found bad one. Well, six levels down, disabling ever smaller portions of code and building executables i was able to pin the problem and as i already mentioned it was "Std deviation and variance.vi". Interesting thing is that disabling entire block diagram of that VI doesn't solve 1502 problem.

Hope it helps.

If anyone from NI need some additional debugging let me know. I'll keep this "contained bug" in my code for a little bit.

XInstruments

 

[SMeserve]

Hi XI,

Is there anyway you can post up the code and steps to reproduce?  This makes filing a CAR a lot easier!  Thanks!

[AlexanderKhodarev]

Merry Christams everyone!

Stephen, below you can find the BD for the vi which was using Std Deviation vi and which got broken and couldn't be built in executable. (I've used  a diagram disable structure to verify which VI was causing problems. "Allow debugging" was enabled by the way.) After that i've tried to build executable of Std deviation.vi and it produced the same 1502 error. Furthermore i've tried to disable the entire Std deviation's block diagram and still got the same error.

That was few days ago. Today however i have a completely different story.

Today all of these 1502 problems are gone. I'm able to use std deviation and build all executables i want without 1502 problem. Weird. (or maybe that's my Christmas wish came true)

Anyhow, here are some thouhgts on the matter. First of all i want to explicitly state that no software was added/removed to cause/fix this bug. Then yesterday i've had same 1502 error even though on different occasion. (some time ago i've noticed that Labview has hard time traking errors/problems on the fly in big project. So for instance if you update vi's defenition (for instance it had two inputs A and B and was later changed to one input - A) Labview doesn't always show you broken arrow (like it normally would in small projects). Instead three things can happen: 1) broken error, 2) no broken error but labview crashes on attemp to run applicaiton, 3) no broken error, labview doesn't crash but attemp to build executable ends with 1502 error.) So i've found what was causing the problem and fixed it. And my thinking is that it may somehow fixed the problem with Std Deviation vi. Maybe Application Builder "reset" somthing inside itself after that second 1502 problem or something. I don't know what to add to the story, because realistically that (second error) was the only "extraordinary" event. Anyway i think that is one of these wierd bugs which happen from time to time without any reason simply because software is getting more and more complicated and self aware and trying to take over the world one little bug at a time. Right? 

[muks]

Is a car generated?

[SMeserve]

Without a reproducible crash or error, then we can't file a CAR.

[bbbbbbbbbb]

Thanks...... i got the solution for ERROR code 1502

solution:- use Enable Debuging during application build process.

[muks]

Thanks for updating..

[murali_vml]

Hi ,

I'm facing the same error as discussed in post..im able to recover from it by unchecking disconnect type definitions and unchecking remove unused members in proj libraries of build spec properties.

But my exe size has increased a lot(say almost 10 times)

but even i tried by creating the build with vi already open..but still i couldn't overcome the error..

John has mentioned it was solved..does ur exe size still the same after this?

kindly help..

-Murali

[Z.Chen]

Hi,

Today I've got the same error.

I tried to enable debug, but my executable crashes immediate after launching.

So I began investigating the source.

My result is that this error mainly caused by connecting constant Enum to a case.

After I changed all my constant Enum to Control, problem solved.

Hope this helps.

Cheers,

[Sanjay_C.]

Hi Zch,

Error 1502 occurs when the Application Builder cannot build an executable without the block diagram. Sometimes, this error is caused when certain cases in a case structure never execute (i.e. if you wire a Boolean constant to a case selector, and put some logic in both cases). I believe that you were able to overcome the error by replacing the Enum constants with controls because now the compiler belives that there is a chance that all cases in the case structure can execute (whereas previously, when using the Enum constant, it's possible that certain cases would never have executed). Make sure that there isn't any code that simply doesn't execute, as this can trip the Application Builder.