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.

BOOSTXL-DRV8301 & LAUNCHXL-F28027F identified the value

Other Parts Discussed in Thread: BOOSTXL-DRV8301, LAUNCHXL-F28027F, DRV8312, MOTORWARE

Hi

When I used  the BOOSTXL-DRV8301 & LAUNCHXL-F28027F to identified the value of motor . My motor is DT4260-24-055-04 . Useing the value estimated by software there is a lot of jittery moment of the rotor . But when the value came from user.h it run very well , also DRV8312-69M-KIT can identified the value by software and the motor run well .  In order to identified the value by BOOSTXL-DRV8301 & LAUNCHXL-F28027F software what should I do ?

  • proj_lab05c and proj_lab10a I used for both kit .

  • fanqiang,

    What ID'd values did you get for the BOOSTXL where it didn't run well?

    But you also said it only ran poorly when run just after it ID'd....but if you saved and loaded the values from user.h it always ran well...that's correct?

    The motor you are using (the standard motor for DRV8312 kit) should work immediately with both kits....the default USER_MOTOR and all the settings are for this motor across all DRV83x based kits.

    If you do a "DIFF" on the two user.h files what are the differences in settings? (they should be the same for all settings except the filter_pole, and voltage/current scaling.

    Are you either saving your Voltage and Current offsets in the user.h (they are differrent for each board) or insuring you are starting the motor with gMotorVars.Flag_enableOffsetcalc enabled?

     

  • Chris

     YES, it only ran poorly when run just after it ID'd....but if I saved and loaded the values from user.h it always ran well .  

    I never changed the value in the two user.h . 

    The first and second picture the motor ran after it ID'd .the third one is loaded the values from user.h . 

    I found the different values is Ls-d and Ls-q .

    what 's the function of Flux*Full Scale Fred . sometimes the light is green sometimes it red .

  • in your first image, your

    USER_IQ_FULL_SCALE_VOLTAGE_V

    is set to 42V, which may be too high for a 12V bus and a 0.034 V/Hz motor. (BTW - the motor you are running is a 24V motor if you want to hit 4000 RPM loaded).  I think if you had 24Vbus you would still be ok with 42V....

    When you run this project (Enable Syste - Run) are you seeing an error from gMotorVars.UserErrorCode?  If not this is actually something I should add to the ErrorCheck and the spreadsheet.  In the spreadsheet I show you how to make sure the USER_IQ_FULL_SCALE_VOLTAGE_V is small enough to give you the resolution needed for low flux motors...but it can also be TOO large so that your Ls measurement doesn't have enough resolution.

    Clearly your Ls measurement during ID is too high.  This motor has an Ls of 600-700 nH, and you are measuring 14mH.

    In your 2nd image that is more interesting...you have a reasonable 24v for USER_IQ_FULL_SCALE_VOLTAGE_V but still didn't ID the Ls correctly.  What are you using for USER_MOTOR_FLUX_EST_FREQ_Hz?

    Can you Options - Attach the user.h that produces the 2nd image?  Which project are you using to ID for this?  (for this motor any of the labs BESIDES 2c should work just fine). I'd like to duplicate this behavior.

     

    "what 's the function of Flux*Full Scale Fred . sometimes the light is green sometimes it red ."

    This is a check similar to this one from the spreadsheet:

    b) Bemf Generated @ Target Hz + 10% buffer

    For larger Bemf motors (especially those that you are going to apply field weakening to run at higher speeds, you need to insure that your IQ_VOLTAGE variable is always > Flux (V/Hz) * maximum frequency (Hz).

    It is turning Red because it is warning you that at 800 Hz with 0.038 V/Hz, you need to reprsenent a per unit of over 30.4V.

     

  • "is set to 42V, which may be too high for a 12V bus and a 0.034 V/Hz motor. (BTW - the motor you are running is a 24V motor if you want to hit 4000 RPM loaded).  I think if you had 24Vbus you would still be ok with 42V...."

    I actually discusss this on

    Page 25 of

    C:\ti\motorware\motorware_1_01_00_12\docs\guis\universal\qsg_gui_universal.pdf

    However, I used 24Vbus when I did this testing...so having 12Vbus may give you an issue. I'll try it tomorrow.

     

  • I only changed the value of USER_IQ_FULL_SCALE_VOLTAGE_V . USER_MOTOR_FLUX_EST_FREQ_Hz is 20.0 .

    When I used the 24Vbus the result are same .

    the project of proj_lab10a ID'd the values : there is no error from gMotorVars.UserErrorCode .

    When I defined USER_PWM_FREQ_kHz as 30kHz to ID the values . the motor ran better than 45kHz . but not as well as the values loaded from user.h . I used 12vbus .

    24Vbus and USER_PWM_FREQ_kHz = 30kHz . it ran poorly .


    All the ID’d value of Ls is too high .

    My power is 24V/4A and 12V/3A is anything wrong ? my motor had non-loaded . 

  • I agree that something is wrong when using the Anaheim/Telco motor.  I'm trying different combinations and will let you know results / solutions.

     

  • I'm using proj_lab2b with a baseline/default MW _12 installation.

    What I've been able to verify is that you run into issues on this motor with

    USER_IQ_FULL_SCALE_FREQ_Hz  too high

    and the bus voltage being to low can have an effect on the Flux measurement being too high

    With these at:

    1200 Hz / 12V:
    I can reproduce the issue where flux IDs a little too high and Ls much too high (1mH+ vs. 0.6mH). 

    Using USER_IQ_FULL_SCALE_FREQ_Hz        (USER_VOLTAGE_FILTER_POLE_Hz * 3.9)  / 12V:
    the Flux is again a bit high but this time the Ls craters to 3.9uH.

    If I then change the IQ_VOLTAGE to (28.0) the flux still ID's high, and then the current controllers lose control during Ls testing (that horrible squeeling noise you may be familiar with by now).

    Increasing Vbus to 18V has no effect.

    But now decreasing the USER_IQ_FULL_SCALE_FREQ_Hz to (800.0) and everthing is perfect.

    With 800 Hz / 12-24Vbus I can NOT make it fail, even with 24.0 - 48.0V USER_IQ_FULL_SCALE_VOLTAGE_V and any reasonable combination of PWM (15 - 45) and decimation.

    Changing just USER_IQ_FULL_SCALE_FREQ_Hz  to (1000.0) and it again fails.

     

    I see in some of your images that you are using 800.00 Hz though...that is strange.  It worked for me perfectly.

     

     

     

     

  • I just had it fail with 800.0 / 42.0 to match yours using proj_lab10a. 

    It works fine with same user.h on proj_lab02b.


    I think it has to do with the interrupt overflowing.

    Changing the PWM to 30 KHz with decimation of 3,1, 1, 1, 10, 10 and everythign worked!

  • Even with the 30 KHz / 10 KHz I'm still seeing the issues when IQ Frequency is increased beyond 999.0 Hz

     

  • Ok, scrap all other ideas. Here is the root cause and solution for everything I can duplicate.

    During Motor ID the ForceAngle feature is used, regardless of the state of the ForceAngle Flag.

    • The switchover point between ForceAngle and FAST is set by USER_ZEROSPEEDLIMIT * USER_IQ_FULL_SCALE_FREQ_Hz
    • The following must be true for proper ID:
      USER_ZEROSPEEDLIMIT * USER_IQ_FULL_SCALE_FREQ_Hz < USER_MOTOR_FLUX_EST_FREQ_Hz

    I'll add this to the spreadsheet and to error checking for MW _13

     

  • fanqiang,

    please post your user.h, I want to see if this solves your issue. Do you have your EST_FREQ_Hz set very, very low or something?  Everythign else seems completely reasonable.

     

  • Chris,

    I hope it will be usefull . 

    #define USER_IQ_FULL_SCALE_FREQ_Hz        (800.0)  

    #define USER_IQ_FULL_SCALE_VOLTAGE_V      (42.0) 

    #define USER_ADC_FULL_SCALE_VOLTAGE_V       (26.314)     

    #define USER_VOLTAGE_SF               ((float_t)((USER_ADC_FULL_SCALE_VOLTAGE_V)/(USER_IQ_FULL_SCALE_VOLTAGE_V)))

    #define USER_IQ_FULL_SCALE_CURRENT_A         (20.0)

    #define USER_ADC_FULL_SCALE_CURRENT_A        (33.0) 

    #define USER_CURRENT_SF               ((float_t)((USER_ADC_FULL_SCALE_CURRENT_A)/(USER_IQ_FULL_SCALE_CURRENT_A)))

    #define USER_NUM_CURRENT_SENSORS            (3)  

    #define USER_NUM_VOLTAGE_SENSORS            (3)

    #define   I_A_offset    (0.839922905)

    #define   I_B_offset    (0.84156394)

    #define   I_C_offset    (0.8358885646)

    #define   V_A_offset    (0.4941458106)

    #define   V_B_offset    (0.4941235185)

    #define   V_C_offset    (0.4918507934)

    #define USER_SYSTEM_FREQ_MHz             (60.0)

    #define USER_PWM_FREQ_kHz                (30.0)

    #define USER_MAX_VS_MAG_PU        (1.0)   

    #define USER_PWM_PERIOD_usec       (1000.0/USER_PWM_FREQ_kHz)

    #define USER_ISR_FREQ_Hz           ((float_t)USER_PWM_FREQ_kHz * 1000.0 / (float_t)USER_NUM_PWM_TICKS_PER_ISR_TICK)

    #define USER_ISR_PERIOD_usec       (USER_PWM_PERIOD_usec * (float_t)USER_NUM_PWM_TICKS_PER_ISR_TICK)

    #define USER_NUM_PWM_TICKS_PER_ISR_TICK        (3)

    #define USER_NUM_ISR_TICKS_PER_CTRL_TICK       (1)     

    #define USER_NUM_CTRL_TICKS_PER_EST_TICK       (1)     

    #define USER_NUM_CTRL_TICKS_PER_SPEED_TICK  (15)  

    #define USER_NUM_CTRL_TICKS_PER_TRAJ_TICK   (15)  

    #define USER_CTRL_FREQ_Hz          (uint_least32_t)(USER_ISR_FREQ_Hz/USER_NUM_ISR_TICKS_PER_CTRL_TICK)

    #define USER_EST_FREQ_Hz           (uint_least32_t)(USER_CTRL_FREQ_Hz/USER_NUM_CTRL_TICKS_PER_EST_TICK)

    #define USER_TRAJ_FREQ_Hz          (uint_least32_t)(USER_CTRL_FREQ_Hz/USER_NUM_CTRL_TICKS_PER_TRAJ_TICK)

    #define USER_CTRL_PERIOD_usec      (USER_ISR_PERIOD_usec *

    #define USER_CTRL_PERIOD_sec       ((float_t)USER_CTRL_PERIOD_usec/(float_t)1000000.0)

    #define USER_MAX_NEGATIVE_ID_REF_CURRENT_A     (-0.5 * USER_MOTOR_MAX_CURRENT)  

    #define USER_ZEROSPEEDLIMIT   (0.002)    

    #define USER_FORCE_ANGLE_FREQ_Hz            (1.0)  

    #define USER_MAX_CURRENT_SLOPE_POWERWARP   (0.3*USER_MOTOR_RES_EST_CURRENT/USER_IQ_FULL_SCALE_CURRENT_A/USER_TRAJ_FREQ_Hz)

    #define USER_MAX_ACCEL_Hzps                 (20.0)

    #define USER_MAX_ACCEL_EST_Hzps           (5.0)    

    #define USER_MAX_CURRENT_SLOPE           (USER_MOTOR_RES_EST_CURRENT/USER_IQ_FULL_SCALE_CURRENT_A/USER_TRAJ_FREQ_Hz) 

    #define USER_IDRATED_FRACTION_FOR_RATED_FLUX (1.0) 

    #define USER_IDRATED_FRACTION_FOR_L_IDENT    (1.0)  

    #define USER_IDRATED_DELTA                  (0.00002)

    #define USER_SPEEDMAX_FRACTION_FOR_L_IDENT  (1.0)  

    #define USER_FLUX_FRACTION           (1.0)   

    #define USER_POWERWARP_GAIN                   (1.0) 

    #define USER_R_OVER_L_EST_FREQ_Hz (300)           

    #define USER_VOLTAGE_FILTER_POLE_Hz  (364.682) 

    #define USER_VOLTAGE_FILTER_POLE_rps  (2.0 * MATH_PI * USER_VOLTAGE_FILTER_POLE_Hz)

    #define USER_OFFSET_POLE_rps            (20.0)  

    #define USER_FLUX_POLE_rps              (100.0)  

    #define USER_DIRECTION_POLE_rps             (6.0) 

    #define USER_SPEED_POLE_rps           (100.0)

    #define USER_DCBUS_POLE_rps           (100.0)

    #define   USER_EST_KAPPAQ               (1.5)

     

  • I need to see the USER_MOTOR settings you are using. Pleaes just go to Options - Add File to upload your user.h

    So far everything you posted is fine. I would change both of these to (10), but that's a minor thing.

    #define USER_NUM_CTRL_TICKS_PER_SPEED_TICK  (15)  

    #define USER_NUM_CTRL_TICKS_PER_TRAJ_TICK   (15)

    as long as you are using the standard USER_MOTOR = Anaheim...

    with FLUX_EST_FREQ_Hz (20.0) or (30.0)

    You can not be having any SW problems. If there are still issues it has to be HW related or the motor is damaged (not very likely).

     

  • Chris 

    #define USER_NUM_CTRL_TICKS_PER_SPEED_TICK  (10)  

    #define USER_NUM_CTRL_TICKS_PER_TRAJ_TICK   (10)

    I have tried . but the motor also ran poorly .

  • fan,

    When I get my laptop back I'll use your exact user.h and run.  I'm positive it will work correctly though.

    There must be a HW issue with your BOOST or LAUNCH

     

  • Chris,

    you mean that it ID'd the values and work correctly ? if it's HW issue with my BOOT or LAUNCH ,why I loaded the values from user.h and the motor ran well . 

    In your  opinion what  's  the HW issue would be ?

  • I have not run a project with YOUR user.h yet. Once I get my laptop back I will (today/tomorrow), but I expect that it will ID fine.

     

    That's a good point, that you say the motor runs fine when you bypass motor ID....that doesn't point to a HW issue, I agree.

     

    Let me test when I get a chance...hopefully your user.h fails for me and we just overlooked something simple.

     

  • you're right, I see the same error just dropping your user.h into MotorWare _12 for BOOSTXL + F28027F.

    Ls does not identify correctly and flux is just a little too large.....let me figure this out by changing one item at a time.

     

  • ok, I took my working user.h and changed the variables one at a time to match yours, testing Motor ID each step until everything was identical except for the user.h offsets....which shouldn't matter as Offsetts are Recalculated during ID.

    and I can still ID just fine with your exact settings (you can see I even have your incorrect 10 KHz / (15) for speed and trajectory which displays as 0)

    I tried copying over your exact Offsets, so now my user.h is IDENTICAL to yours....

    First I did just the currents, no change, could still ID.

    Then I did the voltages, no change, could still ID.

     

    User.h are 100% identical, and I can ID with the built proj_lab02b.out

    Now I build with your user.h (the compiler won't even build because it doesn't think the user.h has changed, so I force a Rebuild) and it ID's fine.

    I go back and re-download

    6505.user.h

    directly to C:\ti\motorware\motorware_1_01_00_12\sw\solutions\instaspin_foc\boards\boostxldrv8301_revB\f28x\f2802xF\src\user.h

    This time it builds (I don't have to force a Rebuild)

    It ID's fine.  I do 5 straight IDs and each of them are the exact same, all working.

     

    I am completely stumped....no idea what hapened....it certainly didn't work the FIRST time I tried. But now I can't make it fail at all.

     

    Maybe there is something very marginal about the 42V IQ_VOLTAGE and 20 Hz FLUX_EST_FREQ_Hz...but if that's the case you should get it to ID MOST of the time...like I'm seeing. Attached user.h has things set to a slightly better scale for this motor...see if you still see failures.  Here are results from running this user.h with proj_lab02b

     

    user.h
  • Chris ,

    I have run the proj_lab02b with YOUR user.h . and changed the Vbus . but I haven’t get the same result like yours .

    When Flux * Full Scale Freq > 30 and it turn red .

    I wondered if Flux * Full Scale Freq turn red has influence on the ID’d values ?

    I believe that the values has ID’d correctly on your kit . but I don’t think there is HW issue with my kit . Here are my HW , is anything wrong ?

    Chris can you give some advice what should I do to find out the reason why I can't ID'd the values correctly .

     

  • fan,

    your image is too resolution, please increase so I can see the values of the GUI screenshot.  There is nothing wrong with your HW settings.

    please check which compiler you are using.

    Right click on the project in CCS --> Properties --> General

    You need to be using v6.2.3 +

  • Hi Chris

    I'm sorry for so late reply  . I have update the compiler to v6.2.3 but the ID'd Ls still too large . I have tried to use another BOOSTXL-DRV8301 but nothing changed . 

  • BTW the second PCB of BOOSTXL-DRV8301 is made using TI Open source gerber.rar . I failed  ID'd the LVSERVOR too .  I will focus on the problem and if I find the reasons I will let you know .

    whatever , thanks Chris 

     

    I really need your help to clear confusions . 

    1、_iq beta_lp_pu = _IQ(pUserParams->offsetPole_rps/(float_t)pUserParams-> ctrlFreq_Hz); can you talk more about the expression . and what’s the relationship between the beta_lp_pu and the coefficient(a0,a1etc) ? 

    2、In the software code of CTRL_setParams(CTRL_Handle handle,USER_Params *pUserParams)

    // set the default Id PID controller parameters

    Kp = _IQ(0.1);

    Ki = _IQ(pUserParams->ctrlPeriod_sec/0.004);

    Kd = _IQ(0.0);

    outMin = _IQ(-0.95);

    outMax = _IQ(0.95);

      // set the default speed PID controller parameters

      Kp = _IQ(0.02*pUserParams->maxCurrent*pUserParams->iqFullScaleFreq_Hz/pUserParams->iqFullScaleCurrent_A);

      Ki = _IQ(2.0*pUserParams->maxCurrent*pUserParams->iqFullScaleFreq_Hz*pUserParams->ctrlPeriod_sec/pUserParams->iqFullScaleCurrent_A);

      Kd = _IQ(0.0);

    outMin = _IQ(-1.0);

    outMax = _IQ(1.0);

    why the default PID controller parameters set like that ? can I changed the default values and how to change it .

    When the values are ID'd . the Kp Ki set like this . 

    3、

    // ***********************************
    // configure and run the Id controller

    // compute the Kp gain
    // Scale Kp instead of output to prevent saturation issues
    if(CTRL_getFlag_enableDcBusComp(handle))
    {
    Kp_Id = _IQmpy(Kp_Id,EST_getOneOverDcBus_pu(obj->estHandle));
    }

    I know Kp_Id multiply by EST_getOneOverDcBus_pu(obj->estHandle)  used for compensation via changed the Duty  . Chris can you explain the expression in theory ? 

    in the UG . the values of PID tuned automatically  but how to tune automatically ? in my opinion  Automatic  adjustment  means that real time base on diffrent speed or torque . in the software code , when the motor's values ID'd . call the function of calcPIgains()  .

    void calcPIgains(CTRL_Handle handle)
    {
    CTRL_Obj *obj = (CTRL_Obj *)handle;

    float_t Ls_d = EST_getLs_d_H(obj->estHandle);
    float_t Ls_q = EST_getLs_q_H(obj->estHandle);
    float_t Rs = EST_getRs_Ohm(obj->estHandle);
    float_t RoverLs_d = Rs/Ls_d;
    float_t RoverLs_q = Rs/Ls_q;
    float_t fullScaleCurrent = EST_getFullScaleCurrent(obj->estHandle);
    float_t fullScaleVoltage = EST_getFullScaleVoltage(obj->estHandle);
    float_t ctrlPeriod_sec = CTRL_getCtrlPeriod_sec(handle);
    _iq Kp_Id = _IQ((0.25*Ls_d*fullScaleCurrent)/(ctrlPeriod_sec*fullScaleVoltage));
    _iq Ki_Id = _IQ(RoverLs_d*ctrlPeriod_sec);
    _iq Kp_Iq = _IQ((0.25*Ls_q*fullScaleCurrent)/(ctrlPeriod_sec*fullScaleVoltage));
    _iq Ki_Iq = _IQ(RoverLs_q*ctrlPeriod_sec);
    _iq Kd = _IQ(0.0);

    // set the Id controller gains
    PID_setKi(obj->pidHandle_Id,Ki_Id);
    CTRL_setGains(handle,CTRL_Type_PID_Id,Kp_Id,Ki_Id,Kd);

    // set the Iq controller gains
    PID_setKi(obj->pidHandle_Iq,Ki_Iq);
    CTRL_setGains(handle,CTRL_Type_PID_Iq,Kp_Iq,Ki_Iq,Kd);

    return;
    } // end of calcPIgains() function

    my question is Ki is similar to what said in the UG . in the UG Kp = L *bandwidth . the bandwidth I think is selected by the specific system . however the Kp in calcPIgains() I think it's constant as fullScaleCurrent /fullScaleVoltage /ctrlPeriod_sec is constant  for a specific system . So what 's the reason ? 

     

    4、For exzample  pUserParams->ctrlWaitTime[CTRL_State_OffLine]=(uint_least32_t)(5.0*USER_CTRL_FREQ_Hz);

    In the example above, the offsets calibration is done for a period of 5 seconds.

    questions: I think the timer is used to calculate the time but which one ? if timer isn’t used how to calculate the time .

    5、LAST question . I confused about trajectory generator . What’s the function of trajectory generator in the system ?

    thanks,

     

  • please post your most recent user.h, confirm you are using MotorWare _12, and you actually BUILD the project with compiler 6.2.3+  (on the properties page you should NOT see any compiler versions less than 6.2.3)

    fanqiang Meng said:

    1、_iq beta_lp_pu = _IQ(pUserParams->offsetPole_rps/(float_t)pUserParams-> ctrlFreq_Hz); can you talk more about the expression . and what’s the relationship between the beta_lp_pu and the coefficient(a0,a1etc) ? 

    beta_lp_pu is just the software Low Pass (lp) filter in per unit radians (why youd divide by the CTRL freq to cancel out  the seconds

    offsetPole_rps is set in user.h USER_OFFSET_POLE_rps (20.0)

    nothing to do with coefficients.

    fanqiang Meng said:

    why the default PID controller parameters set like that ? can I changed the default values and how to change it .

    This is a "rule of thumb" we use just to initialize the Speed PI controllers to something.  It generally works ok (stable) for most motors.  For high RoverL motors these gains are much too stiff. For low RoverL they are much too soft.

    Follow proj_lab05b to calculate your speed gains.  I also outline some options for doing a first tuning by hand at zero speed.

    C:\ti\motorware\motorware_1_01_00_12\docs\guis\universal\qsg_gui_universal.pdf

    fanqiang Meng said:
    I know Kp_Id multiply by EST_getOneOverDcBus_pu(obj->estHandle)  used for compensation via changed the Duty  . Chris can you explain the expression in theory ?

    OneOverDcBus_pu (per unit) will be a percentage of the IQ_VOLTAGE.

    So if your IQ_VOLTAGE is 24V and you Vdc_Bus measurement is 24V you will have a unity gain.  This gets multiplied by the Kp value to scale it.  So if the Vbus goes higher, the Kp will reduce. If Vbus goes lower, the Kp goes higher to compensate for the lower voltage present on the bus for the inverter duty cycle to use.

     

    fanqiang Meng said:
    in the UG . the values of PID tuned automatically  but how to tune automatically ?

    This is all explained in the Lab Guide. Are you following?

    C:\ti\motorware\motorware_1_01_00_12\docs\labs\instaspin_labs.pdf

    see proj_lab05a

    fanqiang Meng said:
    my question is Ki is similar to what said in the UG . in the UG Kp = L *bandwidth . the bandwidth I think is selected by the specific system . however the Kp in calcPIgains() I think it's constant

    I think the lab write-up for 05a is confusing....what is written is an option of looking at the current controller gains if you wanted to change or experiment with the bandwidth.  All well and good - I guess - but that's not what is done by default in the software, and isn't necessary.

    The current control tuning set by the software works extremely well for most motors.

    _iq Kp_Id = _IQ((0.25*Ls_d*fullScaleCurrent)/(ctrlPeriod_sec*fullScaleVoltage));
    _iq Ki_Id = _IQ(RoverLs_d*ctrlPeriod_sec);
    _iq Kp_Iq = _IQ((0.25*Ls_q*fullScaleCurrent)/(ctrlPeriod_sec*fullScaleVoltage));
    _iq Ki_Iq = _IQ(RoverLs_q*ctrlPeriod_sec);

    fanqiang Meng said:
    questions: I think the timer is used to calculate the time but which one ? if timer isn’t used how to calculate the time

    The state transitions that have time dependencies are based on an internal counter compared to the value stored in the respective wait time in user.c:

    uint_least32_t ctrlWaitTime[CTRL_numStates]; //!< Defines the wait times for each controller state, estimator ticks

    The "5 seconds" isn' t 5 seconds because of the number 5.  The seconds is determined by the relationship to USER_CTRL_FREQ_Hz and the Estimator Hz (equal by default user.h settings, but doesn't have to be)

    Example, if you use a CTRL rate of 10 KHz and EST rate of 5 KHz this same equation

    pUserParams->ctrlWaitTime[CTRL_State_OffLine]=(uint_least32_t)(5.0*USER_CTRL_FREQ_Hz);

    would produce a wait time of (50,000) estimator states (which are at 5 KHz) = 10 seconds

    fanqiang Meng said:

    5、LAST question . I confused about trajectory generator . What’s the function of trajectory generator in the system ?

    Trajectory generation is what feeds the speed controller.

    For example, if I am going 1 KRPM and want to accelerate to 9 KRPM at 1 KRPM/s, you don't just set a new speed reference of 9 KRPM to the input of the speed controller.

    You create a trajectory profile:

    1000 RPM  to 9000 RPM = 8000 RPM change, at 1 KRPM/S = 8 seconds

    If your speed loop is running at 1 Hz (default), that is an update every 0.001 seconds.

    So your trajectory will have 8 seconds / 0.001 seconds = 8000 updates

    Each update to the speed controller will then have a delta step of 8000 RPM / 8000 updates = 1 RPM / update

    So what your Trajectory is feeding into the Speed Reference is a new Speed Ref for every speed loop update at 1 Hz.

    t = 0  (0.000 sec)  1000 RPM
    t= 1  (0.001 sec)    1001 RPM
    t = 2  (0.002 sec)  1002 RPM
    ....
    t = 8000  (8.000 sec) 9000 RPM

     

  • Dear all,

    I have some problems with  DRV8312-69M-KIT (that KIT use TELCO DT4260-24-055-04 motor)

    I try to run project lab_5c on that KIT

    But there is some not good results

    1. With high-speed, it's okay (set speed = estimated speed)

    2. With low-speed, the FAST module estimated wrong value.

    Any professional or MOTOR team of TI can help me? Thanks alot!

     

  • 1. Anytime you are evaluating low speed performance disable ForceAngle

    2. Just like you were taught in 5b you need to tube the speed controller. For 5c this means increasing the BW. 1.0 is too low for scale AND more importantly it looks like you are missing a variable in you user.h so the effective bandwidth is 0.0. I'm shocked this controls anything actually.

  • Dear Chris,

    I know U r shocked when see the figure that I posed.

    But it´s the fact. I don´t know why. But I want to solve this deeply.

    I have just bought that KIT from eStore two days ago.

    At fisrt, I run the code pre- programed on Chip by TI.

    But in low-speed, the result is the same last post (estimated-speed is not equal to set speed)

    So, I try another code (proj 5c) with hope that the result better... But as you see:(

    I will try your advice and respone later.

    Any other ideas, professor?

  • 5c is just for inertia ID.

    you need to then run 5e to have the bandwith changes take effect.

    please follow instaspin_labs.pdf

  • Have you tried checking the actual speed of the motor using a tachometer?  I would expect that FAST is reading the true speed of the motor and that the system is having a hard time regulating that low of a speed with the Telco motor.

    Also Lab 05c still uses the PI controller to control the speed.  That lab is only designed to get the inertia value needed for all of the following InstaSPIN-MOTION labs.

  •  Dear Chris,

    I have try LAB 5e with modification of BW (0-5)

    But the estimated speed is still not right

  • This doesn't make much sense. 100 RPM command should be much better than what you are seeing.

    If you give it a slight load with your fingers does it improve?

    How is the regulation at 500 RPM?

    I can run the same motor + HW at 22.5 RPM (1.5 Hz).

    Are the Idq_Kp and Ki values the default or did you change them?

  • Hi Chris,

    - At 500 RPM, it run very well

    - The Kp and Ki are the default values

    Can U post your test at low-speed here?

    I have try many ways (modify user.h) but at the rate < 100 RPM, It run not good!

    Now, I am setting up an encoder part (3000 pulses) to run lab 12b. But when I run the universal GUI to load firmware (appProgram.out) to controlCard. The driver IC is very hot and motor run only one time.

    I check the signal of encoder wire feedback to chip by oscilloscope. It's okey

    Any change need to do with the sourcecode on lab 12b?

  • You should not need to modify the source code in lab 12b. For the 3000 pulse encoder, what value are you setting in usher.h? This value should be set to the number of pulses or lines on the encoder disc. 

    Have you confirmed that the motor and the encoder are wired so that they agree on which direction is positive? There should be instructions in the lab guide for how to confirm this. 

  • Dear Adams,

    I have checked the connected wires for encoder signal to Jumper J4 okie.

    In user.h I set 3000 for encoder line number

    But it can not run!☹

    I have a plan to apply TI control method to our product.

    But with 2 problems of KIT, I think we can not continue...

  • When you ran the lab 05d, did the motor spin anti-clockwise?

    When running  the labs with an encoder, it is critical that the motor and encoder are aligned.  If they are not aligned than your motor will not spin.

    Follow this procedure to ensure that your encoder is setup correctly:

    1. In lab 12b set gMotorVars.Flag_enableSys to 1

    2. Add st_obj.vel.conv.Pos_mrev to the watch window (this is an IQ24 variable)

    3. Manually rotate the encoder anti-clockwise 1 rotation

    4. Check that the value in st_obj.vel.conv.Pos_mrev is equal to 1.  If this value is not equal to 1 than there is a problem with the encoder configuration.  This means that the Motor Pole Pairs or Encoder Line Count is incorrect.  If this value is -1 than you need to switch A & B lines in your encoder.

  • The motor in your original post has hall sensors, not an encoder. 

    You can certainly tune the speed controllers in sensorless mode for good response at 7.5Hz / 100 RPM, especially with some load. 

    There is a series of videos using the LaunchPad + BoosterPack where I show load speed performance. It is on the video player at the support tab at www.ti.com/instaspin

  • Thanks Adam! I will test again with setting up motor and encoder are aligned.

    @ Chris: I have set up a new encoder addon. I think sensorless method is not suitable at low speed. So I try sensored method. Anyway, thank you very much for these support. SpinControl is a big research that I want to study.

  • Dear Adam,

    I fixed that error (The encoder A&B wire is connected wrong way).

    So now, I can run the lab 12b. It's seem to be better than use sensorless.

    My project need to run motor from 1 RPM to 2000 RPM. So it's very important to research low-speed control.

    That's is some results:

    Can U share some advices when controling at low-speed use SpinControl method of TI? (I use sensored method)

  • The first thing to try in the GUI is to increase the bandwidth beyond 5. You can do this by manually entering numbers in the green BW Scale box. You should be able to go up to 10. 

    The next step would be to modify the sample time of the speed loop. You can do this in the user.h file. The parameter to modify is the CTRL ticks per SPEED tick value. With a smaller sample time this will also let you set a larger bandwidth value. 

    It it is also critical to get a good value for the inertia. I would redo the inertia estimation using lab 12a. This gives a better estimate than lab 05c. 

  • So clearly, thanks for your help Adam!

    I will note when testing motor.

  • Cao Son Dinh said:
    My project need to run motor from 1 RPM to 2000 RPM. So it's very important to research low-speed control.

    Correct, constant 1 RPM control can NOT be done with InstaSPIN-FOC today. A sensor is required.

  • Dear Adam and Chris,

    I have successful run lab12b with 3000 pulses encoder addon.

    There are some images capture the encoder signal channel A feedback to DSP.

    - At 2000RPM

    - At 1000RPM

    - At 10RPM

    - By seeing motor running, it's okey from 10RPM to 2000 RPM.

    But when I check the signal of encoder reponse to DSP (OUTA or OUTB after voltage-level IC on board). It is not stable (you can compare MIN and MAX freq).

    - Can you share some ideas to reduce noise and fluctuation.

    My target is run well at 1RPM.

    Thanks!

  • What value for bandwidth are you using for this motor?

    Have you tried adjusting the sample time of the speed loop?

  • Hi Adam,

    Follow your guide, I set 20 for BW. It mean 400 rad/s ( It's the best value with my motor)

    Sample time (or frequency to pick-up samples) is thing that I've thought to adjust. 

    But I have not found that parameter or virable which present it. I will find again... Thanks!

  • That parameter is in the user.h file. There is a section about setting up the clocking or timing. I'm on mobile right now so it is difficult to look up. I believe it is called CTRL_TICKS_PER_SPEED_TICK. This is the number of FOC calls in between Speed calls. There is a section in the users guide that talks about this in greater detail. 

  • I have found it and ajusted, but the default value is the best one Adam. I will post the video running at 1RPM next-time. I´m online by mobile phone too.

    There is a problem about Torque at low-speed I wanna solve.

  • Here is the VIDEO

    http://youtu.be/BH_CAptADfQ

    Is this run okey follow INSTASPIN method of TI? 

    At this speed, I can turn the motor-cylinder easily follow clockwise.

    How to keep the moment of motor-cylinder during motion?

    'Cos i'm afraid that, it can not run well when bring load.

     

  • Based on that video it looks like is has decent control of the motor at 1rpm.  It seems to be rotating smoothly.

    If you bandwidth is sufficiently high you should have no issues with producing torque at those low speeds.