Mechanical limit switches - acceptable practice?

[bmammen]

We were wondering if it’s an acceptable practice to have a second normally closed limit switch wired in line with a motor and sitting just a little longer in the throw, past the electrically monitored limit switch as a safety precaution?

The reason that I ask is that last season we had two instances where our software controlled limit switch either didn’t work or was physically knocked off center causing a very strong bag motor with planetary gearbox to bend and break our launching mechanism as it didn’t shutoff the motor at the end of the throw.

Any suggestions?

[Ether]

Originally Posted by bmammen

We were wondering if it’s an acceptable practice to have a second normally closed limit switch wired in line with a motor and sitting just a little longer in the throw, past the electrically monitored limit switch as a safety precaution?

The reason that I ask is that last season we had two instances where our software controlled limit switch either didn’t work or was physically knocked off center causing a very strong bag motor with planetary gearbox to bend and break our launching mechanism as it didn’t shutoff the motor at the end of the throw.

Any suggestions?

FRC legality aside, a few technical questions:

What motor controller were you using?

About the software you were using to detect the switch state: Was this an interrupt service routine or a polled task? If polled, at what frequency?

About the software you were using to react to the limit switch state: Was this an interrupt service routine or a polled task? If polled, at what frequency?

About the limit switch actuating lever: did you add a flexible extension to prevent permanent bending of the lever?

and finally:

What's the current rating on the limit switch you plan to put in the power line going to the motor?

[pfreivald]

The other question I'd ask is, is this a more-than-one-use mechanism? Because once that limit switch kills power to the motor....

[AdamHeard]

Originally Posted by pfreivald

The other question I'd ask is, is this a more-than-one-use mechanism? Because once that limit switch kills power to the motor....

Driver flails on the joysticks until the arm moves enough to lose contact!

[bmammen]

Originally Posted by pfreivald

The other question I'd ask is, is this a more-than-one-use mechanism? Because once that limit switch kills power to the motor....

Yes, the limit switch would be a safety mechanism and the robot would be done for the match however it could be fixed much easier than replacing a mangled launching assembly.

[Ether]

Originally Posted by bmammen

Yes, the limit switch would be a safety mechanism and the robot would be done for the match however it could be fixed much easier than replacing a mangled launching assembly.

If your root-cause failure analysis reveals that it's a software timing issue (your software as designed can't reliably respond fast enough to the limit switch), you might want to consider using a pot instead of a limit switch as your primary means of preventing motor overtravel. That would give your software a lot more time to respond and slow the motor down.

[bmammen]

Originally Posted by Ether

If your root-cause failure analysis reveals that it's a software timing issue (your software as designed can't reliably respond fast enough to the limit switch), you might want to consider using a pot instead of a limit switch as your primary means of preventing motor overtravel. That would give your software a lot more time to respond and slow the motor down.

Awesome, thanks for the input! We'd talked about adding a pot and that sounds like a good option.

[Mark McLeod]

A limit switch in the motor power pathway sounds like it would violate last year's R50 and primarily R53, but a robot inspectors advice is more valuable on questions such as these.

R53

CUSTOM CIRCUITS shall not directly alter the power pathways between the ROBOT battery, PD Board, motor controllers, relays, motors, or other elements of the ROBOT control system (items explicitly mentioned in R64). Custom high impedance voltage monitoring or low impedance current monitoring circuitry connected to the ROBOT’S electrical system is acceptable, if the effect on the ROBOT outputs is inconsequential.

[Joe Ross]

I agree with Mark that it isn't legal to place a limit switch inline with a motor.

We've typically chosen two options from the following list:

• Limit Switch with software control
• Potentiometer or Encoder with PID control and soft limits
• Current sensor
• Mechanism robust enough that it doesn't matter

Another option is to use the limit switch inputs on the jaguars, which will operate faster then your software and won't get commented out accidentally.

[FrankJ]

Joe stole my comment about using Jags.

Anyway, as much as I like to rag on the software guys, Limit switch failures are almost always mechanical & how they actually stop the motor is not the issue.

Anything that requires double protection like you are suggesting, you want to separate the modes of operation as much as practical. Like using a feedback pot for normal posting & limit switch through a jag for the end points.

[Jon Stratis]

As others have said, this would be illegal. The intent, as I read it, of R53 is one of safety- we need to know that the robot will cooperate in a predictable way when connected to the field (for example the field says stop and the motors all stop), and we need to know that the components can handle the current the motor is going to be pulling. As such, this is something I could see as being something teams could lobby the HTC to change in future years- an appropriately rated limit switch wouldn't prevent the motor from stopping. The trick is finding an appropriately rated limit switch and ensuring inspectors can verify rinsing catch on fire while on the field.

Using the limit switch into a jag helps, as it takes it out of the programmers control. Additionally, we've always designed in a hard stop that would force the motor to stall before a mechanism ripped itself apart. This was also a good place for the limit switch, as the hard stop can help prevent a mechanical failure of the switch. Leave it stalled long enough and the mechanism might still year itself apart, but the hard stop gives you a small buffer for the code to respond to the limit switch.

Where possible, potentiometer or absolute encoders can also come in handy for helping to control a mechanism and limit its range of motion.

[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.

[MrForbes]

I learned long ago in my FRC career that it's a good idea to make mechanisms that don't get hurt, if the motor keeps running. Yes, it takes some effort to figure out how to do this, but it can usually be done.

one trick is to have motors that spin rollers. Another is to use pneumatics for stuff that has to move a limited distance. Another is to have a "clutch" of some sort, such as a V belt that can slip, instead of a toothed belt or chain.

It's not that I don't trust the programmers...it's just that things somehow always go wrong. Mr. Murphy is usually hanging around the shop.

[Mr V]

If you are worried about failure of a single limit switch then just wire in two so you have a back up. Use the NO contact and wire them separately and in your code have it stop if either of them put out a signal. Relatively simple and legal under last season's rules. Having one in the power path would not be legal under last year's rules and I'd bet that it won't be legal under next year's rules. Additionally the problem is finding a limit switch rated for the amperage that the motor is rated for along with the fact that it would kill that motor for the rest of the match.

[bmammen]

Actually I'd not like to put FRC legality aside, if it's against the rules then we don't want to do it.

Our motor controllers are Talon SR's and not Jag's with CAN controlled limits, and to focus on one of the scenario's - lets go with the switch was physically damaged during a match (and it was), so we can leave programming out of the discussion for right now unless the thinking is to add another monitor in addition to the limit switch.

Yes the normally closed limit switch would need to be rated for the current draw of the bag motor.

Just wondering if this is possible and legal.
Thanks for the reply!