Inverting Talon SRX

[King Nerd III]

So a few days ago we were putting together the code for an elevator and realized that the limit switches were backwards, basically the top limit switch stops it if it is going down and bottom stops it if it is going up. We are using the Talon SRX with the CAN bus and I was just wondering if there would be a way to invert it in the code? I know we can do it physically, and will probably end up doing that, but code would be much easier. I looked in the manual and couldn't find anything, so maybe it is hidden? I know with a Talon SR we can do random_motor->SetInvertedMotor(can't remember if it's bool); but it doesn't work with an SRX. Any ideas?

[FrankJ]

The procedure is documented in talon programming manual. But the "forward" limit switch stops the controller in the "forward direction" That might be down. Also if you are using normally closed limited switches you need to set that in the talon web dashboard. The default is N.O.

[King Nerd III]

The procedure is documented in talon programming manual. But the "forward" limit switch stops the controller in the "forward direction" That might be down. Also if you are using normally closed limited switches you need to set that in the talon web dashboard. The default is N.O.

I looked in the manual in there really is nothing as easy as random_motor->SetInvertedMotor(); which is inconvenient. A search of the manual brings up inverting a slave motor, but it doesn't really help. I think we will just stick with moving the forward limit switch to the bottom, and reverse to the top.
Thanks for the help!

[ozrien]

You will need to fix it in the wiring. If the Talon is green (positive throttle) it will only check the forward limit switch. What causes the Talon to be green (closed-loop, slaving, slave-invert) instead of red (Reverse) can be controlled by Reverse Sensor and Reverse Closed-Loop output. But the limit switch is compared against the final output.

[King Nerd III]

You will need to fix it in the wiring. If the Talon is green (positive throttle) it will only check the forward limit switch. What causes the Talon to be green (closed-loop, slaving, slave-invert) instead of red (Reverse) can be controlled by Reverse Sensor and Reverse Closed-Loop output. But the limit switch is compared against the final output.

Yeah, that's what I thought. I wish we didn't have to do that, but as long as it works it's fine.

[Alan Anderson]

I know with a Talon SR we can do random_motor->SetInvertedMotor(can't remember if it's bool); but it doesn't work with an SRX. Any ideas?

The SetInvertedMotor() method is generic to any motor speed controller. What makes you think it doesn't work with a Talon SRX?

[King Nerd III]

The SetInvertedMotor() method is generic to any motor speed controller. What makes you think it doesn't work with a Talon SRX?
The fact that when I do the following with a CANTalon object:
right_motor->SetInvertedMotor();
It says it can't resolve SetInveretedMotor(), and also the header files for both CANTalon and CANSpeedController do not have this method.

[Alan Anderson]

The fact that when I do the following with a CANTalon object:
right_motor->SetInvertedMotor();
It says it can't resolve SetInveretedMotor(), and also the header files for both CANTalon and CANSpeedController do not have this method.

I don't see that method in the non-CAN Jaguar or Talon headers either. I'm pretty sure that's because it's a RobotDrive function. Are you able to get a random_motor->SetInvertedMotor(true); to compile when random_motor is a Talon SR, as your original post implies?

I should stop being subtle. It isn't working.

[King Nerd III]

I don't see that method in the non-CAN Jaguar or Talon headers either. I'm pretty sure that's because it's a RobotDrive function. Are you able to get a random_motor->SetInvertedMotor(true); to compile when random_motor is a Talon SR, as your original post implies?

I should stop being subtle. It isn't working.

Nah, that doesn't work either. I agree that it is probably a robot drive thing, which won't help with an elevator.

[wireties]

And like Omar said this is all internal to the Talon - when it is green it is looking for the "forward" limit no matter the software convention.

[King Nerd III]

And like Omar said this is all internal to the Talon - when it is green it is looking for the "forward" limit no matter the software convention.

That kind of sucks, now we have to unsolder and all that. The last time we soldered was a nightmare, I don't want to go through that again!

We'll do it, though. For the team!

[wireties]

That kind of sucks, now we have to unsolder and all that. The last time we soldered was a nightmare, I don't want to go through that again!

We'll do it, though. For the team!

Use connectors for all sensors and motors so they can be removed/replaced easily. It makes repairs (especially under stress) much easier.

[King Nerd III]

Use connectors for all sensors and motors so they can be removed/replaced easily. It makes repairs (especially under stress) much easier.

We're using an encoder breakout board so it has to be soldered, we don't want to risk it coming apart. But we did this:

[board]~~wire~~[pwm connector][pwm connector]~~wire~~[sensor]

It works well enough!

[jhersh]

And like Omar said this is all internal to the Talon - when it is green it is looking for the "forward" limit no matter the software convention.

Is it really that important that forward be up!? I get that it's a little more straightforward, but if you reverse the output and make the top "red" and the bottom "green" then you don't need to rewire, right? You were wanting a software workaround, so a slight inconvenience of needing to invert a number seems reasonable.

[wireties]

We're using an encoder breakout board so it has to be soldered, we don't want to risk it coming apart. But we did this:

[board]~~wire~~[pwm connector][pwm connector]~~wire~~[sensor]

It works well enough!

So just reconnecting the PWM-PWM interfaces for the 2 sensors should fix things?

[King Nerd III]

So just reconnecting the PWM-PWM interfaces for the 2 sensors should fix things?

For one set, yes. I wish we had done both at the same time, one of the pairs is soldered directly to the board seeing as it is within 7 inches of the electronics.
We had a snow day today so no robotics, but on Saturday I should be able to rewire the entire thing.

[GeeTwo]

So just reconnecting the PWM-PWM interfaces for the 2 sensors should fix things?

If one cable goes to the upper, and the other goes to the lower, yes, swapping those PWMs should electrically move the limit switches to the proper location.

[Ether]

You will need to fix it in the wiring. If the Talon is green (positive throttle) it will only check the forward limit switch. What causes the Talon to be green (closed-loop, slaving, slave-invert) instead of red (Reverse) can be controlled by Reverse Sensor and Reverse Closed-Loop output. But the limit switch is compared against the final output.

Is it really that important that forward be up!? I get that it's a little more straightforward, but if you reverse the output and make the top "red" and the bottom "green" then you don't need to rewire, right? You were wanting a software workaround, so a slight inconvenience of needing to invert a number seems reasonable.

Hey Joe, Omar: Are you guys saying different things? Or am I missing something subtle (or obvious?) .

[jhersh]

Hey Joe, Omar: Are you guys saying different things? Or am I missing something subtle (or obvious?) .

I can't speak for Omar, but I'll guess he meant what he said, assuming that the team wanted the polarity of the control values to remain unchanged. My assertion assumed that polarity is a rational trade off to rewiring.

[FrankJ]

I think what Omar is saying (not to put words in his mouth :) ) is the limit switches work directly on the output of the controller which there is no reversing. IE the green & red leds relates to the polarity of the output.

Hopefully Omar will confirm or correct this.