How are you sending commands to the SPARK MAX; PWM or CAN? When in neutral, do you observe a magenta (or yellow) LED, then after it switches to brake mode do you observe a cyan (or blue) LED when in neutral? Are you mapping the joysticks/analog sticks directly to the control commands?

Please send me some video of the behavior to Please reference this CD thread.

I’m asking some the questions above to try and understand if the controller is truly switching to brake mode, or if it may be stopping due to other reasons.


Are you seeing choppy behavior when holding a constant output, when actively adjusting the output, or both?


What method are you using to control the SPARK MAX; PWM, CAN, or USB? Is this during teleop or autonomous?

Please send video of the behavior to Pleae reference this CD thread.


It seems to happen during both holding steady at a company and during changes.


Also, I’ve tested 2 motors and 2 controllers. Identical behavior in both. When I plot hall effect position, I do see the random reset of the position as well. I got to believe this is related.

Also, if no one has said so, thanks for working on the weekends and answering these posts.


No problem! Could you send some video of the chop when running from the Client, both holding steady and changing speeds?

If you can, try the same experiment with a brushed motor.


I just tried the client and it didn’t show the choppiness. Switch to labview -PWM, and the choppiness was there. So I guess I was wrong that the client had that behavior.


I think I just solved it with the help from this:

Packet losses were throwing the motor controller into neutral it seems. I changed computers and it tested stable.

I’ll continue to test but far better than before.



So are there typically more or fewer packet losses when connected through the FMS vs. directly to the robot at home? Laptops that were perfectly fine communicating with robots last year should not suddenly become obsolete. And replacing them should not become the recommended course of action. I expect more. Waiting to see what REV, WPIlib people come up with.


New problem similar to others posts.

I’m now getting a magenta/orange blinking light suggesting a Brushless Encoder Error. Sticky Faults show a Sensor Fault.

This only happens when I switch modes to Velocity or Position. Going back to Percent Vbus, everything seems to work fine.

Any ideas on what’s causing this? Triple checked the cable, FYI.

We are connected using CAN.

One additional question, if we switch to PWM we can’t use closed loop internal motor controls can we?


Is there an update for the LabVIEW API to address this, or did this issue only affect Java/C++ teams?


Only Java/C++ teams. The API is slightly different for LabVIEW, and already includes a timestamp for those calls that can be read to see if the data is stale.


What are the native units for duty cycle on the motor controller that interface with the PID gains? Is it truly a -1 to +1 internal on this controller or is it similar to the TalonSRX where the values range from -1024 to +1023? I am looking into calculating F gain as a part of writing my own “Motion Magic” implementation for this controller. Right now I just tune it empirically, but I would like to be able to calculate it as a starting point before tuning to get close.


Yes the units internally are -1.0 to 1.0 (percent duty cycle).


What are the units for FF? Is it just 1/maxRPM or is there more? Thank you


The ‘Feed-forward’ gain (using setFF(gain)) is simply a gain which is multiplied by the setpoint. You can see how this is implemented here.

The ‘arbitrary feed-forward’ is different, the unit for this is ‘volts’.


Cloesd loop with CAN. The team took some video yesterday and were planning to send to you.


How is the Spark Max able to map encoder ticks to rotations for encoders with a varying number of ticks per rotation? My understanding is that the Spark Max is compatible with all quadrature encoders, and I don’t understand how it can map all of those types of encoders to rotations without any configuration on the user’s end.


I am having trouble with one of our SPARK MAX controllers. Here is a video:
SPARK MAX odd behavior
This is over USB.
I also cannot connect to this controller over CAN.
After the video, I re-flashed the firmware, and was able to run the motor over USB. However, the motor ran significantly faster than it should have and I immediately unplugged the controller. The LEDs do not indicate any known failure modes, nor was I able to reproduce this on the other 3 controllers. I also tested the motor on another controller and it ran fine.


Try running with USB with the CAN cables unplugged. Then try the opposite. Be sure you are setting your CAN IDs and saving the configuration with the Client application.