This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Rotor blockade behaviour

Other Parts Discussed in Thread: DRV8312, MOTORWARE

Hello,

I've got a low inductance motor (Rs = 0.71Ohm, Ls_d = 81µH, Ls_q = 51µH) which I want to operate through zero speed. (HW: DRV8312 w/ 69M.)

When running lab05g at 1000rpm and blocking the rotor, the system starts producing torque (about 1sec after blocking) in CW and CCW direction at a frequency of about 1-200Hz (depends on speed and Ki_spd). It seems that it tries to do its startup angle detection although ForceAngle is disabled. However if I release the rotor it moves into the right direction again. (Manually forcing the rotor directly into CCW direction and moving it CW and CCW works rather smooth if I set Ki_spd = 0.)

Is this the expected behaviour (i.e., FAST algorithm cannot be used for a blocked rotor) or what can I do about it?

Thanks!

  • 1. please make sure you have compiler 6.2.3+ set as active

    2.  What is your Vbus?

    3. What is your ID'd Flux?  Were you able to ID an average inductance or did you just update ythe Ls_d and Ls_q by hand?  (you will need to use proj_lab2c to ID this motor as it has an RoverL > 2000)

    3. What is your USER_IQ_FULL_SCALE_FREQ_Hz    USER_ZEROSPEEDLIMIT    USER_FORCE_ANGLE_FREQ_Hz

    4. Is gMotorVars.Flag_enableForceAngle = True or False?

    MKo said:

    When running lab05g at 1000rpm and blocking the rotor, the system starts producing torque (about 1sec after blocking) in CW and CCW direction at a frequency of about 1-200Hz (depends on speed and Ki_spd). It seems that it tries to do its startup angle detection although ForceAngle is disabled. However if I release the rotor it moves into the right direction again. (Manually forcing the rotor directly into CCW direction and moving it CW and CCW works rather smooth if I set Ki_spd = 0.)

    Let me see if I have this correct....

    1. Running at 1 KRPM, you stall the motor by providing a load > torque the motor can produce.

    2. After 1-2 seconds of 0 torque, the motor begins producing torque in both CW and CCW direction, fighting to breat the load - which is being held constant at a stall condition, correct?

    3. If you remove the load it immediately moves in the correct (commanded) direction and regains the target speed)  <yes, this is certainly correct behavior upon stall recovery>

    Is this the correct summary?

     

    I think in #2 this can be typical behavior, but will depend on the speed control gains and if the load is truly holding the shaft still or if there is any movement. 

    Is your expectation that a stall condition will result in the motor producing no torque? Or limited torque?  If so, you could add your own state logic that upon stall detection you immediately limit the output of the speed controller to a smaller value than USER_MOTOR_MAX_CURRENT....but if you want to be able to recover to a near full load this wouldn't help you much as you need the MAX output of the speed controller.

    Can you describe your desired reaction upon stall better?

     

  • ChrisClearman said:

    1. please make sure you have compiler 6.2.3+ set as active

    I'm using 6.2.5.

    ChrisClearman said:

    2.  What is your Vbus?

    24V.

    ChrisClearman said:

    3. What is your ID'd Flux?  Were you able to ID an average inductance or did you just update ythe Ls_d and Ls_q by hand?  (you will need to use proj_lab2c to ID this motor as it has an RoverL > 2000)

    The identified flux is 0.0166 V/Hz, but I wasn't able to identify Ls_d and Ls_q with lab2c. So I had to update these values by hand.

    ChrisClearman said:

    3. What is your USER_IQ_FULL_SCALE_FREQ_Hz    USER_ZEROSPEEDLIMIT    USER_FORCE_ANGLE_FREQ_Hz

    800Hz, 0.002, 1.0Hz

    ChrisClearman said:

    4. Is gMotorVars.Flag_enableForceAngle = True or False?

    I set it to false after the motor starts spinning.

    ChrisClearman said:

    When running lab05g at 1000rpm and blocking the rotor, the system starts producing torque (about 1sec after blocking) in CW and CCW direction at a frequency of about 1-200Hz (depends on speed and Ki_spd). It seems that it tries to do its startup angle detection although ForceAngle is disabled. However if I release the rotor it moves into the right direction again. (Manually forcing the rotor directly into CCW direction and moving it CW and CCW works rather smooth if I set Ki_spd = 0.)

    Let me see if I have this correct....

    1. Running at 1 KRPM, you stall the motor by providing a load > torque the motor can produce.

    2. After 1-2 seconds of 0 torque, the motor begins producing torque in both CW and CCW direction, fighting to breat the load - which is being held constant at a stall condition, correct?

    3. If you remove the load it immediately moves in the correct (commanded) direction and regains the target speed)  <yes, this is certainly correct behavior upon stall recovery>

    Is this the correct summary?

    [/quote]

    Absolutely.

    ChrisClearman said:

    I think in #2 this can be typical behavior, but will depend on the speed control gains and if the load is truly holding the shaft still or if there is any movement. 

    Is your expectation that a stall condition will result in the motor producing no torque? Or limited torque?  If so, you could add your own state logic that upon stall detection you immediately limit the output of the speed controller to a smaller value than USER_MOTOR_MAX_CURRENT....but if you want to be able to recover to a near full load this wouldn't help you much as you need the MAX output of the speed controller.

    Can you describe your desired reaction upon stall better?

    I would expect that in a stall condition the motor produces some constant current limited torque even if slowly rotated against the commanded direction by hand.

    I already somehow limit the speed controller output in a stall condition by setting Ki_spd = 0 and this works more or less (see above). However, as you noted this doesn't work as long as I need full torque when the rotor is blocked (i.e. torque should only be limited by USER_MOTOR_MAX_CURRENT).

    Any ideas how this can be achieved?

    Or do I have to use your HF-Injection based solutions for very low speed operation as mentioned here: http://e2e.ti.com/support/microcontrollers/c2000/f/902/p/299070/1042520.aspx

  • MKo said:

    I would expect that in a stall condition the motor produces some constant current limited torque even if slowly rotated against the commanded direction by hand.

    No, that can't happen because constant torque can't be produced when FAST no longer knows where the rotot is located.  What is happening is that at stall condition the FAST estimator starts to drift (and produce erroneous results as feedback) as there is no longer any Bemf being produced to track.  This is "normal" or expected conditions.

    You may get something closer to your desired functionality by using the ForceAngle feature.  This can continue to produce a torque response by forcing a constant rotating angle as the estimated feedback.  But it's rotating, so it will not be a constant torque.  You wil see this also a torque pulse as the stator flux continues to rotate while the rotor is stalled and remains stationary.  You may be able to "freeze" your stator flux during a stall condition by continuing to write the same angle into the estimator with ForceAngle enabled.....I don't think we've tried this, but it could work.  You could also just break the inverter (all low sides or all high sides on) during a stall....you would then need to detect the stall was removed though.

    One thing that you should do when using ForceAngle

    1. figure out where - for your motor and hardware - FAST starts to break down.  Then set USER_ZEROSPEEDLIMIT  to a value where USER_ZEROSPEEDLIMIT * USER_IQ_FULL_SCALE_FREQ_Hz = this breakdown value in Hz.  This is the transition point that will be used between FAST and ForceAngle when ForceAngle is enabled.

    2. For the best transition, you want USER_FORCE_ANGLE_FREQ_Hz > 2 * this transition point.  It needs to be larger than the transition frequency so it can move the rotor into a better area of operation when appropriate.

    MKo said:
    Or do I have to use your HF-Injection based solutions for very low speed operation as mentioned here:

    For continuous low speed operation something like an HFI technique would work well, but note that HFI requires a special type of motor with high saliency.  We are working to release a version of this in MotorWare / InstaSPIN this year. 

     

  • Chris, thanks a lot for your thorough answers.