**bleep** you, error 1502!!! (shakes fist)

[Austin_S]

 A couple things to try that we've seen work for others getting this error are to uncheck the "Disconnect type definitions" and "Remove unused members of project libraries" options in the Additional Exclusions category in the Application Properties.  You also may try to check "Enable debugging" in the Advanced category, but that might also make your application quite large.

[LabVIEW_Wizard]

I tried unchecking "Disconnect type definitions" and "Remove unused members of project libraries" but then the Build threw up:

ERROR 7

File Not Found: C:\Program Files (x86)\National Instruments\LabVIEW 2010\vi.lib\vision\Basics.llb\IMAQ Create

The missing file might be referenced by one of the libraries included in the build or by the file - splash.vi. To fix this issue:

- Open all Startup, Exported, or Always Included VIs, recompile them (CTRL+SHIFT Click the Run arrow) and save them to update their dependencies.
- Open all libraries included in the build and verify the existence and locations of referenced files. Also, try building with the additional exclusion option, "Remove unused members of project libraries", checked.

I looked in that directory and no such 'vision' folder exists.

I am now going to check "Remove unused members of project libraries" as the ERROR suggests and re-build.  I'll let you know how things go.

[LabVIEW_Wizard]

SUCCESS!!!

After unchecking "Disconnect type definitions" and re-checking "Remove unused members of project libraries" I still got ERROR 1502.  I then went through my Project, selected "Source File Settings" unchecked "Use Default Save Settings" & unchecked "Remove Front Panel" & "Remove Block Diagram".  After a few iterations of modifying the "Source File Settings" (each time I tried a build & it failed it would tell me which VI was the cause of the failure) it finally worked.  Hopefully this thread will be able to help someone out of the bind that I was in.

[Austin_S]

Thanks for posting that!  That is great information to have on our end in case this particular error shows up for others in the future.  I hate that you were getting this error to begin with, but glad that you're able to move forward with your project now.

[Wayne.C]

In process of dealing with the 1502 problem.  Experience also included what appeared to be a corrupt LV install as well.   NI is telling me that executing code in a transition of a statechart that is set to execute on a RT target running VXWorks will cause problems.  See here .  The trick is figuring out how to fix/recover all that hard work.

Here's what worked in my case.  This seems drastic but due to time constraints I had to hit all possibilities in one pass.

1. Format cRIO target.
2. Reinstall LV.
3. Make a copy of the offending project.
4. Blow away the .lvproj and associated files.
5. I edited the statechart outside a project and removed all code from the transitions. ( Had previously tried in a project and that didn't go well. )
6. I temporarily set the offending party to execute on the desktop and saved it.  I then set it to execute on RT target, regenerated the code and saved. 
7. Mass compile of just the statechart and then of the top level vi that calls the statechart.  Fix all errors.
8. Start with a blank project and rebuild.
9. Enable 'debugging' in build specification.
10. Once it will build again, go back and modify code to account for loss of code in transitions.

[smoothly]

Hi,

If you search Error 1502 will find the following explanation from NI.

Error 1502 can occur if dependencies are placed in non executing case structures
In previous versions of LabVIEW you could place VIs in a case structure with a constant wired the the case selector. This would load the VIs at runtime. If you have this pattern and attempt to build an executable you could receive error 1502

Workaround: Don't use unreachable code

Reported Version: 8.6.1

Resolved Version: N/A

Added: 04/20/2011

My fix instead of changing the vi, I simply on page "Additional Exlucsions" uncheck "remove unused members from project libraries". This will slow down the build a lot. It solves the problem.

Henry

[Keith_W]

Just for completeness, this error can also arise when using polymorphic VIs.  I was able to resolve my error 1502 by following the comments in this thread and also unchecking the "Remove unused polymorphic VI instances" under additional exclusions.

[Dan_at_Ocean_Systems]

I had the same problem. Don't ask me why but by turning "remove polymorphic instances" ON and deselecting "Remove unused members of project libraries". Both are in "Additiona exclsions" catagory my project compiled just fine.

Good Luck

[JCC_(SK)]

I am able to build RT application (for cRIO) only when I tick "Disconnect type definitions". Ticks on "Remove unused polymorphic..." and "Remove unused members ..", Ctrl+Shift+Run recompilation didn't help.

I didn't try to move VIs to new project.

I didn't try to Mass Compile. I expect that Ctrl+Shift+Run recompilation recompiled everything what was in my project

But when I tick "Disable type definitions" I was able to compile it but my application was not running after cRIO restart.

After half-day I found that I am reading data from FPGA through same controls which is Type Definition. After FPGA code modification - disconnected control from Type Definition and FPGA recompilation (and RT compilation) Application is starting. Finally!

[StephenB]

I just got hit by this for a source distribution (LLB) for VxWorks. In my build spec I had selected everything, including dependencies, to remove block diagrams... Similar to RTEXEs. I also had disconnect typedefs, remove unused members of proj libraries, remove unused polymorphic VIs and disconnect inline VIs checked. I DID NOT check modify project library after removing unused members.

I finally figured out what caused the issue. I had TCP Listen in my code.. And deep in its hierarchy there is "Three button dialog.vi". This VI is broken on VxWorks for obvious reasons... But that was OK because it was behind a conditional disable structure for OS. So my code was not broken. However, since source distributions include edit time dependencies as well as run time dependencies... It was going into the LLB and the block diagram was attempting to be removed yielding error 1502.

However RTEXEs do NOT include edit time dependencies. Only run time dependencies. So items behind a conditional disable shouldn't cause this problem.

Nevertheless I can't help but think this is related. One thing is for sure- something in your hierarchy includes a broken VI. Sometimes it is very hard to figure out what this VI is because the LVproject hides some dependencies as "internal".