DRV8301 motor performance tuning (low tech)

for low speed continuous operation you are already on the right track.

You have RsOnline enabled.
You have ForceAngle DISABLED, correct? (you want to use FAST as the feedback source as low as it will go).
You have tuned your speed controller as best you can.

• You will have to increase the Kp and Ki quite significantly on a PI controller for best continuous low speed operation
• Since you are using the 69M controlCARD I will reccommend that you look at using 5c-5f to take advantage of the SpinTAC controller in InstaSPIN-MOTION. It makes a significant difference in low speed control, usually allowing me to go 2-3x lower than I can with a PI controller

You then need to look at what is realistic and what can be improvded for your specific motor.

• In this case you have a decent motor for low speed operation as it has a flux of 0.1 V/Hz. That means at 1 Hz (30 RPM with 4 poles) it produces 0.1 V.   That's not a lot...but it is "enough", and much better that many of these high speed motors customers are trying (flux values 50x lower).
• You want to maximize the resolution of this signal
  • Right now you are trying to sense this signal on a voltage reading of 66.x volts. That's bad.
  • You want to re-scale this to a voltage that fits your motor, the larger of
    • Vbus + some headroom or
    • Flux_VpHz * Maximum_Hz during highest speed (Field Weakening)

In your case this is probably 20V + 15% = 23V.  This will nearly triple the resolution of each ADC voltage step, allowing you to go a bit lower in speed (make 1 Hz very good, maybe 1/2 Hz....you'll have to see).  You can simply change out the resistors on the voltage phase and bus sensing to rescale these (use chap 5 of SPRUHJI for the calculations).

We actually have a 3-ph inverter that would fit this very well, the BOOSTXL-DRV8301 (24V/10A), unfortunately right now it only has control support from the InstaSPIN-FOC F28027F LAUNCHXL-F28027F.  We are working on a 69M version of this LaunchPad for summer release.

Saturn Z said:

I guess, probing the right signals on the board (using a scope) during the tuning process can give a good indication of how well the motor is tuned. Alternatively, the graphing capability on Code Composer is incredible and can potentially be used to get a good insight about the drive performance.

In your investigation, probably the only truly helpful thing would be to add an encoder to your motor and compare the angle from the encoder to FAST. This is the only way to truly know if the limitation is at the estimator (mostly decided by voltage scaling, Flux of motor, and accuracy of motor parameters) or with your control loop tuning. 

But the first thing to do is to use SpinTAC and you will essentially take the speed loop out of the equation. You can also do somethign similar by running proj_lab5a in torque mode and only commanding enough torque to keep 30 RPM operation at a give load (you will need a load).  This will give you a good lower limit with your existing HW scaling, motor, and parameters.

Hi Chris,

Thanks for your detailed response, as always.

I agree with most of what you have said/suggested above.

My question however is that, after I have tuned the PI gains by way of visual feedback and looking at improvement in motor vibration and noise, there comes a point when I cannot see a visible difference in motor performance even when I increase the PI gains further, whereas I am sure there is subtle change happening in motor performance. In such a scenario can I look at some hardware signals and get a better insight into how the gain values are making an impact on the performance. If packaged into a software (for e.g. using graphs) this could serve as an invaluable tool for end customer as well.

Having said that, I am definitely going to try out the Spintac labs to see if motor tuning is more convenient and associated performance is better than a PI controller.

PS: Is there a way to see the value of phase current as seen by FOC algorithm (in CCS). Something similar to gMotorVars.VdcBus_kV for Bus voltage, what is the equivalent for phase current ?

when you get up to lab10 you will notice

expAdd ("gMotorVars.Vd", getQValue(24));
expAdd ("gMotorVars.Vq", getQValue(24));
expAdd ("gMotorVars.Vs", getQValue(24));
expAdd ("gMotorVars.VdcBus_kV", getQValue(24));

expAdd ("gMotorVars.Id_A", getQValue(24));
expAdd ("gMotorVars.Iq_A", getQValue(24));
expAdd ("gMotorVars.Is_A", getQValue(24));

in these labs we are only "getting" these values in the background task, which is good enough for viewing in CCS watch window.  If you want them every cycle you have to add the _get function into the ISR....but then you have to do something with them...you can see proj_lab5f for an example of how the DLOG functions are used for this sort of thing to buffer up data.

Yes, agree that doing things by hand can only go so far. To test torque or speed controllers you should give step inputs and plot response to tune for best over/under shoot and settling time. This can be done using the graph functions.

Internally we have some projects set-up to do this testing, but it hasn't been added to MotorWare quite yet....