Occasionally, when running our Neo through a Spark MAX, we get this message to appear about 8 times in the driver station window:
[CAN SPARK MAX] timed out while waiting for Periodic Status 1
We’re using the Neo to operate a single flywheel on our shooter mechanism. Usually the error doesn’t occur until about 2 and a half minutes into operation when it appears completely unprompted except for the fact that it appears during the operation of our shooter, and when it does show up, it shows up in groups of between 8 and 10 errors, and the “Periodic Status 1” appears between 1 and 4 times at the end of the error message. It doesn’t prevent our robot from running, but when it appears, it prevents us from operating our Spark MAX through PID control.
Our program runs our shooter through percentage control for roughly a second and a half before flipping to PID control as a way to give it a “running start” so the feedback loop doesn’t have to work as hard. After the errors occur, we’re still able to run the motor through percentage control, but as soon as the PID takes over, the motor just stops running entirely.
I have no idea where to start to fix this issue. The lights on the motor controller seem to be complying with what I would consider to be normal behavior. What’s going wrong?
The first thing that goes through my head is a loose connection somewhere on the CAN bus. However you say that you still have % control which is interesting.
Have you tried swapping out the spark max?
Forgot to mention that the inability to operate through PID persists through disable/enable cycles, but as soon as I rebuild code or reboot the robot I am able to operate it again. I don’t believe wiring is the issue but I’ll try swapping the Spark MAX tomorrow.
Yeah, that sounds less like a wiring issue, especially since it takes a redeploy/reboot to fix. If you reboot the code through the driver station, does that make it operable again too? If so it sounds like an issue with the software or with the Spark MAX.
Rebooting code was able to temporarily fix the issue like redeploying it was able to. I also swapped the Spark MAX out with a new one and it seemed to fix the issue, but at this point it’s not easy to tell for certain. I also noticed that it wasn’t in brake mode while the other Spark MAX was. Dunno if that’s significant but I’ll update this thread if I start getting the error again.
Just had the error occur again with a brand new controller. I’m at a total loss on what could possibly be happening here. The motor hadn’t been ran for a little while since building was taking place, but I don’t really know what it is now.
What’s the CAN utilisation %? If it’s too high then that might be a source of trouble.
Also, is your CAN bus correctly terminated?
CAN utilization % is hovering around a near constant 45%. CAN bus is correctly terminated through the resistor on the PDP. All our other CAN devices work fine when the error occurs.
Updating this thread because I think I found the solution.
After some changes to the prototype’s design, it started to become clear that each error that was thrown could be connected to some sort of failure in the function of the design such as, for example, two balls being accidentally shot by the flywheel at the same time. This wasn’t obvious to me in the prior design and the errors seemed to happen randomly.
I used the getBusVoltage() method on the Spark MAX and graphed it on the Shuffleboard and, sure enough, the voltage read a huge spike each time the error happened. I can probably fix this with some programming changes, and, with a better design, issues like this should happen less often anyway. Thanks for your help and suggestions everyone!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.