Build Errors

[apalrd]

When building the FRC Boot-up deployment, I get this error:

An error occurred while saving the following file:

C:\Users\YOUR NAME HERE\Documents\LabVIEW Data\Buzz15\Robot Main.vi

Invoke Node in AB_Source_VI.lvclass:Close_Reference.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_RTEXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller
<APPEND>
Method Name: <b>Save:Target Instrument</b>

It also says this in the "Details" box:

Error 1502 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_RTEXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  Cannot save a bad VI without its block diagram.

I have check all of my code, there is nothing apparently wrong with it. It works fine when I hit the play button in Robot Main.vi, it downloads and runs from there, but it won't do a full build.

[LabViewEnthusiast]

we've gotten that error too, search for it. It acutally went away on it's own, so I can't help you there, but someone has said that it's because one of the VI's is broken, i.e., the run arrow is broken and if you tried to click it you would be directed to an error within the coding.

[DiscoBall]

Can you try the following troubleshooting steps:

- Does this happen with unmodified code? If not, then there is an issue with a subVI in your code.
- What happen if you change the following options in the Build Properties under the Additional Exclusions category and select Do not disconnect type definitions or remove unreferenced members.
- Try enabling debugging. This can be done by navigating to the Advanced section of the build specification, and check Enable debugging.

Do you still get an error?

Joshua B.

NI FIRST Support

[apalrd]

1. My "Test-Drive" mostly unmodified code works. Its default code but with a shift solenoid and tank drive. It builds fine, I tried it twice.

2. Disconnect Type Deffinitions is not checked, Remove Unused Members is checked. It was already like this.

3. When I enable degugging, it works fine. Why would this be?

The Run Arrow in Robot Main.vi is not broken, thus none of it's SubVI's are broken.

[DiscoBall]

Are you using any code from last year? If so, you should be using this year's framework. Make sure that you don't have any unsupported functions and attempt a mass compile. If you are still having issues, can you make a new project and copy your code into the new project?

Joshua B.
NI FIRST Support

[rellimcire]

I have the same code. Started with this year's project, but have made many changes. Didn't happen until a day ago. Here is my comment from chief delphi.

------

ni.com/ask has several threads about this. What worked for us is enabling debug info. Right-click on your build spec, then select properties. On the property panel left side select Advanced, then click the box to Enable Debugging. According to stuff on ni.com, debugging forces the diagram to load which overcomes the problem.

What's disturbing about this is loading debug info on a competition robot. I'm trying to figure out a way around it. Anybody have any ideas? Plus, why the heck does LabVIEW need to save a vi during the build that I've already saved manually?

BTW, ni.com had a couple of other ideas, neither of which worked for me. Perhaps one will work for you. One is to open the offending vi before you build so the diagram is available. Another is to shorten the build path -- apparently path names can get over the 255 char limit on some (all?) Windows platforms (the build path is also on the build spec properties panel.

[apalrd]

Error found. I had a file used in Autonomous called stop.vi, with the purpose of stopping the drive motors and waiting a certain period while feeding the watchdog. It seems that LabVIEW dosen't like things named stop.vi, as soon as I renamed it all was well.

[Doug_Norman]

why the heck does LabVIEW need to save a vi during the build that I've already saved manually?

When LabVIEW builds an exe, it has to organize all the needed files.  It has to mass compile them, strip the diagram code, and often create an internal folder hierarchy to handle different subVIs that have the same name.

[LockheedJoe]

What I've found is if you have a boolean constant (true/false) loop controlling a case structure, it get's that error.

If you change it to a control, it seems to work.

[Doug_Norman]

What I've found is if you have a boolean constant (true/false) loop controlling a case structure, it get's that error.

If you change it to a control, it seems to work.

Right - the 1502 error is a known bug when building an executable with a constant wired to a case structure.  We mostly see this happen when teams try to build their last year's code, because last year's template had a constant wired to the selection terminal of a case structure.