We’ve recently been testing using brushless Neos for our drivetrain this year. However, when we drive around, pretty consistently the front right spark max doesn’t move. The status light is a blinking cyan, even though there is a command being sent to it, so it should be either green or red. Even connecting through a usb to the controller and manually setting power there doesn’t work either.
The spark max controller is connected to the brushless neo motor with the 3 wires and the encoder. On the robot, it receives power from PDP, and is daisy-chained for CAN communication. The CAN daisy chain starts at the RoboRIO and terminates at the PDP.
We’ve swapped out the Spark, and it started working for a bit, and then it stopped working. We then swapped the old Spark back in, and it started working again, for only 10 minutes. We swapped the motor it’s connected to as well, and that worked for a little bit before failing again.
I tried upgrading the firmware to the latest version, but then the dashboard started reporting an error where the firmware version of the spark I just reimaged was too low. However, I triple checked that the firmware I flashed was the latest version available from the website.
A little more info of the failure. It seems there is some sort of state in the Spark Max controller that once it’s ON (or OFF), it prevents the controller from spinning the motor. We made the observation that once we got it to work, it kept on working until we power cycle the robot in which case we suspect some state got cleared and it will stop working with the same code. My first thought after this observation is to suspect the limit switch states. If somehow it was enabled and configured to normal closed then the motor controller will think both limit switches are engaged and will not spin the motor. But we went over our code and didn’t see any initialization statements on limit switches. Just for safety, we added limit switch initialization to disable limit switches. We also connected our laptop to the controller via USB and looked at all the states in the “Advanced” tab and didn’t see anything unusual. So we are still puzzled. To make it even more confusing, this trouble motor controller is one of the four controllers controlling the drive base wheels. The other three are functioning normally with the same code, just the right front wheel is causing trouble.
@dyanoshak, any comment on this issue? We are still stuck. In all our previous seasons, we always connect our CAN devices in a “home run” configuration. With the REV Spark Max, because of the tiny connector, we can’t get a good crimp to make a longer cable to connect to the central hub. So this is the first year we did daisy chaining. At first, we thought it may have something to do with the CAN daisy chain. So we swapped the chaining position of the trouble controller with another good controller. But it doesn’t make any difference. Besides, with the latest observation, it seems the problem is with software initialization.
Nevermind, we were able to fix the problem. We were accidentally sending a follow command to the Spark Max in question, and so it wouldn’t respond to driver input.
The issue was fixed by just removing that follow command.
@dyanoshak, just for our future reference. Is there a way to check the volatile state of the controller via USB (or other means), not just the non-volatile configuration? If we had a way to see the controller was in “follower” mode, we would have found the problem earlier.
The PC Client will display the volatile state, however there is not a great way currently to view the follower mode as part of that. This is something we can put on our list for a future improvement, and I appreciate the feedback.
In the SDK there is a call ‘isFollower()’ which returns the follower state of the controller which may help.
