Motors use excessive current when idling after a position cmd

[SouthernAtHeart]

Setup:
2X15 Roboclaw
2 motors w/encoders, 24 volt power supply, use about 5 amps when running at full speed
When I give the motors a buffer command, like go home or go to a certain position. They reach there fine. But after getting there they still consume 2-3 amps of current. At first I thought it was that I didn't have a dead zone set, but I set one to 5, 10, even 20, and it makes no difference. Plus, I can see the encoder reading in the Roboclaw utility, and the encoder values are not changing. I've got the motors tuned to run pretty smooth, and they find there target quickly without overshooting. But after they're there, and all settled in, the motor amps still show 2, 3 or more. The motor itself is not even trying to move.
With both motors doing this it was causing my temp to rise up to like 70. I finally found a simple work around: After sending the motors to their position, I have my Atmega chip watch the buffer, and once it's clear I just send a dutyM1M2, 0,0 command and that instantly drop the current.
I can run both motors wide open for a long time and the temp never went above 40. It must be something about the MOSFETs oscillating somehow, when I send a position command alone. Unless there's some setting I'm missing. I worked with both the Velosity and the Position PID values for a couple hours, but no matter how I set them it would still use current even after the motor arrived at it's destination.

[Basicmicro Support]

If while holding position the motors are using excesive current it usually indicates the PID settings are set too agressively and they never let the PWM to the motor stop. The motor is constantly fighting itself. Even thought he encoder reading you are seeing may not be moving, the motor controller is updating the PID 300 times a second internally so it can still be fighting itself with too aggressive a PID setup(I is the usualy culprit).

Also note that position commands are still active even after the command finishes(eg they will fight against any external changes in the load).

If you have an oscope you can look at the motor channels(you will see a PWM signal) if the motor is still active.

When the motor is just barely active there will be a PWM duty near 50% on both sides of the motor(setting the duty manually to 0 stops the PWM, btw). This near 50% duty causes ripple current in the motor. Some motors(with low/very low inductance) will heat up quite a bit from this ripple current(the lower the inductance the worse the ripple current).

[SouthernAtHeart]

The motors weren't heating up at all. Nor was there any load on them. I could manually move the motor shaft sprocket, shaking it back and forth, and it would drop the amp reading in the roboclaw utility back down. I'll have to check my PID settings some more. My settings are:
//Velocity PID coefficients
#define Kp 500
#define Ki 10
#define Kd 0
#define qpps 10000

//Position PID coefficients
#define kp 2000
#define ki 0
#define kd 5000
#define kiMax 0
#define deadzone 5
#define positionMin -90000000
#define positionMaxM1 2390000
#define positionMaxM2 200000
#define accel 1000
#define deccel 1000
#define maxSpeed 10000

[SouthernAtHeart]

Great news. As soon as I updated to the latest firmware, the motors stopped drawing 3 amps even when at rest. Now, once the position command is reached, instantly the amperage kicks out, down to about .8 or so. And the temp after 10 minutes of running to different positions is still below 40!

A side note. The issue with the controller not recognizing the M1/M2 home switches on startup -- I thought maybe this firmware update would fix it, but it hasn't. I'll be looking to hear from you about that. I have another new controller coming from you in a day or two. I'll see if it does it with that one too.

[Basicmicro Support]

We will be working on the home sensor code this weekend. After a brief examination of the code the problem was obvious. We use an on-change interrupt to detect the switch being triggered. If the switch is triggered before powering up then of course the interrupt will never get fired. We will be adding code to read and set the flags for the home sensors to correct for this problem.

Note: the 4.1.19 firmware has been out for a while(from before you had noticed this problem) which is why it didnt have this fix yet.