[Jared Russell]

This happens a lot. To veteran and rookie teams alike... I know that I've been programming our robot between matches more times than I can count.

I do have some advice, though (some of this won't help this year, but might come in useful in preventing this in the future).

1. Code in "units". Don't write a 1000 line program, build it, and expect everything to work the first time. It just doesn't happen. Even if you only have a day to test code, try to test it incrementally. First get the drive working. Once you're happy with that, move onto the scoring functions.

2. There are two types of tuning/debugging you will need to do: correctness testing, and parameter tweaking. A complicated sequence of commands is something that you can either get right or wrong. Other things, like PID loops, time delays, etc. need to be tweaked until they work well. You can oftentimes do "correctness" testing by running your C++ code on a PC (taking out cRIO specific things as necessary). Or you can try your LabView code in a non-real time environment. Make sure your function(s) output expected values. But tuning needs access to the robot. So make sure your code is correct before downloading to the machine, and worry about tweaking afterwards if you can.

3. Have a plan. Know what you want to get working first, what can wait, and what is just bells and whistles.

4. Write maintainable code. Use parameters and constants liberally. These will make changing things that much easier.

Good luck! It sucks sitting around watching the mechanical folks do their thing (hopefully none of my team's mechanical team is reading this). But know that you are in good company!

EDIT: I posted before I saw you are using LabView. Still, these points should apply.