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.