[Joseph F]

LOL! You never heard of a program breaking under "unexpected conditions"??? It's called a "bug". (Maybe he's never programmed, nor tried to run a Microsoft product before... ). Seriously though, in industry we more often use HARDWARE to protect us from SOFTWARE bugs than the other way around! Most of the time for cost savings Consumer software only does "sanity checks" to keep an eye on the hardware, and simply alerts the user to problems. In military and automotive programming though we do often spend the extra time, money, and effort to try to "program around failed hardware".

I wasn't talking about all programming. I'm talking specifically about the robot program. The conditions of the match shouldn't be far enough outside the realm of normal capabilities that it would cause the program to crash.

Actually, a good solder joint is VERY reliable, as long as you have a good mechanical initial connection before soldering, and strain relief on the harness.

Given the specifics of the competition odds are a wire will be ripped off long before the program gets confused enough to crash. Plus we dont have anyone who actually 'knows' how to sodder propperly, so our joints are probably sub-standard.

If you are REALLY worried about an automatic pressure control failing, then simply give your driver an "override switch".

I did program in an ovverride that turns the pump on whenever the pneumatics are fired. As for a manual on/off/auto switch its a good idea I hadn't concidered. I'll probably set up as much of it as I can until I actually get the robot back.

You can also do this with an unused thumbwheel as well by dividing its possible position value into thirds.

A good idea, unfortunately our control board has all but 1 switch in use currently. I programmed in a turn corrector controlled by our last availible wheel (our robot turns right for some odd reason).

Of course if you wish (and are REALLY bored), you can always review each case, and create the logic to test and handle error cases. For example, if you see the LOW switch thinks the pressure is too low AND the HIGH switch thinks it is too high, something is not right. Watching which one the pressure toggles around tells you the OTHER switch failed, and you fall back to a timer method using the good switch. The two switches now gives you REDUNDANCY.

wow. um. I am going through robot withdrawal currently but I havn't achieved that level of desperation just yet.... Actually its probably not as bad as it sounds, but of course this would assume I put in and soddered up the second switch. I might write the program for this eventually anyway, just for future refrence.

Thanks for all the help. I'll be printing out this thread eventually to keep all this usefull information.