Talon SRX limit switches - incorrect operation.

[DougJensen]

Background: Using SRXs with CAN. Updated with latest software (we have already been through (and won) one FRC competition, so yes they have been updated.)

Summary of problem:
Whenever the motor is traveling in 'direction A' and the 'direction B' limit is actuated the motor does not run at full power (it runs but at low power or with much 'stutter') - which is incorrect operation. Limit A should not affect operation in direction B and vice versa.

Using default Normally Open configuration (limit switch closes at limit.)
Using CTR cables and breakout boards.

More detail:
1.) The limit switches operate correctly in the 'appropriate' direction:
When the 'FWD' limit actuates, it stops the motor immediately when the motor is traveling in the forward direction AND the 'REV' limit stops the motor immediately when traveling in the REV direction.

BUT

2.) When 'coming off a limit', i.e. when the FWD limit is actuated but the motor is commanded at full power in the REV direction, the motor 'stutters' (it certainly does not drive with any appreciable power) until the FWD limit switch DE-actuates (the switch has some overtravel on it, so it remains actuated for some length of travel while the motor runs in the REV direction), but once the FWD switch is de-actuated the motor runs at full power in the REV direction as commanded. Likewise the opposite happens at the other end of travel. (The REV limit is actuated but the motor is commanded to full power in FWD direction - the motor does not run smoothly with any appreciable power until the REV limit de-actuates and the motor returns to full FWD power as commanded.)

As mentioned we are using normally open switches and have confirmed the operation manually (by shorting wires by hand.) Every time the motor is 'stopped' by either direction limit (by CLOSING) the corresponding limit switch (shorting the limit input to GND) the motor stops as it should, but the motor will not reverse gracefully when commanded - it stutters or runs at low power until the limit switch is OPENED.

Conclusion we reach: The limit switch for direction A is affecting operation of the motor in direction B, which it clearly should not.

Observations, suggestions welcome. Thanks!

[Peter Johnson]

Almost certainly this issue is due to your code. Either it's driving two different motor values from two different parts of the code, or disabling and driving from two different parts of the code.

This can be a bit subtle to find, as we found out this year when we had a near-identical symptom with our CANTalon use of limit switches. We were resetting our encoder value to 0 when the limit switch was pressed, and the code to do so effectively looked like this:

if (motor.isFwdLimitSwitchClosed()) {
    motor.changeControlMode(ControlMode.Position);
    motor.setPosition(0);
}
...
if (driving pid) {
   motor.changeControlMode(ControlMode.Position);
   motor.set(...);
}
else {
   motor.changeControlMode(ControlMode.PercentVbus);
   motor.set(...);
}

The issue was with calling changeControlMode() in the first if statement, which calls applyControlMode(), which in the non-pid case results in the motor being disabled until set() is called again (which happens later in the code). The fix was to not call changeControlMode() here--it's not necessary to be in Position Control mode to set the position.

I would recommend carefully examining your code to see if you might have a similar hidden issue. Even if you're not using changeControlMode(), simply calling set() from two different locations would cause the same stuttering issue.

[Aren Siekmeier]

Hi Doug,

Perhaps another software detail to check: Are you using the command scheduler in WPILib? If your command scheduler is not killing the FWD command, even when the REV command is started, then you'll have conflicting calls to Motor.set() as Peter describes. It sounds like maybe the FWD command is only killed on the falling edge (rather than the rising edge) of the FWD limit switch signal.

Deploying a test project that checks a button or axis every loop iteration and sets the motor speed over CAN based on that (with only a single Motor.set() call, and without checking the limits at all) should confirm the hardware's behavior.

Congrats on your phenomenal win at Northern Lights! Looking forward to seeing more of it in the North Star webcast, and of course at Champs

[ozrien]

So which strategy did you use to wire limit switches? Are you letting the Talon do it internally or doing it yourself (like in Peter's example post).

I know the switches are wired to the Talon, but does it say "Normally Open" in the web-based drop down. You' mentioned "Normally Open" config but I wasn't clear if you just meant the wiring.

Might be easier to just post the code and screen shot the self-test when this problem occcurs.

I can tell you the firmware in the Talon definitely does not look at FWD limit switch when you are asking for REV throttle, and vice versa. There are several teams that rely on this to work.

The motor stutter tells me the problem is something else. The motor response should be consistent, almost sounds like a bouncing signal (loose cable or broken limit switch). Or could be code (post it?).

Who is calc'ing the Talon's throttle. Are you doing VoltagePerc mode and controlling throttle directly? Or are you using the Talon's closed-loop modes when the problem symptom occurs?

[wireties]

We are using the TalonSRX limit switch feature on three different motors with no problems. I would look for software issues and intermittent cable/connection problems in that order.

Good luck!

[DougJensen]

Thanks Folks. We are using the hardware limit switch inputs of the talon - no software is involved in limiting the motor. The config page is set to normally open.

Again, the switches STOP the motor properly in the appropriate direction. However, they Affect the motor when traveling in the other direction. Very simple test we do:
1.) Drive the motor in the FWD direction (continuous CAN throttle value which happens to be 100%.)
2.) Motor moves normally at high speed in FWD direction.
3.) Using a toggle switch to short the REV limit switch input to GND:
a.) Every time the switch shorts the REV input to GND, the motor stutters(like it is being rapidly modulated on and off - think of a multicylinder engine missing a few cylinders).
b.) Open the REV switch and the motor returns to high speed.

Repeating for emphasis: Opening/shorting the REV limit affects the motor when traveling in the FWD direction. (and vice versa.)

Although I haven't put a scope on it, it's almost like there is a high capacitance on the limit input and the weak pullup is causing the input threshold of the micro in the talon to get confused as the pullup yanks the signal through the Vih level. I have not tried a stronger pullup to test this, and I'm puzzled why the input signal is not pulled higher than about 2.3V - I assume the micro is running at 3.3, so I would expect the input to be pulled to that rail, not some 'soft point' like 2.5V.


It's great to hear some input from a CTR dude (thanks Omar) - in this case, I cannot explain how the FWD/REV limit input is affecting the REV/FWD operation. In cases where limit switches have short travels before the mechanism stops, they spend very little time actuated when transitioning at end of travel locations - and 'what we see' would be masked by the short time/travel required. In our design, we have a mechanism with lots of momentum that cannot be stopped quickly, even with braking enabled. This means our limit switch has considerable overtravel required. This requires the motor to travel a 'considerable' amount before the limit switch de-actuates - and during this portion of travel, the motor's operation is hampered by something in the talon/limit switch operation.

Sadly we are abandoning the hardware limit to go to the software limit operation through the dio ports on the rrio...But I'd really like to find the problem here. Thanks to everyone for taking the time to offer help.

[Alan Anderson]

Originally Posted by DougJensen

...I'd really like to find the problem here.

Have you tried a different Talon?

What kind of limit switches are you using, and exactly how are they wired? Do you have your own interface to the data connector, or are you using one of the encoder/limit breakouts?

[GeeTwo]

The simplest cause would be if the two limit switch signal lines are being intermittently shorted to each other. In addition to swapping out the talon as suggested in the previous post, I would try swapping out the cable, all the way from the tiny pitch connector on the talon to the limit switches. If the talon lights visibly flicker, it might also be interesting to disconnect the motors from the talons to see if the problem goes away when you remove the motor vibration and drop in battery voltage.

[Alan Anderson]

I wonder what a Talon SRX does if you short the data connector's power pin to ground. That sounds like a simple enough experiment, but I won't have access to one in order to try it until sometime next week.

[ozrien]

~2.5v is about right. That's just how the micro works. That's high enough.

You can try pull ups if you want, but it sounds like a harness issue.

So the self test will tell you what's going on. Assert each limit switch and check the io values in the self test while throttling. Also you can use the sticky faults to determine which fault is occurring. Double click self test button to clear them.

You can also use the programming api to instrument the Io values, and to potentially implement your own limit switch logic.