Spark max current limit

We had trouble with our spark max / neo motors this weekend. We are a direct drive mecanum bot with 9:1 gearboxes. We have our Max controllers set to 40A current limit. Several matches we got into a pushing match and shortly after, one side of our robot didn’t want to run. We logged our PDM currents for the motors and saw 50-60A current surges just before that side dropped out. Current then stayed at 0A with occasional blips of 4-5 A.

We tried replicating in the pits by stalling the motors, but they never tripped I assume it was probably the other robot pushing us backwards. Should the current limit have protected us? What can we do to prevent this in the future.

How are you setting the current limit, in code or through the Client? Can you verify it was absolutely changed and saved to flash?

Please send your logs to

We had the exact same issue – I will send logs as soon as we get a chance to get them from the driver station machine.

We are setting the current limit through code (setSmartCurrentLimit) and also setting a higher secondary current limit.

Are you calling BurnFlash() after setting all your parameters? If you were to have a brownout without saving the current limit, it would go back to default.

We are using the client app to set the current limit. Specifically the simple setup screen (not advanced). We know it sticks as we can come back later and see it set.

Where can I read about the different current limit options (java).

We are using Spark Max and Neo Motors too and we ramped our speed in order to combat brownouts. We also used the client as a current limit and it seems to be serving us well during matches and pushing matches.

Unfortunately, I don’t have actual “Logs”. We display the PDM current levels on the Shuffleboard display, and we have been recording these during matches. When we replay the match, we see normal currents when we are not being pushed backwards, but when we get pushed, the motors on one side of the bot spike up to 50-60A over a couple of seconds, then the currents go to zero.

We don’t know if it’s the breakers tripping, or the controllers shutting down.

We do a lot to limit the normal current load on the motors during game play. Under “undefended” play condition, we can completely stall the motors at full throttle (which for us is only 80% of max voltage) and hold this condition without trouble. Measured currents stay well less than 40A… typically 25-35A

It’s just when we have someone actually pushing us backwards that we get the problem.

Do brushless motors generate back EMF like brushed motors? Is this combining with the applied voltage to spike the current.

What’s the firmware version on the PDP you’re using for testing? If I recall correctly, there was a fix in version firmware version 1.40 that corrected some of the current measurements. This might be the source of your current discrepancies.

PDP was updated several weeks ago, but the current readings are not in question…

They are great in fact, as they helped us to explain why the robot performed poorly after a pushing match.

Normal currents followed by high currents followed by no currents.

Hi have been reviewing the SPARK MAX API (since until now we have used the client to setup and just the basic commands to set power and read encoders).

The various current limiting modes seem to be enabled by default, but they are quite confusing to me (a 35 year roboticist) and the explanation seems written for someone who already knows how they work.

There also is no indication on how the API defaults are actually set…

eg: there is apparently smart current limits and secondary current limits, but what are the actual current limit values for each of these if I don’t set them explicitly.

Also, how are the “smart” current limits applied if the direction of movement of the motor is opposite to the commanded direction? The docs would imply that it’s linear from full speed to stall, but what about “worse than stall (being pushed backwards)”

Is there a white paper or general discussion on how the defaults are setup if I select one of the client limit options (40A)?

What firmware version are you using in your spark max?

I would very much like to see this whole thing simplified down. From the programming side I’d like to be able set current limits going into the motor controller. That’s how I can schedule my loads and insure I don’t brown out. It is unnecessarily confusing doing it other ways.

Spark max current limits set the motor current limits. They are different from the current drawn from the battery.

If you want to read how much current the spark max is drawing from the battery, use the PDP’s current sensing.

At the point where you have already drawn the current, it is too late. Especially when you are using multiple motors.

That is why a current limit function is so important. Much like voltage limiting, the idea is to proactively manage load, not catch it after the fact.

If the PDP isn’t suitable, then this is any easy solution if you want to put a “hard cap” on the battery drawn current per motor controller:

The motor current * motor duty cycle = battery current.

When battery current > max current, set motor power to (battery current / motor current)

And in addition to that just add some running averages for measurements.

I guarantee you that is sufficient enough for FRC use, and if CTR adds battery current limiting onto the spark max this is essentially how it would be done.

I am fairly certain CTR will not add current limiting to the spark max. But your solution has the same problem your previous one did. Limiting current after the fact is too late.

For teams running high power drive trains after the fact can cause brownouts. Many teams protect against this by proactively limiting the input current on motor controllers.

Look, my point is this, there is no difference between adding current limiting through the spark max, through the PDP, or through the sparks own current measurements.

There’s no way to magically stop current preemptively, it’s all in software.

Talons limit current the same way. They read current and limit duty cycle.

It’s never perfect, but it can be made better by estimating the projected current ahead of time, which again can all be done in software.

When you boil it down to the essentials, limiting current is just using a PID algorithm. You set motor power to whatever you want, and when your current approaches your limit, you begin to PID your motor power to the max current, and switch back to normal power control whenever your pidded motor power is greater than what you want it to be.

And if teams can make magical robot arms that swing around without overshooting at all, then they can certainly PID to a current.

I’ve seen teams already run a “current control” mode for their DT’s where the joysticks map to a current (closer to torque control, instead if arbitrarily voltage). And even more advanced is a watt control, where it uses the current AND voltage to pid to a wattage output.

Limiting current is definitely possible, and has essentially been done before.

Tom and Shiftingbot, you have hijacked my thread asking for assistance…

The Spark Max is sold by REV, not CTR.
I am setting the max current limit at the Motor controller, and monitoring it via the PDM…

In my case PDM Current = Motor current… other than heat, there is nowhere else for it to go.

My problem relates to the effectiveness of the MAX current limit when dealing with Reverse Rotation by external forces… can it do it, and if not, what’s a good approach with the current hardware.

I’ve not seen this problem (Excess current above stall current) on other controllers or motors in the past, but I know the firmware is still in flux… I am using 1.0.385 firmware

Why not use 1.1.33 firmware?