In previous years, my team has used both Digital and Analog Inputs (limit switches and pressure pads, mostly) to stop a motors rotation in a certain direction. Up until this year, we have always written the code to control this ourselves and it has worked decently. However, while reading over the CTRE Pheonix Documentation, I came across the use of limit switches and soft limits. I am slightly confused on what the documentation meant (https://phoenix-documentation.readthedocs.io/en/latest/ch13_MC.html#soft-limits) and I was wondering what everyone’s opinion on the topic was. Is it better to custom write limit switch logic for motors, or does the CTRE library give us the ability to use AI and DI for limit switches? Note: my team is using SPX/SRX only for this.
We have used both the soft and “hard” limits of the Talon SRX. We found this was easier than writing our own logic to set limits for the mechanism.
When the talon is told to use the limit switch, if for example the forward limit switch is triggered, and the motor controller is commanded to drive forwards, it will not. the same applies to the reverse limit switch and driving backwards.
The soft limits are essentially virtual limit switches based on an encoder value. You can set a virtual limit at 1000u for example and once the encoder measures a value 1000u or greater, it will not drive in that direction as if a limit switch was triggered.
We used this feature last year when the limit the mechanism could extend changed depending on the configuration of the robot, this meant we could not use a limit switch and instead used the soft limit function, as it can be updated on the fly.
The feature of using limits with the Talon SRX and Victor SPX, only works if the limit switch is wired directly into the sensor port on the Talon SRX or into something that can act as a remote feedback device, such as another Talon SRX or a Canifier (as is required for the Victor SPX as it has no data port).
As a bonus of letting the Talon SRX manage the limits, is that if a “hard” or soft limit is triggered, it will display a red flash pattern on it indicating why it will not drive.
My personal preference is to let the Talon SRX act on the limit values itself, thus eliminating the possibility of me or someone else breaking the code (and limits) accidentally. This and because of the flash pattern that helps with debugging.
Thank you so much!
No problem!
Also note that doing the work in Talon gives you 1ms resolution instead of ~20ms you get with the wpilib scheduler.
As long as your motors and encoders are in phase, and you can guarantee the starting position when your relative encoder is instantiated then it works well.
The year we did this we also had an absolute encoder which we would use to “zero” our relative encoder on startup"