FIRST Robotics Competition Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Build Errors

We saw this when we had our working code in there but would have experamental code in there for the same set of blocks. Once we changed it to a control it worked fine.

"Lockheed" Joe
Testing Blog"
0 Kudos
Message 11 of 13
(750 Views)

It turns out that though enabling debug allowed me to build, it wrecked my deployment. I'd build, then deploy. LabVIEW says all is OK. But after deploying the code would not run on the cRIO. The only way to run was from LabVIEW.

So I went back to the most recent version that built without enabling debug. (Lesson: I was saved a lot of grief because I make daily or more often backups of our project.) That version also deployed so the two problems are linked.

Since LabVIEW gave no clues, I took the current project and went back to the Teleop.vi that worked. Using that fixed my problem. Then I retraced my steps bit by bit until I found the step that broke it. After a couple of hours I found it was caused by a new sub vi. That vi referenced the drive motors (specifically arcade drive) which is a logical conflict with the reference in Teleop.vi. Cleared that up and everything builds OK and deploys OK. WHEW!

So my problem is fixed and my code is better. It's strange that the problem was caused by a logic error. Furthermore, adding the same logic error to a pristine FRC robot project does not produce any error. Combine that with the comments about cases/loops controlled by constants and constants setting structures and I suspect there are some complex, seemingly random things going on when LabVIEW is building and saving the cRIO image.

Glad I got rid of the problem. Thanks for all the helpful comments.

0 Kudos
Message 12 of 13
(750 Views)

DougNorman wrote:

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.

I see the same problem in LVRT 2011 SP1. A case with a constant input selector makes a build error or a run as startup application in CRIO to crash. Don't use constant in case structures.

0 Kudos
Message 13 of 13
(750 Views)