Yes, the current limits on the MAX are output currents, as we are directly measuring phase currents instead of the total input current. So there is a difference between the two numbers, we will add this to the list of things we need make a conversion table for.
When using the Neo Brushless Motor with the SPARK MAX Motor Controller, reading the output in LabVIEW using the new API, what temperature scale does the Sensor on the NEO output? Celsius or Fahrenheit? I couldn’t find it in the documentation.
Reading the C++ documentation, I can’t find a PWM controller for the spark max. There is only a CAN one. Have I missed it ?
For pwm, you can just use the existing spark class in wpilib.
Just wanted to post and let you all know that the C++ libraries have now been posted to http://www.revrobotics.com/sparkmax-software/#cpp-api
Also we released a new firmware version : V 1.0.381
- Improvement to the Smart Current Limit when changing direction (fixes forward/reverse delay)
- CAN framing improvements for get/set parameter calls (required for C++/Java API)
- Other small improvements
Java libraries are coming within the next day or so.
Played with the c++ API implementation tonight and had a few issues.
First is closed loop control available yet? I can neither set closed loop control active on the run page in the client nor programmatically, second is the only way to set the control mode programmatically through the set reference command in the pid controller class? There’s some strange verbiage in the API that makes it sound like the set reference command is overriding something rather than a normal means of operation.
An additional question, is the arbitrary feed forward presently working as intended? When setting it in duty cycle mode (since I can’t get my spark max to move it’s neo in any other mode) it doesn’t appear to be applied.
Not REV, but…
Does the rev::CANPIDController class not work as expected? That sounds concerning.
So we allocate a sparkmax, use that to allocate a pid controller, then for example set P to a value, and use set reference to indicate velocity mode with a Target of say 200 rpm, and our motor controller presently doesn’t move.
If we use the setreference call with a duty cycle control type instead - it does move, so the basic setup seems to be correct.
I’m also not sure of the scaling of the gain values presently.
In regards to the API verbiage - specifically “Set the controller reference value based on the selected control mode. This will override the pre-programmed control mode but not change what is programmed to the controller.” Is that just indicating that it will temporarily override the control type that had been set by the client?
Thanks for the detailed description. Can you verify a few things:
- You have updated to the latest firmware (v1.0.381)
- The value for P Gain is being set, as well as Min/Max output for the selected slot? All of these values default to 0
In a previous version of the API there was a command that would use the saved control mode in the case that you called SetReference() without specifying the ControlType field. We pulled this as we felt it was non-intuitive, and just specifying the control type explicitly is cleaner. That part of the description has been removed from the API Doc, and will be removed from the header comment in the next update.
Our documentation will also be updated to show the default values of all parameters.
It is the latest firmware, we have set a P gain and verified via the client that it ‘took’.
You mean via the setoutputrange method? The API made it sound like that only applied to the derivative gain.
Should we be able to set the control type via the client? There are radio buttons for it but they’re all always greyed out.
Yes, this method is intended to set the max output from the PID controller.
Right now the GUI only supports duty cycle output. This is a planned feature that we plan to release in a GUI update with graph feedback of control signals.
The SparkMax class does PWM.
Last night I pushed experimental Python bindings for the REV SPARK MAX. For anyone interested, see this thread: RobotPy SPARK MAX bindings
Using the set output range command we were in fact able to start running in closed loop modes and tune the motor.
It still seems like the arbitrary feed forward doesn’t function properly though, running free with velocity control and an F gain of .000175 we see the motor moving fine, but then we tried using an arbitrary feed forward of both 4 and 32, both seeming to have no effect.
I was able to confirm this behavior and the root cause in the C++ implementation. We will roll in a fix with the next update.
How would you connect CAN wires to this do we need to buy a special connector?
Each SPARK MAX includes a CAN and PWM connector shown in this picture from the User Manual
Hey, I’d just like to point out that the pinout for the PWM/CAN port in the user manual seems to list the encoder pins instead. Something that slipped in the launch scramble, perhaps?