I emailed CTRE to see if they would be restocking the CANifier. They said they decided to discontinue the product. This is very disappointing news in light of their decision to remove the physical limit switch ports from the Krakens - we had been planning to use CANifiers to handle all our limit switches. They suggested “joining our email list since we have some new products coming out that may be of interest”, so maybe they’ll have something else coming out before season - bets on it being $100+?
Does anyone have any clever and easy alternatives that don’t involve the DIO ports on the Rio? I know you can use CANcoders as a hall effect sensor, but its a little ridiculous to use two $70 magnetic encoders when cheaper and more flexible digital and physical options exist. We had also talked about using old TalonSRX motor controllers and their 10-pin ports for Talon Tachs, etc, but again, it seems like overkill to use a whole motor controller just to read two limit switches.
RTFMr’s, can you connect multiple TalonSRX controllers to one PDH slot if you are not using them to power motors?
My guess is they are referring.
to the CANdi digital input can device they recently trademarked.
To your quetion about the dio ports, you dint have many optios currenty for “easy” soltions beyond a remote talonFX (or srx if you want to do manual integration) or cancoder, honestly, routing a wire to your dio ports isnt too bad.
Honest question, how many limit switches would you anticipate needing? I don’t recall needing more than 1 or 2 on a robot.
If you’re using any brushless motor, you have a built in encoder so it’s fairly easy in many cases to just detect that you’ve hit a hard stop and stopped turning. Or use an absolute encoder it it’s a rotational mechanism; the Thrifty encoders are only $30 and go directly into a Rio analog port, or you spend the $70 for a CANcoder.
Is there a particular reason you’re avoiding DIOs? They are almost certainly going to be the cheapest way to do this, and they work fine…
I love having at least one limit switch on every subsystem. Encoders are great but unless you have the code to re-home your position by looking at current draw, a slipped belt or a brownout combined with no limit switch means your elevator, intake, arm, etc is useless for the rest of the match. Non-absolute encoders also mean the starting condition of the robot has to be pretty precise every time. Throwing an absolute encoder on a system isn’t always trivial.
Also, when students are coding robots, having hard limit switches embedded at a firmware level is amazing, or the first thing we do is add limits to the code. I can’t tell you how many times a bold programmer in a rush has partially destroyed a mechanism while tuning PID or motion magic before we had limit switches in.
I’m honestly surprised you can get by with one limit switch. Honestly, I prefer to have redundant limit switches on critical systems - this has saved us multiple times when a wire gets pulled out or a sensor gets damaged.
Why don’t I like the Rio ports? A: I prefer to tape those ports shut to keep shavings out. B: Absolutely hate using PWM cables that have no physical locking mechanism to keep them from getting yanked out. C: Running wires all the way back to the RIO can be super annoying. Year before last we had a beam break sensor on the end of a double-jointed arm, total wire length if we ran it back to the Rio would be something like 2.5 meters, as opposed to 10cm into a limit switch port on a Falcon.
So, while likely not the exact same situation, we had a few similar problems this season that would have been solved by CANifier.
For starters, our shooter mechanism was out on the end of an arm, and utilized 3x beam-break sensors to detect the note and ensure it was positioned correctly in the mechanism prior to revving it up and shooting. Additionally, the mechanism had two axis of rotation: one for the arm, to raise the shooter up and down, and one for the “wrist” which rotated the shooter to the appropriate shooting angle, and obviously any joint you have to run wires around is a potential failure point (our extending arm in 2023 also had similar concerns).
Because our shooter was using Krakens, we were already running our CAN bus out to the end of this mechanism, and it would have been significantly easier (and less prone to one of the sensor wires failing) if we could run all of our analog signals from those sensors on the shooter (we did analog for simplicity rather than adding resistors to make them work like switches) via the existing CAN connection, rather than adding 3x more sets of PWM wires down the entire length of the mechanism.
As to avoiding the ports on the RIO, for us, it mainly comes down to connection reliability. I’d much rather solder or use ferrule connectors for connecting things to CAN instead of needing to deal with the PWM headers on the RIO, or having to hot glue everything in place every time.
I agree with some of the other discussions though, I highly suspect CANifier will be replaced at some point (hopefully soon) by some kind of updated version of the product (it especially makes sense since CANifier didn’t support CAN FD, which CTRE seems to be trying to move everything to).
Yes, you do need a way of initial zeroing (either starting from a known position or an automatic cycle-to-zero if that’s feasible). Having a way to re-zero on command is definitely advisable.
With built-in encoders, you can look for motor velocity=0 rather than change in current draw.
Limit switches and their wiring, especially if relying on the little adapter boards or fragile connectors that too many controller manufacturers use, can be significant failure points too. If you’re reliant on one to keep your mechanism from self-destructing, one tiny disconnected wire or flaky switch could make for a bad time.
This is a concern no matter what your protection mechanism is. “First do no harm” is a good mantra! In 2023, we had a system of arm software e-stops in place before we ever powered up the arm for the first time, as we were terrified of wrecking the joint. Literally.
I can think of one place (2022 climb arms) where we had two, one per side. Some robots have none; we’ve usually managed to find other solutions, and in the era of modern smart brushless motors it’s gotten easier.
I hear you on all 3 points. To address connection reliability we have been using Swyft interface boards that provide JST-XH connectors that are a lot better, especially with a spot of hot glue. (And we still tape over unused ports.) But yes, long cable runs, especially going way out a mechanism, isn’t ideal.
Part of me hopes that the CANdi has a similar form factor as the REV Servo Hub. Plug and play, mostly, still gotta code it, no more soldering like the CANifier. Well, you might solder/crimp wires onto limit switches.
Nevertheless, I am excited to see what CTRE has been cooking
Best practice with limit switches is to set them up so that if a wire is cut, or other common failures occur, the motor stops. I dislike having RIO S/W in the loop for a limit switch, since you are now one coding error away from bad stuff. I’m still in the camp of wanting hardwired limit inputs on the motor controller.
With a CAN-FD CANdi (or whatever it will be called), at least it’s all in CTRE F/W – provided the system sets up for fail-stop behavior, which is a major qualifier. (The enable/disable handling on the driver station is mostly fail stop, for example.)
True, but this might be one setting you’d only expose in Phoenix Tuner. Even without this restriction, the coding error would be a less likely one. To be clear, I’d still much rather have hardwired limit inputs – but the same sort of configuration error could cause the same problem there, unless you have a cover/jumper that has to be installed when the limit switch isn’t being used (or go with normally open limit switches, not ideal).
I’ll be interested to see the new offering and how it works (assuming of course, that such an offering is forthcoming).
