So I’m having a problem with my Sparks and the CAN system. This year our team is running a six neo/spark drive train (programming with Labview). Whenever I try to run one side of the drive train, only two of the sparks work. When I try to run the other side, none of them work and they all start blinking on and off magenta really quickly. I also get CAN Bus Off, Transmit and Receive errors from the driver station. I know that it’s not with the CAN system itself because I have tried disconnecting them all from the CAN and plugging them back in one at a time and they don’t give off any errors. After I plugged them back in they even worked properly for a while. Then they went back to the way they were before. I am making two sparks follow one master for each side. I have also tried making the Sparks unfollow each other with similar results. Can anyone help?



We had a similar issue. Not entirely sure what fixed it because we did many things and they all fixed it temporarily as you describe. However the combination of things as led us to be able to practice with our robot for a full day without any lingering issues.

Firstly we have SMax’s at the start of the CAN chain, then talons and then more SMax’s near the end of the chain.

  1. we redid all of our our can wires from SM before the talons and noticed that one SM was always breaking the chain randomly and the talons behind it reported CAN issues. So we swapped it.

  2. after that we got it to work for a while but then it would stop spinning the drive motors again (funny enough though it was trying to send a signal to the motor). We would spin the wheel with our hand and then the motors would start to spin, which was really bizare. So we tried to test this with a NEO off the robot and didnt have an issue. Realized that one of the encoder wires were not seated properly

  3. We went back to having can issues and the flickering lights, so I tested each individual CAN cable by disconnection it from every device one at a time. First I found that the CAN wire wasn’t seated into RIO nicely, then found that the second SM was always breaking my CAN to the talons after it. Simply swapped the CAN cable on that SM with the CAN cable of the SM we originally took off.

  4. it all worked after the above steps, and so we decided to do a firmware update just to be safe.

Since then, we didn’t have an issue. I know this crazy, not well thought out process we followed doesn’t exactly help, but I figure I would at least share my experience. We did mean to go back to try and reproduce the issue off board, but there was a robot to play with and break. I will see about maybe getting a student to help me try to reproduce it this week.

1 Like


Have any of the subsequent updates to the roboRIO API/SparkMax firmware addressed this issue? We are still having problems with it on our robot.
Is status/diagnostic information automatically sent from the SparkMaxes periodically, or do methods like getMotorTemperature() block the main thread until they send and receive a message? We have a lot of calls to get output current/motor temperature in our periodic methods, so we were thinking about pushing those calls to a separate thread.

1 Like


It depends on the function, but the statuses such as temperature/current are non-blocking. The API documentation mentions which ones are blocking. You can also view the source code starting with the v1.1.5 beta



Coast vs Brake mode? We are using NEOs and Spark Max controllers in our drive train: two NEOs per gearbox (left and right), and each side has one Lead and one Follower configured. All Spark Maxes are controlled via CAN.

Although the Spark Maxes have been configured for COAST mode, the motors actually appear to be braking. All Spark Maxes are blinking MAGENTA indicating BRUSHLESS COAST mode is configured. However, when the joystick throttle is returned to zero, the motors stop hard – like what I expect to see for BRAKE mode. Thoughts?



The LED means they are definitely in COAST mode. It could be the case that when you release the joystick it is sending it values close to 0 but enough to still send a command to the motors that is not an idle command. An even more drastic would be a value inverse of the direction you are commanding if the joystick is able to travel past 0.

An easy way to test if this is the case would be to graph the actual joystick command, and possibly the motor controller applied output using motor.getAppliedOutput().



Is there an expected date for when the firmware beta release will become the full release?



Will, That makes sense. We don’t currently have a dead-band limit applied to the joystick input, so very likely that the motor input isn’t going exactly to zero. We’ll add a dead-band limiter to the software and try again. Thanks!



Any update on being able to follow a SRX Master?



You can do this already.

TalonSRX masterTalon = new TalonSRX(0);
CANSparkMax slaveSpark = new CANSparkMax(1, CANSparkMaxLowLevel.MotorType.kBrushless);

// follow CTRE controller with ID 0
slaveSpark.follow(CANSparkMax.ExternalFollower.kFollowerPhoenix, 0);

// the Spark will now also run at full positive power.


I recall there being firmware version issues though which caused it to not work.



It allegedly works in the beta.



It currently does not work for LabVIEW. As for the other languages, I’ve heard success, but haven’t seen it myself



I seem to have found an interesting bug with firmware version v1.1.26-beta. When I try to use velocity PID in Java, it doesn’t actually do velocity PID. It seems like it is doing position PID instead. I think the ControlType constants in the SparkMAX Java library do not match what the firmware expects.



I have neos hooked up to the sparks maxs running on whatever is the latest non-beta and beta, and when I set the sparks maxs to break, they stutter like crazy. This is with the Rev tool exe and straight java. When they’re set to coast, the motors rotate normally. The best I can come up with is that the spark is attempting to break when it should not every rotation. I’ve resetted the Sparks and it still happens. The sparks are hooked up over can. I have the exact same problem as: NEO Motor & SPARK MAX problems except mine is always there and always immediate.

1 Like


Found an issue with the Phenoix follower. When using PercentOutput on the SRX, the Spark MAX follows fine. However, as soon as we change to a different control mode (we tested Motion Magic and Position control), the Spark MAX no longer follows properly, despite the SRX giving the correct output. We observed that although the SRX would stop the motor once the mechanism reached the Motion magic setpoint, the NEO would continue running at a constant speed.

As such, instead of using the REV follower commands, we did the following:

  • Set Spark MAX voltage compensation to 12
  • Pull output voltage from SRX and divide by 12 to make the output range go on a scale of -1 to 1
  • Use the .set method to set the Spark MAX to output the adjusted SRX voltage output
  • Put the above code in a notifier running at 10ms (main runs at 20ms)

The above method also works for getMotorOutputPercent instead of getMotorOutputVoltage if you want to go that path. The important thin gis to put the code in a notifier or there will be noticable lag when running the SRX in closed loop.

For the above code, run once it once in init to start the notifier thread.


SPARK MAX - Firmware Release v1.1.31

Hi, has there been a solution implemented for the 0.02 loop overrun issue?

We have seen the same issue for a few days on Spark max over can.

But do not see it at all when we change motor controllers.

1 Like


This happens to us too.



When using this hack, is there jitter on the Neos?



If you run it without notifier in the main loop there will be jitter. You need to have it run in notifier faster than the main loop.