Delayed reaction of limit switches.

Technical Electrical
1

There is quite a significant delay between pressing the limit switch and the code reacting. The wiring is as follows: signal to com, 5v to no, and gnd to nc of a DIO. I did it like this off of one that I found already wired. Is toys correct? Any idea what causes toys? Anyone know how to fix it?

2

Your wiring sounds fine. The issue could be programming, or the brake-coast setting of the motor controller. Most like it’s the brake-coast setting. If your motor controllers are set for coast, the motor isn’t going to stop very quickly when the output is set to 0, so make sure they’re set to brake for something that should stop fast. Even then, there’s going to be some stopping distance. Your system will work better if it’s designed to coast (a little) into a hard stop after triggering the limit switch, or if it’s designed with closed loop position control to actively hold the position when it triggers the limit switch.

3

Beg to differ on the wiring.
A limit switch doesn’t require power, just a DIO signal and ground.
Signal to com and gnd to nc of a DIO. You don’t need the no unless you want to reverse how the switch reads in code (or don’t want the switch to fail safe).

4

I don’t see how the 5V being connected would cause a problem, even if it’s not particularly necessary. It certainly wouldn’t cause this “delayed reaction” issue.

5

Just for the record, all of our motor controllers are in brake. But I was testing them with having a piston extend when I pressed the button and retract when I let it go. The piston took seconds to respond to the press and more seconds to register when I let go.

I will try this today and see if I get any better results. I don’t see why this would be the issue but it’s certainly worth trying.

6

If the signal/gnd wiring with the power gets reversed you will be shorting out the 5v power rail whenever the switch gets depressed.
That would be an interesting intermittent problem to troubleshoot, since it would probably only be noticed during full operation on the playing field.
Ground traditionally gets wired to Common and signal to either the NC (normally closed), or NO (normally open) signal option.
So if you get someone in who knows that and wires it the right way around with the useless power, all your DIO belong to us.
Wired correctly that can’t happen.

It’s wrong, and you don’t want to be doing that, but may not be the cause of this particular delay problem.

7

Sounds like a code issue. Would you post your code for this?

8

Can you post the output of your limit switch to SmartDashboard or something? See if that changes instantly or has the same delay as your actuators.

Which language do you program in?

Are there any other delays in controls?

9

When you say the piston took seconds to respond… what is the solenoid doing? When dealing with pneumatics, there are a lot of other things could cause a piston to be slow. For example, a flow control valve could easily make the piston appear to respond late and slowly.

10

Declarations in our header file:


DigitalInput LeftLimit;
DigitalInput RightLimit;

In our constructor:


LeftLimit(2),
RightLimit(3),

The code for the actuation (LeftFlap is a DoubleSolenoid object):


if (LeftLimit.Get())
{
     LeftFlap.Set(DoubleSolenoid::kForward);
}
else
{
     LeftFlap.Set(DoubleSolenoid::kReverse);
}
  1. I’ll tried it with standard dashboard and it didn’t work. But I think it was the fact that standard dashboard isn’t great. I’ll try SmartDashboard today.
  2. C++
  3. No

I’m fairly certain that the solenoid was firing at the same time as the piston. But having to answer the question is making me have doubts so I’ll check again :slight_smile: .

11

What I see there seems OK. Check that you don’t have any timer delays or other time consuming steps in your periodic functions.

12

We bring all of our limit switches out to the dashboard as Booleans, making it easy to validate their state. It’s particularly useful after maintenance to be able to run through all of the switches in a few seconds to verify that wiring is back in the right place.

13

Depending on the application, it might be best to use a motor controller (like a Spark or TalonSRX) that allows you to wire the limit switch directly into the motor controller, bypassing the RoboRio (and any code issues) altogether. Wiring directly to the motor controller should offer the best response time of any available option as you cut out other variables that cause latency.

Again though, this is entirely dependent on how you’re using the limit switch.

EDIT:
If you’re having issues with slow pneumatics, one way to isolate the problem might be to try and trigger the pneumatic manually with a joystick button and see if the same delay occurs, if it does, the problem is likely with your solenoid (or code), if not, then see the comments above.

Also keep in mind that vision code (even the default stuff) can have a pretty drastic negative effect on performance.

14

Pneumatic Piston?

Regardless of the limit switch, a pneumatic piston will fully extend and fully retract.

You may stop more air going into the piston, but the piston will keep moving until it hits a hard stop. The piston could be dirty, and slow moving.

Are you using the limit switch to tell the piston to move, or to try and stop a moving piston? If you are trying to tell a piston to move, then you have a piston or air flow problem. If you are trying to stop a moving piston, then it won’t work.

15

Thanks for all of the help! I’ve decided to go with using the SRX data port for the limit switches. :smiley: