Problem with New Spark Max Firmware and Follower Mode

Our team uses two Neos to run our elevator, so we invert one of the Spark Maxes in Begin.vi (the two Neos face each other on opposite sides of a custom gearbox, so they must always turn opposite directions in order to not fight each other), and command the inverted Spark Max to follow the other (from this point on I’ll call them the slave controller and the master controller.)

We haven’t had problems with this setup until recently, when we upgraded the Spark Max firmware and the Spark Max Labview API to the most recent version (1.4.0). After upgrading to the new version, the follower functionality appears to be dysfunctional.

As mentioned previously, when we open a reference to our Spark Maxes in Begin.vi, we invert the slave controller, and command it to follow the master controller. This makes it so that no matter what output we send to our master controller, the slave controller will mimic the opposite of that output.

Up until we upgraded firmware and API versions, whenever we commanded the master controller to rotate forwards or backwards, the master controller would blink green or red, and the slave controller would blink the opposite color as expected. Now however, both controllers always run the same direction (both blink either red or green together), regardless of whether we invert the controller in Begin.vi or not. I found this in the release notes, thinking it may be the source of our problem.

However, I find absolutely no way to alter the inversion of the motor via the Spark Max Client, and I find no instructions from Rev regarding this new way of handling the inversion of Spark Maxes. Additionally, if the inversion of the controller is no longer controlled via the API, why does the invert function still exist within the API?

The next thing we tried was rolling back our firmware and API versions to API version 1.1.0-8, and firmware version 1.1.33 (forgive me if I didn’t format those version numbers completely correctly, as I’m doing this from memory.) After rolling back the API and firmware versions however, the master controller still blinks the color corresponding to the direction we tell it to move, but the slave controller maintains a solid light blue color, which means that it isn’t receiving any movement commands.

  • We have confirmed that the fault doesn’t lie with the CAN Bus.
  • We tried replacing the slave controller to no avail, the behavior was exactly the same.
  • If we simply swap the CAN ids of the master controller and the slave controller, the behavior is also exactly the same, with the master controller (now the slave controller) maintaining a solid light blue color, and the slave controller (now the master controller) responding correctly with either a red or green blinking light.

Whether we use the new firmware version, or get the older version to work, it doesn’t really matter to us. We just need our elevator to work for an off-season competition this weekend. Any help is appreciated.

Thanks for reaching out and the detailed report. The method you describe is the expected method to invert the controller in follower mode, and this is still functional in v1.4.0

However there is one more relevant change that was done in the changelog I’ve highlighted below:

This means that the blink codes when driving forward or backwards will now always match the programmed command sent to the motor, not the inversion setting. The decision to make this change came down to ease of debugging for software teams. I’m sorry for the difficulty and that this was not clear from the changelog. We will make an update to the changelog to be a bit more verbose.

From a software release standpoint, we made sure to test these cases and make sure that while the blink codes may change polarity, any inversion settings remain as expected to prevent any issues.

My recommendation is to keep update v1.4.0 and test that the motors are spinning in the directions you expect. Let me know if it is not or if you have any further issues.

Regarding the earlier firmware version, it is not clear to me why the follower does not appear to be working. I will look into this further and get back to you.

Regards,
Will Toth

1 Like

Thanks, I’ll give this a try tonight. But can I just say, (not trying to sound rude) I dislike this feature, and not just because my misunderstanding of how it worked caused some issues with our elevator. In my opinion, the blink code indicating the direction the motor is rotating should be a constant. Otherwise you run into scenarios where you can only decipher which direction a motor is rotating from the blink code if you also know whether or not that controller is inverted. This can all be solved by diligently labeling motor controllers, but from my point of view, it adds a layer of unnecessary hassle. Again, I’m not trying to sound picky, just my personal thoughts. Thanks again for your help!

I certainly appreciate the feedback. We had discussed this change internally for some time, and also the possibility of making this configurable to choose between desired behaviors. This may still be an option looking forward.

Edit: I’ve also added this as a feature request on our public roadmap here.

3 Likes

We just tested the functionality of the new API, and we have encountered another issue. We have determined that no matter which way we invert our slave controller, it turns the same direction. So when a Spark Max is in follower mode, it doesn’t respect whether the controller is inverted or not. But when we invert the master controller, it responds as expected, going forward when not inverted, and going backward when inverted.

I’ve been able to confirm that there is actually an issue here specific to the LabVIEW API. The original discussion still holds true regarding the LED blink codes. I’ve put a detailed bug report card on Trello here. We will have a release available with this fix soon.