Spark or Talon and CAN or PWM

For our Rookie team would it be best to use the provided Spark motor controllers and spend more $$ to get 2 more Talons ? Would it be best to use CAN or PWM for connecting the motor controllers ?

The Sparks should be put on your highest load motors.

      As for PWM/CAN, what language is your team using? I know that LabVIEW has been having trouble with using CAN motor controllers, so if you use that, use PWM. In general PWM is less difficult to make work.

Unless you plan to use the advanced closed loop features of the Talon, there’s no need to double your expenditure.

Sparks only support PWM, Talons support both. The aforementioned closed loop features only work over CAN.

In your place, I would stick with the Sparks. There’s nothing wrong with PWM, and unless you want to do motion profiling there’s no reason to use Talons.

Thank you for this thread and advice. I think this very helpful as a second year team that is just experimenting with CAN and closed loop. The follow up question I have is this.
If one wants to close loop the drive base, would you reccommend 4 talons (one for each cim motor, purchasing the new Victor’s, for two, or could we use the old Victor’s for two. I want to try to make the closed loop in the data port to free up resources from the Rio.


Sent from my SM-T810 using Tapatalk

You can use 4 Talons (probably the safest bet), or 2 Talons and 2 Victor SPXs (a little risky, as they are brand new this season).

2 Talons + 2 VictorSPs would not work, as the Talons cannot communicate with the VictorSPs (only the RIO can).

Thanks. That was my thought. We have the new framework working on our benchtop test right now. We do not have the new Victor’s, but may invest as a cost saving measure. If we do that, we may plan talons as a backup (drop a closed loop elsewhere).

Sent from my SM-T810 using Tapatalk

If you plan on utilizing the closed loop features of the Talon SRX’s you only require one Talon per side. The second motor can then be controlled by the cheaper Victor SPX by utilizing the follow command in the new Phoenix framework. Personally I prefer CAN to PWM as PWM connections have fallen off our robot in previous years. CAN is slightly slower then PWM but I have not noticed the speed drop.


As for PWM/CAN, what language is your team using? I know that LabVIEW has been having trouble with using CAN motor controllers, so if you use that, use PWM. In general PWM is less difficult to make work.

As a LabVIEW team, we haven’t had trouble with CAN since we last used Jaguars in 2013. What trouble do you know of?

I’m interested as well, we swapped to CAN off of PWM immediately after our rookie year and haven’t seen any issues. Would be good to know about any, just in case.

A lot of people are having trouble getting labview running with the new libraries, but we have been successful thus far. We are using labview as well. Last year we used sparks, and did not know about PID or have any real deadband control. Our robot was top heavy to boot so it was incredibly jerky. It was to the point that we just used two motors to drive.

Our solution was to have a limit slider in the driver station and a trigger to give full throttle after we got going.

It was useful, but we would like to avoid the necessity this time around.

Is it safe to say this is due to programming and mechanical design rather then speed controller choice?

This is definitely a possibility.

The Sparks have a higher peak amperage than the Talons and thus can handle the higher load motors better.

Since 2017, to use CAN you need to download the CAN libraries. This can be difficult for newer teams and prevents the easy sharing of code between teams that have included the library and teams that have not.

The Talon SRX and SPARK have the same current ratings for both peak and continuous operation. 60 amps continuous, 100 amps for 2 seconds. Exactly what the parameters under which those limits are determined is a good question, but I suspect they’re conservative enough we don’t have to worry about it.

In any case, both controllers have been used with success in very high current FRC applications.