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

[JÞB]

Still missing type defs and subs of the sub

try zipping the project folder (assuming no dependancies not in the folder heirarchy)

[Jeff-H]

I cannot send it all because it belongs to our customer.  I removed the case structure from the vi, and it started compiling every time.  Then I added a similar case structure around the place where that function is called, and guess what?  Now the calling function will not compile sometimes.  It seems that LV has a problem with case structures that have a constant input, in my case False.  True always works, but False fails sometimes.  I have two instances where I comment out the same vi using this method.  Only one of them fails with a False input.  I attached the pictures here, though there is not much to see.  Is this a know issue?  Maybe there is a better way to easily comment out code?

[JÞB]

Yes, Conditional disable structures and project (or target within project) Symbols

[Jeff-H]

Okay, I found that setting an indicator to False and then using a local variable at the structure input is acceptable to LV.

Thank you very much for your help, and I hope that NI can address the issue of constant inputs to case structures being another causation of the dreaded 1502 error.

[JÞB]

As has been previously stated in this thread the solution is "never write unreachable code"

(A good practice in any language) Unfortunately  you can't just "//" in front of Block diagram objects!  So, those case structures driven by constants look like a good idea to disable code although they are not ideal.  Use disable or conditional disable structures to truely "Comment out" code. 

Although, I have seen block diagram free text lables like "//I am a comment written by a former C programmer" that use the "//" to warn the compiler to ignore the text.

[LabBEAN]

We fixed this 1502 error on a recent cRIO project by disconnecting type definitions in the RT build spec (under Additional Exclusions). In our case the error was related to the code that opened the FPGA reference and is apparently a bug introduced in LV 2011 SP1.

[MissyS]

Thank you for posting this! I couldn't get my RT executable to build because of error 1502. I removed a case structure that I had left in for debugging purposes that had a constant wired to it. Removing the non-executing code did the trick.

Thanks again!

[cirrusio]

It's been a long time and this thread is still rolling, which is pretty sad because this error is incredibly frustrating.  That being said, several years ago I think I came across the answer to this by happenstance at a local dev day.  If I am not mistaken, the way to reliably get rid of this error (if this is the same one) is to actually clear your compiled cache and close and reopen LabVIEW.  Silly, but really simple.  I have not had any major issues like I did before since I discovered this neat little trick.

[MissyS]

Thank you cirrusio. For completeness (and to save me time looking for how to do it), how does one clear their compiled cache in LabVIEW? I've never done that before, or I have and I don't know that is what it was called. Thanks again!

[cirrusio]

In any window, go to Tools->Advanced->Clear Compiled Cache.  This will throw a dialog pop-up asking you if you want to do this and showing you the size of the current cache.  You can also delete the object cache folder.  On Windows, this might be in LabVIEW Data, but I am not certain.  This has been successful for me.  Let me know if it works for you.