Programming goofs!

[WizenedEE]

I'm interested.. How did you change begin so that it would work just once? It seems like you'd just add "true" constants to the inputs of robot drive.

As for me, I've never messed up anything too badly in programming, mostly because we loaded the code on the C RIO before ship date last year and my brother wouldn't let me touch it afterward.

This year, I spent a week trying to figure out why we were having communication errors before seeing that once of the loops in periodic tasks didn't have a wait on it.

[Bryan Herbst]

During Overdrive, one of the other programmers and I decided that Linux would be awesome on our laptop.

We decided to go ahead and dual boot Linux and Vista while we were at the regional. Set up the partitions, and everything went fine. Booted it up only to discover we had installed it to the wrong partition!

[Cecil]

The major goof i remember was back in 2009. We had a slider that would push out orbit balls from our hopper, and had limit switches to stop the motor at its outer limits. Right before one of the matches, i added an override button for the ramp-up PID we had implemented for our drive wheels, at the request of our driver. I found what i thought was the latest code on our laptop, made the simple switch, and loaded it in. For some reason, during our function check, our slider wouldnt work, but everything else would. It wasnt until mid-match that i looked back at the code and saw that the digital input had been called a second time, just sitting at the bottom of the code out of view. Nobody knows why it was there.. After a simple delete, everything worked fine. Still blame myself for losing that match.. Pretty much cost us that regional.

[Owen Meaker]

Originally Posted by WizenedEE

I'm interested.. How did you change begin so that it would work just once? It seems like you'd just add "true" constants to the inputs of robot drive.

The reason the problem was ocurring was that I had made inputs from the dashboard to toggle controls. I had written the autonomous to use no inversions, but the drivers wanted forward and backwards inverted. my first solution was to have a "use inversion" set to false in begin, then set to true on entering teleop. this had the problem of only working once per power-on, and I didn't consider running two matches before powering the robot off. my second fix was moving the variable from begin to autonomous, so it would work everytime.

[Kyoshirin]

This isn't so much a programming goof as a Labview goof.

This year, we made a new program every time we wanted to edit our program, and our programmer saved all the variations into a single folder. Near the end of build we were testing the compressor separate from everything else, so we made another program for that. We stop partway through working, save and leave.
The next day our programmer couldn't come, so I took over that part. I opened the non-compressor .vi and it only has compressor stuff. Being utterly confused, I try opening older .vi's and find that they are all the same. We had no clue what happened. Me and another guy on the team began working on a new program to attempt to get all functions back, without ever seeing the actual working program before.
After two days of making new code, we discovered the problem. By saving all the .vi's in one folder, they all had the same dependencies. Begin, teleop, and all the others were used by every new program we made, writing over the old code.
That day we learned to make a new folder for each program.