• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 84 subscribers
  • Views 398 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C2000WARE-MOTORCONTROL-SDK: Motor spinning great with estimated parameters but not with the same parameters hard-coded

Mitcham Tuell
Prodigy 150 points

Part Number: C2000WARE-MOTORCONTROL-SDK
Other Parts Discussed in Thread: BOOSTXL-DRV8323RH, LAUNCHXL-F280025C

Hello,

After a few weeks of being pulled to other projects I'm back working on implementing sensorless FOC with a small custom BLDC motor using a LAUNCHXL-F280025C and BOOSTXL-DRV8323RH with the universal motor control lab. I now have the system spinning the motor really nicely after running the parameter estimation sequence in build 4 of the lab. The drive current waveform is nicely sinusoidal and the motor always recovers nicely when I stop it with my finger. Current draw is low and I am satisfied with the performance so far. Part of the key ended up being to replace the 7mOhm current sense resistors with 50mOhm ones. I set the current gain to 20 for a full scale span of 3.3A and that seemed to make a big difference. Here are the values that the auto-tuning sequence spits out:

motorSetVars_M1.RoverL_rps = 20529

motorSetVars_M1.RsOnLine_Ohm = 3.09

motorSetVars_M1.Rs_Ohm = 3.09

motorSetVars_M1.Ls_d_H = 0.000189

motorSetVars_M1.Ls_q_H = 0.000189

motorSetVars_M1.flux_VpHz = 0.004 (constantly updates near this number)

Now I would like to be able to hard-code those parameters and spin the motor equally well without running the auto-estimation sequence at all. However, every time I try this it doesn't work. I write those values into the corresponding variables in user_mtr1.h:

#define USER_MOTOR1_Rr_Ohm (3.09) 
#define USER_MOTOR1_Rs_Ohm (3.09)
#define USER_MOTOR1_Ls_d_H (0.000189) 
#define USER_MOTOR1_Ls_q_H (0.000189)

#define USER_MOTOR1_RATED_FLUX_VpHz (0.004) 

And I set userParams_M1.flag_bypassMotorId to false in sys_main.c. When I run the code after that I get a short jitter of the motor and an immediate overcurrent error every time. Before I reduced the full-scale current to 3.3A it would jump the motor around and draw a bunch of current - I guess reducing the limit triggers the overcurrent. I tried setting motorSetVars_M1.overCurrent_A to 100A to see if I could bypass the fault but it still throws it. When I have run the auto-tuning the motor spins perfectly and never throws an overcurrent fault even when I load it heavily or fully stop the rotor by hand. It just draws 600mA or so and then spins right back up to speed and low current when I let go.

What could be the difference between the auto-tuned behavior and the hard-coded behavior? I have searched through the code to find parts that rely on that userParams_M1.flag_bypassMotorId flag and have tried a few edits to make the two cases the same, but no luck so far. In previous posts I have speculated that the auto-estimated motorSetVars_M1.RoverL_rps not being equal to actual R divided by L looked suspicious, but I don't know what to do about that or if it is a problem at all.

Is the estimation sequence estimating any other hidden parameters that I don't know about and am not manually setting?

Any ideas? Thanks.

  • 0
    TI__Guru 54875 points

    It sounds like you've made all the required code modifications correctly. Let me copy my colleague to see if he has some suggestions. Thanks for your patience.

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 150 points

    Whitney,

    Thanks for the response. Interestingly, it seems to have started working. I think I didn't try it enough times in a row before, but eventually it will actually spin up. I think I have figured out now that the overcurrents were from too high acceleration during MOTOR_CL_RUNNING phase, set by USER_MOTOR1_ACCEL_START_Hzps. After some more playing around I have disabled MOTOR_CL_RUNNING entirely with a hack in motor1_drive.c so it goes straight to MOTOR_CTRL_RUN and now the motor spins up very nicely with hard-coded parameters and seems to behave exactly how I want. Do you have any idea what the consequences of disabling MOTOR_CL_RUNNING could be? I can't see any so far.

  • 0
    Guru 56358 points
    Mitcham Tuell said:
    And I set userParams_M1.flag_bypassMotorId to false in sys_main.c.

    Needs to be true to bypass (skip) the motor ID process and read the values from user_mtr1.h, was user.h in other SDK projects. Likely why you had to change the code to get the previously ID'd motor to run.

  • 0 in reply to Genatco
    Prodigy 150 points

    Sorry, that was a typo. I set it to false to run the motor ID and true to bypass motor ID.

  • 0 in reply to Mitcham Tuell
    TI__Guru** 117160 points

    There is no any difference on FAST estimator between run the motor after identification and run with the setting parameters. They may try to change/tune the parameters in user_mtr1.c for the calculation of Kp and Ki of the current and speed PI controller. Or the may try to tune the motorSetVars_M1.Kp_spd aand motorSetVars_M1.Ki_spd in the expression watch window to find the right Kp & Ki if the USER_MOTOR1_INERTIA_Kgm2 is not known. You may check if the Kp&Ki are significant different from the identification or using the setting motor parameters. 

    objUser->BWc_rps = MATH_TWO_PI * (float32_t)100.0f;
    objUser->BWdelta = (float32_t)20.0f;

    objUser->Kctrl_Wb_p_kgm2 = (float32_t)3.0f *
    objUser->motor_numPolePairs *
    objUser->motor_ratedFlux_Wb /
    (float32_t) (2.0f * USER_MOTOR1_INERTIA_Kgm2);