[cfair]

Bmammen, your original thought is sound, but not allowed in FRC. My experience with machine tools is pretty dated and we made one-off tools rather than production tools, but we ALWAYS put a second limit switch beyond the first one, and the second switch was connected to a relay or contactor that killed the entire system (no software involved). This second switch is surprisingly expensive, because you need a couple of inches of extra travel to accommodate the switch plus deceleration of the carriage. This year we built a linear test fixture with exactly these provisions for testing software because:

In FRC, our experience is that the best method is to use encoders and PID, with soft limits, so that the actual limit switches should never be encountered except during initialization (homing). However, there are multiple conditions that will cause the system to lose zero during a match, which you are apparently aware of. It is therefore very important that software be able to deal with hitting a limit switch, and it is a continual battle to keep our software folks and their code doing the right thing. In particular, kids often think it's OK to use open loop control and just monitor the limits (particularly for joystick mode), or they find that they never actually hit the limits using programmed moves, so the software that responds to them "atrophies", and bad things happen when they inevitably hit them. The response once you're in a limit switch can be debated, but we generally allow motion in the appropriate direction to get off the switch, and what happens after that depends on your tolerance for risk, because it should never have hit it in the first place.