Neo Max or Facon 500 Programming Pros/Cons

We are considering standardizing on the Neo Max/Neo or FalconFX/Falcon 500 controller/motor and have decided the major consideration is software. Can you comment on the differences in terms of features, WPILIB support, PID and autonomous capability?

Note: please do not comment on the pros and cons with regards to non programming features.

1 Like

The Falcon/TalonFX has motion profiling/magic, the SparkMax doesn’t have it supported yet. The Falcon is interoperable with the other CTRE devices (which are very good), the SparkMax is pretty much a standalone because Rev’s FRC ecosystem isn’t as developed (quantity wise, I’m not planning on opening the quality discussion here). The SparkMax API does have a feature to follow a CTRE CAN motor controller, but it isn’t officially supported.
Neither is natively supported in WPILib - you need to include the vendor lib.
If you have experience with CTRE’s ecosystem (TalonSRX/VictorSPX) and want to continue using it, you would probably prefer the Falcon as it is an almost identical API. Dealing with both ecosystems can be a headache, as you would need to use both Phoenix Tuner and the SparkMax Client (that needs some work) and the devices don’t interoperate.
The Falcon’s built-in encoder has a much higher CPR than the NEO’s - better for PID/control. If you want to have decent positional control on a NEO, you would need an external encoder, that is then a headache with Alternate Encoder mode. However, if you want to do control based on a sensor that isn’t an encoder, the SparkMax might be more convenient as the Falcon has no external sensor ports - you would need to connect it to a TalonSRX or a CANifier.


I have never used a falcon 500, but I did use ctre software for talons and victors as well as rev.

We used neos with built-in encoders for 2020 drivetrain and our flywheel. In 2019 we used a neo running off a sparkmax following a talon with a mag encoder.

Our autonomous used the wpilib tools and wpilib characterization, neither had any issues.

In terms of unit conversions for the neo encoder its much easier since it gives position in motor rotations (only need to multiply by gear ratio to get output rotations) and velocity in rpm which was super nice for the flywheel this year. I know it’s a tiny thing but half the times when things don’t work in auto or with some other feedback loop its because of unit conversions.

Keep in mind that you can use the sparkmaxes with non brushless motors and with external encoders (as a talon replacement) for cheaper ($75 vs $90) so you don’t have to maintain a collection of functions for both ecosystems. As we had to in 2020.

As for prototyping mechanisms, the sparkmaxes were much easier because of the ability to run without a roborio with the USB cable.

The rev updating mechanism is nice with updating all the controllers over the CAN, but the ctre method of doing it wirelessly is still much easier and more reliable, rarely had any fails for ctre while the rev software can be very finicky at times.

My only experience with rev positional PID is with our arm in 2019, during the actual season we were planning to use a the sparkmax to follow a talon because we didn’t want to bother with more software APIs. That did not work natively, the workaround I found is detailed here in a post juju_beans made last year. During the off season I tried to get smart-motion working, the pid constants are way different than ctre’s so if you try the same values expect things flying around and violent oscillations. But I belive it would have worked if all the values we used for arm rotation were in degrees and not in native talon units (had to do some unit conversions which I think screwed it up).


One thing we didn’t like about the Spark Maxes this year was the hall effect encoder lag that came from the filtering. We use typically on RIO PID controllers and motion profiling from WPILib however due to the large amount of lag(~40 ms) of the NEO’s encoder measurement when getting its value over CAN from the Spark MAX we were forced to run all our PID controllers onboard the Spark Max. Keep in mind this is also an “issue” with the filtering on the Falcon 500/Talon FX however, CTRE provides the option to turn the filtering off and reduce the measurement lag to an acceptable amount with however the data without the filter is very noisy. Another thing to note is that this problem can be completely rectified by using an external encoder connected to the RIO such as the REV half inch hex bore encoder however, that requires design foresight. This is just something to keep in mind when buying the motors/controllers.

1 Like

From a pure-sw-implementation standpoint, competition between the companies has largely driven the same set of software features to be implemented on both devices. Though they’ve got slightly different names for features, I can’t think categorically of any major function that one does, but the other absolutely cannot do.

Rev is (or at least was) close to mostly open-sourcing their implementations, if that matters to you. Not sure where CTRE is on that journey.

Last year, I was nervous for falcons only because I hate to pick up things the very first year they’re available (or, at least, pick them up knowing we’ll be part of the “work the kinks out” group). However, both products are stable enough at this point that I’d call them roughly equivilant.

Additionally, keep in mind, new firmware comes out every year. Though I certainly don’t expect either company to “bork up” their product, there’s always the probability that they could change something in a bad way one of these years. Again, not at all expecting it to happen… but just pointing out that a decision made this year based only on software support could get invalidated in a future year.

I’d definitely poke a bit at your existing programming team, especially if they have experience working with both. If you’ve got the budget and time, a good test might be to build a simple arm mechanism, buy one of each motor, hook them up, and have the SW team do the exercise of installing/flashing/programming each motor from the ground up, to see which “ecosystem” they like better.

Personally I’ve found the Spark MAX Client to be very buggy which makes it difficult to set them up. Plus you have to plug in a USB cable to each of them rather than just configuring the entire CAN bus like you can do with Phoenix Tuner.

On the other hand, being able to plug in the USB cable is very handy when doing a quick test.

I’d go with CTRE stuff, because you have 3 different motor controllers to choose from with different price ranges (Victor SPX, Talon SRX, Talon FX + Falcon). Plus with the Falcons you get to play midi files. And if that isn’t a plus I don’t know what it.


I actually found that, at least once set up the first time, that the Spark MAX Client has a dropdown listing each of their devices so you can modify each MAX on the bus without swapping where the USB is connected.


You are talking about the USB-to-CAN interface: SparkMaxes with firmware v1.5.0+ can be used as bridges, and you can “communicate” with any device with firmware v1.4.0+.
It’s a nice feature, but it’s a bit buggy (maybe it’s just the client, but it doesn’t make much difference where the problem is). I think I still prefer connecting to the RIO. The client definitely needs some work, but Phoenix Tuner has it’s own problems - you can’t firmware upgrade a device without the whole CAN network. That is one of the advantages of the SparkMax client, but I would like the option to connect to the RIO.


REV has Smart Motion, which AFAIK is a trapezoidal velocity motion profile.


When was this added? Last I checked, the modes were: DutyCycle, Voltage, Position(PID), Velocity(PID), and there was SmartPosition and SmartVelocity that are the same as their “non-smart” counterparts with the addition of following the ramp limit/config.

EDIT: I opened the SparkMax docs and SmartMotion is motion profiling.

In practice, the CPR of the NEO built-in encoder is almost always sufficient for positional control. The NEO has 42 counts per rev. However, if you are using the motor for positional control of something, you will invariably be gearing down the motor output. Let’s say you are using the NEO to move an arm and the gear ratio between the motor and arm is 64:1. The 42 counts per rev of the motor now become 42 * 64 = 2688 counts per rev of the arm or resolution of 0.13 arm degrees per motor encoder count. That effective resolution is better than many external encoders that could be attached to the arm. 0.13 degrees is also going to be less or much less than the mechanical backlash in almost any FRC mechanism.

If you are trying to stop your 1:1 shooter wheel at an exact spot, the NEO encoder is not the right choice, but for the typical reduction range between the motor and final actuated element, the NEO is completely sufficient for position control.


I forget, what should an encoder be closest to - the motor or the output shaft? (tldr: before or after the gearing?)

Ideally, closest to the end rigid body whose motion you are trying to control.

That’s not to say you can’t put it elsewhere (especially for mounting or cost considerations). But, if it’s elsewhere, you have to either account for things like gear lash and slack adding to your measurement error, or assume they don’t exist (and design the mechanism and control logic such that they truly don’t matter).

Like anything else, it’s an engineering tradeoff.

Placing an encoder closer to the actuated element is often desirable to minimize the effect of backlash in any mechanisms between the motor and actuated element.

There is a tradeoff to be considered between taking advantage of a built-in encoder on a brushless motor vs the more direct positional measurement of an external encoder on an actuated element. However, if you are comparing motors on their built-in encoder resolutions, this tradeoff is a separate question.



I wish both vendors would just call it “motion profiling” to avoid confusion. Motion profiling is the standard term for it.


That’s the thing, initial set up is a lot more difficult because the CAN IDs are all 0. Phoenix Tuner deals with this nicely and allows you to easily assign motor controllers different CAN IDs even if some are the same. With the Spark MAXs you have to plug the USB into each one and configure them individually since I don’t think it likes when you have multiple devices with the same CAN id.

I don’t remember a single time during the season were we successfully were able to configure multiple Spark MAXs over a single USB connection even when the CAN IDs were different. We’ll have to try it out next year.

Also, we spent 20 minutes trying to configure a single Spark MAX one time (on its own without CAN), only to find out that we had to change its CAN ID from 0 to something else (0 is a valid CAN ID I don’t know why we had to change it to get it to work (and this was for testing purposely)).

We initially config our Maxes before they go on the bot.

Let’s break this down.

The Spark Max does have an approximately equivalent feature, the Smart Motion stuff. It’s named differently for vendor hype.

The feature REV wrote observes bare CAN frames almost certainly, but this is going to keep breaking unless CTRE keeps their frame format the same, which they have no reason to due so given their ongoing litigation with Diligent Inc. and basic business senses.

For certain teams, the occasionally obtuse and odd behaviors of the CTRE API, this is a good thing.

You would want an external encoder regardless, given that effective resolution is useful when you have as little backlash as possible in a mechanism, not something teams are known for being perfect at given the mechanical complexity.

While we’ve definitely had issues with the Tuner being buggy at times, the most recent updates that allowed bus-wide firmware updates is lovely and greatly alleviates that workflow. I’ve seen others in this thread that say they had issues, and I won’t discount the possibility we got absurdly lucky with our setup.

I’d list issues I’ve seen people have with the Falcons, but the majority of them weren’t controls issues.

For the time being though, if we want to use a brushless 550 class motor, we have to use a Spark Max. CTRE doesn’t sell an equivalent product even if we wanted to use it. And don’t take this as a knock on the Falcon, I love the options being introduced for brushless control in FRC nowadays, none are perfect, but objective analysis and avoiding FUD are essential.


I hope they don’t, because while SmartMotion and MotionMagic are both motion profiling modes/algorithms, they are very different in implementation and execution.

(SmartMotion closing the loop of velocity and MotionMagic closing the loop on position)

1 Like