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]

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!

[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

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

Do you know with acceptable certainty why the switch got damaged? I ask because in your original post it sounded like you don't know why:

two instances where our software controlled limit switch either didn’t work or was physically knocked off center

Before you fix something, it's worthwhile to make a concerted effort to figure out why it failed. Software could be the cause. Or lack of a flexible extension on the actuation lever. Or improper mounting of the switch.

[bmammen]

Originally Posted by Ether

Do you know with acceptable certainty why the switch got damaged? I ask because in your original post it sounded like you don't know why:



Before you fix something, it's worthwhile to make a concerted effort to figure out why it failed. Software could be the cause. Or lack of a flexible extension on the actuation lever. Or improper mounting of the switch.

Understandable, but similar to the reasoning behind breakers on the PDB - there could be a plethora of failures/mistakes/accidents and therefore never a bad idea to provide a safety mechanism to help narrow the scope of imperfection.

[JamesCH95]

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.

Not necessarily. If the arm contacted a spring (a cushioned hard-stop is a good idea anyway) that was able to push the arm off the switch after the switch cut power to the motor, you could reset everything. That's just an example.

Or this...

Originally Posted by AdamHeard

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

This, however, is the most important part.

Originally Posted by Ether

Do you know with acceptable certainty why the switch got damaged? I ask because in your original post it sounded like you don't know why:

Before you fix something, it's worthwhile to make a concerted effort to figure out why it failed. Software could be the cause. Or lack of a flexible extension on the actuation lever. Or improper mounting of the switch.

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