Why do most teams use CAN over PWM. PWM seams better if it becomes unpluged you only loose one motor over everything after the problem.
PWM is one-way communication. CAN is 2-way.
If you use CAN, you don’t need a bazillion sensor wires coming back to the RIO to tell it what the motors are doing.
You can also have a lot more devices on CAN than pwm
CAN generally allows you to use “smart” motor controller features, including:
- Built-in PID loops run directly on the motor controller, allowing for precise position and velociy control
- Current limiting
- Easier use of encoders and limit switches attached to the motor controller
Furthermore, CAN has a higher ceiling of devices (there’s probably a way to get more but by default the RIO only has like 10 PWM slots, vs. up to over 100 for CAN), and allows you to configure encoders, limit switches, etc. directly from the MC, while simplifying wiring as everything goes back to the MC itself rather than a ton of ports on the RIO.
I think there is a place for both. Using swerve as an example, we use direct Analog inputs into the RIO to initialize the module position and then use the motor encoder for control from that point on, so we do not rely on that analog input for control. The motor controllers are connected via CAN. But generally, the motor controllers can be located in a protected location on the robot where those wires are not at risk of damage. For our arm this year, we did something similar where we used the REV through-bore encoder for initialization and then the motor encoders for control.
CAN is very powerful, but does represent a single point failure, so it needs to be protected. Analog sensors can be used to sense the position of a mechanism, but if the wires are exposed to potential damage, it us best to not rely on those wires for mission critical functions.
To add to what others have said, another issue we’ve found with PWM is it’s much more vulnerable to electromagnetic interference than CAN is. Last season I worked with a team whose robot (which exclusively used PWM for motors) would not run at all, in spite of all the wiring looking fine (or at least, plugged in correctly), we put some Ferrite cores on the PWM wires to suppress any potential EMI and it immediately started working again. The EMI from all the motors was actually enough to prevent the robot from running at all.
CAN networks can introduce single points of failure, particularly in daisy chained configurations. My team has gotten around this by using a “Bus” configuration instead of daisy-chaining devices and it’s worked very well for us for the past few years (albeit, there are some limitations to doing this).
Another benefit of CAN is that with all the CAN sensors available now (not just the motors themselves), having a CAN network means you can easily connect sensors to the network since sensors are often located very close to motors, thus reducing the number of wires you need to run back to the RoboRIO. CAN makes electrical much easier and cleaner, when done correctly.
What everyone else said.
Also, PWM connection to the RIO and many motor controllers is through Dupont connectors. They’re pretty decent inside a computer or other device that doesn’t move around very much. An FRC robot, not so much.
Also, CAN allows “follow me” where one motor controller slaves itself to a different controller. That’s very useful when you’re running a gearbox with multiple motors or putting motors at opposite ends of a shooter shaft.
That said, PWM lets you control a motor from a very simple device without having to write ANY software. Very useful in prototyping.
PWM’s simplicity is unmatched. I’ve been pushing for us to use PWM on simple, encoderless actuators such as an intake or simple singulator due to how much simpler it is to wire (plus, it’s one less failure point for CAN), but unfortunately I have been unsuccessful.
Although in small prototypes, CAN is generally almost as simple as PWM (either way, it’s a connection or two and a PD* connection).
Technically you can do this over PWM through software too, but it’s definitely simpler to implement with CAN (probably less code overhead too). EDIT: bobbysq had an even better solution below
I will agree with you on your last point though. We used to be able to use those little Thrifty Throttle devices to run PWM controllers for testing and prototypes which was way more convenient than the ordeal you have to go through to get any CAN motor to work (especially getting around the RIOs heartbeat restrictions).
PWM also allows follower mode with no software changes needed:
As far as I know, every legal CAN motor controller also supports PWM, hence why Victor SPXes and Falcons ship with Dupont connectors on their CAN leads. You won’t have any sensor feedback, control loops, or most importantly for brushless, current limiting though.
Ok. PWM doesn’t do reverse follower mode, where one motor turns clockwise and the other turns counterclockwise.
Don’t you have to put them into like a “PWM Mode” in the case of the SparkMax and Falcon though? I was under the impression it was not a simple as just connecting a PWM wire. In the case of the SparkMax in particular you have to replace the actual connector on the controller with the PWM one too.
Plus, aside from that, I have to assume a fair number of teams running CAN aren’t using the stock Dupont connectors due to the obvious reliability issues with those connections.
You just gotta wire the motor backwards on one of the speed controllers. This doesn’t work on brushless motors, though.
You could just flip the output leads
As far as I know, you don’t have to do that, but I think the only time I’ve personally used PWM with a CAN motor controller was with a Talon SRX. The Spark MAX documentation indicates it auto-detects.
I hope so. The clips they give you seem to help but there’s just far better options out there between lever nuts, various JST connectors, and the Molex connector next year’s KoP will supposedly come with the crimper for.
CAN if you want to know what the motor did instead of sending signals blindly. Otherwise PWM works fine. With good connections, neither will fall out.