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]

Originally Posted by 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.

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]

Originally Posted by 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.

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]

Originally Posted by King Nerd III

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]

Originally Posted by Alan Anderson

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]

Originally Posted by King Nerd III

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]

Originally Posted by Alan Anderson

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]

Originally Posted by 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.

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]

Originally Posted by King Nerd III

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]

Originally Posted by wireties

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]

Originally Posted by 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.

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]

Originally Posted by King Nerd III

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?