We had this exact same problem last week. Eventually the problem went away on its own (after we’d identified the source of the error by selectively deleting subVIs and attempting to build until the error went away). In our case, the error was associated with a modified (and renamed) copy of HolonomicDrive.VI we had placed in our project. At some point we attemped building with our modified copy again and it built successfully. We haven’t seen the problem for over a week now (we periodically build, just to be sure).
The strange thing is we went for weeks just deploying the code to RAM with no errors; we only had problems when we performed a Build.
FWIW, had the same problem (Error 1502) occur again yesterday. This time the supposedly offending item was “Begin.VI”. The solution I found was to revert to an older copy of Begin.VI that had been successfully built in the past, build it (successfully), re-implement the exact same changes, then build it again (successfully). This is the second time this approach has worked. Solution time: 4 hours including the time spent trying to diagnose the problem. Once I gave up trying to find an actual error in the VI, the time spent to backtrack and re-implement was only about 20 minutes. This will be my preferred approach in the future, obviously.
As before, the code could be deployed w/o any errors generated or issues in function, but wouldn’t successfully build. It would supposedly build OK (no errors were generated, at least) when the “enable debug” setting was checked under the Advanced tab in the build options, but after uploading to the cRIO it resulted in a “No Robot Code” condition. Experimentation showed that the issue was not related to file or folder permissions, nor file or folder path length.
We had an issue earlier this year where we could use the RUN function to execute code, but when we did a build, we would get an error. I don’t remember the code, but it looked much like the one in the first post.
NI looked at the problem and found that it was caused by a known bug in LV.
We had some debug code that we were disabling by putting a case statement around it and setting the control to FALSE using a constant. Changing the case input to a control rather than a constant fixed the problem.