The second test done (when I got the really high speeds) was with CAN removed. I have triple-checked the CAN ID as well.
It does seem to be getting a CAN connection now, though it doesn’t respond to power commands at all. It blinks purple, with tiny bursts of orange.


We’ve only gotten the chance to test this now as the robot that had the neos on was on build’s side, but we’re still experiencing this problem with the new software update: once in a few seconds the encoders give a value of 0 instead of their actual reading.
I’ve also tried adjusting the setCANTimeout to 10ms and 5ms, with no notable difference between them. Is anyone else still experiencing this problem?

As a temporary fix, I’m averaging the values of the three motors on each side and if one of them is 0 then I’m excluding it from the average. However, this shouldn’t be the permanent solution and honsetly I still don’t understand where the problem is coming from. Help really appreciated.


I’ve found a better temporary fix is to have a variable keep track of the most recent encoder value. Initialize it with a value of 0 and then each cycle, if the value reported by the spark max is not 0 update the variable with the new value. Then you can use the variable for your encoding needs.


As a temporary fix I agree that’s better, but if I want to do more complex motion profiling it wouldn’t be that good if I have to skip packets… Also do you know if this will affect sending packets to the built-in PID controller?


Can confirm, using the Spark MAX Java API, the NEO encoder will still randomly (but less frequently than before) report the reading as 0 and then jump back to its prior reading.


We’re re-opened this issue and implemented a fix on the firmware side (some notes in on card). This will be rolled out with our next firmware & SDK update.


I’m having several issues with my Neos and Sparks as well. When I tried to run the motors (connected via CAN) with labview code in velocity closed loop mode, they kept jittering uncontrollably.

I switched computers and did the same setup but they still were going ballistic like they did in this video:

I ditched the labview code and went straight to USB. I cleared the PID gains (p was the only one active with a value of 1) and the motor would go for a little while, start slowing down, and then ramp back up. It did this over and over again. Then I tried disconnecting the CAN wires and it worked just fine.

So I switched back to the original computer I was using and updated the API. It is still jittering with the spark giving off a mixture of yellow, red, and green lights which I assume means that its fighting itself and the CAN malfunctioning. Is there going to be a fix to this soon? Thank you all so very much for all of the hard work that you’ve been putting in to solving these issues!


Give REV a call during office hours, and they can walk you through some basic troubleshooting that may point to an issue you overlooked. They found an odd parameter set on my troublesome SPARK MAX, and emailed me a factory default firmware that fixed it.


I noticed this same behavior in velocity mode.

I found out that the ‘gear ratio’ parameter, used to scale the position and velocity, defaults to 0 or was somehow set to 0 on our Sparks. It seems like the position/velocity feedback signals return raw (unscaled) when the gear ratio is 0, probably as some division by 0 protection, but the velocity command (and possibly position, which we didn’t try) multiply by 0 to get a 0 command. This makes the Spark control very aggressively to 0 velocity, which is why it appears to twitch. Setting the gear ratio to 1 fixed it.

I do agree that the documentation did not make this clear. There is also no VI to set kGearRatio, but if you open one of the other set VIs and copy out the Spark MAX Set Parameter VI and call it with kGearRatio it works (or you could set it through USB).


The units for velocity are ‘RPM’, so think about the effect of applying a P gain of 1.

If you set say 500 RPM, the robot starts at 0 RPM, the controller sets the value to (500 - 0) * 1 = 500, the controller limits this to an output of 1 or ‘100% output’ (assuming you’ve set the max output to 1).

As the robot speeds up, say it is at 450 RPM, The controller sets the value to (500 - 450) * 1 = 50, still limited to 1.

As the robot speeds up even more, say it gets to 499 RPM, (500 - 499) * 1 = 1, which is still full output.

It is unlikely that your system can decelerate at this point, and it is likely the system will go past 500RPM. Lets say it goes only slightly over to 501RPM. (500 - 501) * 1 = -1 or full reverse!

At that point the robot will go from full speed forward to full speed reverse. The same problem happens in reverse, and the system will keep switching from full forward to full reverse. For PID control this is called ‘underdamped’ or ‘unstable’.

If you haven’t already, I would encourage you to look at the sample code that we have for velocity control, and look at what sort of gains we used as a starting point.

We don’t have a VI for this, or a corresponding API call/documentation in Java/C++ because this functionality has not yet been implemented. We have it on our near term roadmap here.


I have also tried it with 0.2 and 0.001 for the p with similar results but thank you for the advice


I suspect it is still underdamped even with these values. You should take a look at the gains that we use in our velocity control example as a starting point.


Well the PID works at 0.0001 for P. There is nothing more satisfying than the calm hum of a brushless motor. Thanks!


We just released a firmware update tonight. This update is minor and not required, but fixes some reported bugs (see below)

You can download the latest firmware here


  • Fixes GetPostition() randomly returning 0.
  • Fixes momentary velocity spike when accelerating from 0 speed.
  • Fixes issue related to rapid control mode switching by the user.
  • Fixes issue related to extreme low voltage CAN bus operation.
  • Adds conversion for motor temperature.
  • Improvement to “Has Reset” flag.
  • Improvements to brownout fault indicator.
  • Improvements to brownout behavior.


How does the built in Hall Effect encoder on the neo motor work? I can’t find any manuals on it anywhere. Will you be releasing one any time soon?


The built-in hall-effect encoder plugs directly into the SPARK MAX and outputs a 3-phase encoder signal which is different than a 2 channel quadrature encoder signal that most of us are used to. The SPARK MAX uses this signal to to know the rotor position of the motor. It can also use this signal to calculate motor velocity and overall position.

Take a look at our SPARK MAX Code Examples to see how to to read the velocity and position values through the CAN interface.


We have found that using position control of the neo brushless motors does not work if we had used the SetInverted function to invert the motor. It works when using percent motor output control but in position control the motor will go full speed in the wrong direction and coast down about 4 times past the desired setpoint. We manually inverted the motor in the code by just giving a negative value to the motor output and the setpoint, but is anyone else having a similar issue? We are using the built-in encoder for the NEO motor.


A few questions:

  • We updated the firmware on our SPARK MAXes to the latest firmware, yet receive a warning output message when the robot is running that the firmware version on those SPARK MAXes is out date.

  • Are there plans to release a non-CAN SparkMax class as part of the Java API, similar to that found in the C++ API?

  • What is the currently recommended way to run a NEO motor using a SPARK MAX via PWM using the Java API? We tried using the regular Spark class as mentioned once earlier in this thread, but the SPARK MAX status LED goes from blinking magenta to the CAN Fault orange/yellow blink pattern.


We’ve tracked this down to an issue in the Java roboRIO SDK, this error does not prevent operation. We’ve posted an optional hotfix update v1.0.28 here

Yes we will be adding this in a future release, for now you can use the PWM Spark class included in the WPILib

We’ve also tracked down a possible issue with the PWM interface receiving a CAN Fault. We’ve posted a firmware update which can be downloaded through the GUI.


Just saw this card on the troll. Does this mean that only quadrature encoders can’t be used in brushed mode? If I have the encoder configured for PWM would that work?