Happy kickoff, I know that many of you have been asking about software for MAX & NEO along with some other details. I wanted to start a new thread with some information and to act as a main place to post and collect feedback (rather than spread across a few different posts).
SPARK MAX API - We needed to take a couple extra days to update these due to some late feedback we received. We are in the process of packing things up and running our internal tests and will be rolling these out over the next several days. All of the information will be posted here https://www.revrobotics.com/sparkmax-software/#api-info
The Labview API is out now and available to install and run
The documentation for C++ is also posted (direct link), and the API will follow shortly
The Java will be the last one to post, but it still should be out this coming week.
FIRMWARE UPDATE - As part of the new API release, we are also going to push a firmware update, which fixes some of the things beta teams were reporting (forward/backward switching delays, etc).
We want to be careful with the number of Firmware releases we do in the season to make it easy for teams, but these bugs were cause for a quick update.
I’ll make a post here when it is out, but it follows a similar time frame as the JAVA API
SPARK MAX Client We posted an update to the client today that fixes a few bugs, especially with teams who are using Windows 7, as it now installs the needed drivers automatically. We will be periodically updating this client adding new features throughout the season.
NEO Data sheet/curves - This is now posted on the product page (direct link).
As I mentioned previously there were some challenges we had with getting this data (I’ll save that for a later post).
We have published both our internal tested data and the theoretical performance data, This was done due to the fact that the NEO and MAX are a coupled system in FRC and we wanted to show the expected performance in FRC, but also what we expect the motor to be independent of the controller.
Admittedly (and probably obviously) we were working towards a smoother launch of MAX & NEO than we have done, but again we do appreciate the patience the community has shown and we will keep working around the clock to make sure you can get the experience that we had in mind when we designed the controller and motor.
In addition to myself, @dyanoshak and @Will_Toth will also be chiming in on this thread answering questions as needed.
The difference between the two caused by several different factors, but the two most contributing factors were the testing setup used to get these numbers, and the combined performance of the MAX/NEO vs the independent performance of the NEO. I am going to be doing a longer write up about this in the future.
Yes, we will create a google sheets page and post it soon
The motor has a 42 counts per rev, so the angular resolution is (360/42) = 8.57 deg
Through our testing we have found that an 80AMP current limit is a good one which both doesn’t impact performance much, but also does a good job protecting the motor for FRC use. The default user settable current limit for the MAX is set to 80amps for this reason. If you are using the NEO for non-drivetrain applications, it is always a good idea to put your current limit relative to your mechanism design.
We don’t have this data to share, as the NEO is designed to have a current limit when used with the MAX. The Smart Current limiting in the MAX allows you to run continuously at whatever your limit is allowing for teams to effectively tune the continuous power output they need. As I said above, the 80amp limit is a good starting point for this for drivetrains, with the ability where you can be either more conservative or aggressive based on your team choices.
This will be added to the next version as a text display. You can check if your client is current by going to the about page and click “check for updates”
I’d be very interested to see this information as well. I’ve stalled a decent number of CIM motors over the years and never had to replace one, so knowing how long these can run stalled is very important for me.
I also seem to recall hearing something about the motors having the ability to thermal-throttle using the internal sensors. Is this a function that’s built-in to the SparkMAX controller and automatic (since there’s no user config in the interface for it), or is it something the user has to implement in code?
It is all about how you setup current limits. If your limits are setup at 50amps, you can go for a very long time. If you remove current limiting you can kill them as fast as a 775pro. The default current limit is 80, which we think is a pretty good number for drive train.
I will add this to the list of tests we need to run/publish data on. I don’t have a time frame on this though. One of the challenges in testing these motors is voltage drop when testing batteries and killing power supplies at higher currents. We are working to improve our test setup including buying some new equipment so these tests are easier for us to run in-house.
Every NEO has a temperature sensor in it. That data feeds back to the MAX. At this time, we haven’t implemented a way for teams to use that reading directly, but that is on our development path (and you will already have the hardware)
Am I right in saying the MAX controls the output current (into the motor) rather that the input current (into the controller, like the talon srx does)?
If so, I doubt it will make much difference (it’s easy to convert at a given battery voltage), but it should be pointed out. The current numbers you’re quoting above aren’t 1:1 comparable with talon srx current limits.