• State
  • Locked Locked
  • Replies 34 replies
  • Subscribers 82 subscribers
  • Views 3718 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

The motor is completely uncontrollable after starting the motor

chang lianqing
Intellectual 770 points
Other Parts Discussed in Thread: MOTORWARE

hello,

the error is when i enable the gMotorVars.Flag_enablesys & gMotorVars.Flag_Run_Identify, motor reach max speed suddenly(very fast).

and change SpeedRef_krpm value  is no effect.

and it did not happend every time,

this is the screenshot when error happend with lab12b.

.

  • 0
    Intellectual 770 points
    could anyone help me analysis the reason
  • 0 in reply to chang lianqing
    TI__Guru** 118000 points

    were you able to control the motor in the previous labs?

    if so, it seems like an encoder alignment issue.

  • 0 in reply to ChrisClearman
    Intellectual 770 points
    thank you,how could I find the key of problem.
    if it was encoder error,could I find something from screenshot.
  • 0 in reply to ChrisClearman
    Intellectual 770 points
    I could run lab12b correct normally,but error happend very occasionally
  • 0 in reply to chang lianqing
    TI__Guru** 118000 points
    were you able to run any of the motion lab5c+ ?
    if so, it is likely an issue with lab12a, where the encoder is aligned to a zero electrical angle. follow the lab document again.
  • 0 in reply to ChrisClearman
    Intellectual 770 points
    I could run lab5c correct, and this problem is orcurred very very occasion in lab12b,most result is OK
  • 0 in reply to chang lianqing
    TI__Guru** 118000 points
    this sounds like an encoder alignment issue.
    you need to generate enough torque (through higher RES_EST_CURRENT) setting during RsRecal to drive the rotor (and any load) to a zero electrical position as described in the lab guide for 12a.
  • 0 in reply to ChrisClearman
    Intellectual 770 points
    motor did not have any load now, if RES_EST_CURRENT is not enough,so that motor run uncontrollable.

    it was very dangerous when motor drive load.

    how could i add some protective code to avoid this error occur again?
  • 0 in reply to chang lianqing
    TI__Guru** 118000 points
    chang,
    for sensored operation you need to do an initial electrical to mechanical offset. In the labs the method to do this is by using the RsRecal feature as a proxy for driving Iq = 0 and Id = DC VALUE. If you need to increase this value so much to insure rotor alignment it may make your Rs value increase. In a sensored system Rs is only used for setting the current controllers, but this may be a problem. It is probably a better idea to either
    a) after RsRecal to align, re-write the normal Rs value into CTRL
    b) have a separate set of logic that sets Iq = 0 and Id = ALIGNMENTVALUE before you start-up

    There really isn't a way to guarantee that you have made an electrical to mechanical alignment though unless you use one with an index/home, an absolute encoder, or resolver.
  • 0 in reply to ChrisClearman
    Intellectual 770 points

    thank you for your help,

    firstly, could you confirm that this error (motor driver to max speed  with momentary), because of incorrect  encoder zero offset value.

    fortunately, my system have a RDC chip(ad2s1210) to generate A/B/I signal, and I could acquire the position value by SPI interface, as you said ,may I set the enc offset by that value?

    could you help me how to do this ?

  • 0 in reply to chang lianqing
    TI__Guru** 118000 points
    i believe this is the error, yes.

    yes, if you can get an electrical angle and convert it to a per unit, you should set the EST_setAngle with this value before setting the new speed/position reference.

    //! \brief Sets the angle value in the estimator in per unit (pu), IQ24.
    //! \details This function overwrites the estimated angle with a user's provided angle.
    //! The set value should be between 0x00000000 or _IQ(0.0) to 0x00FFFFFF or _IQ(1.0).
    //! The following example shows how to overwrite the estimated angle:
    //! \code
    //! _iq Overwrite_Flux_Angle_pu = _IQ(0.5);
    //! EST_setAngle_pu(handle, Overwrite_Flux_Angle_pu);
    //! \endcode
    //! \details This function is not recommended for general use, since this will automatically generate
    //! an axis misalignment between the rotor flux axis and the control signals driving the motor.
    //! The use of this function is recommended for advanced users interested in doing open loop
    //! startup algorithms that need to bypass the estimator.
    //! \param[in] handle The estimator (EST) handle
    //! \param[in] angle_pu The angle value, pu
    extern void EST_setAngle_pu(EST_Handle handle,const _iq angle_pu);
  • 0 in reply to ChrisClearman
    TI__Guru** 118000 points
    correction, you need to set through the CTRL since you are using sensored

    CTRL_setAngle_pu(handle,angle_pu);
  • 0 in reply to ChrisClearman
    Intellectual 770 points
    I will try to startup with my RDC position info later.
    thank you.
  • 0 in reply to chang lianqing
    Guru 12800 points

    Chang,

    Chris' recommendations are good.  The one thing I would change is that I think it would be better to use the offset provided by the ENC module.

    One key difference between FAST and the ENC block is that the ENC block calculates the electrical angle for whatever input it is given.  So if you were to use CTRL_setAngle_pu that would work for starting the system, but as soon as the next isr uses the electrical angle from the ENC block then the angle is wrong.

    The alignment is accomplished by running the function ENC_setZeroOffset.  I would recommend that when you system starts up, you read the encoder position over SPI and calculate how far away that is from 0 degrees electrical.  You can provide that value as the zero offset so that the ENC block will now be aligned to what the SPI angle is.

    The other option would be to not use the ENC block at all and use the SPI angle in all situations.  In order to do this you would need to convert the angle you read over SPI into the setup that is expected by the FOC.  So it would need to vary between 0 and 1 over each electrical cycle of the motor, where 0 is aligned to motor 0.  This would also need to be in an IQ24 variable.  In the sensored labs there is an example of how to provide a non-EST electrical angle.  I would recommend that you follow this example.

  • 0 in reply to Adam D. Reynolds
    Intellectual 770 points
    thank you,
    the most important thing to me is avoid the error when i enable system,which lab did you said about non-est electrical angle?
  • 0 in reply to chang lianqing
    Guru 12800 points
    Any of the sensored labs (12-13) should show this example.
  • 0 in reply to Adam D. Reynolds
    Intellectual 770 points
    i think lab12b have been using ENC_setZeroOffset during RSrecal,this means est electrical angle, or I have a misunderstand about your advice?
  • 0 in reply to chang lianqing
    Guru 12800 points
    Lab 12b uses ENC_setZeroOffset to setup an offset so that the ENC block is aligned with the electrical angle of the motor. It is expecting an input that is the number of QEP counts.

    If you want to use the SPI angle all of the time, you would need to provide the electrical angle to the CTRL_run function.
  • 0 in reply to Adam D. Reynolds
    TI__Guru** 118000 points
    for example, in 12b you would update

    else {
    // run the controller
    CTRL_run(ctrlHandle,halHandle,&gAdcData,&gPwmData,ENC_getElecAngle(encHandle));
    }

    to replace ENC_getElecAngle(encHandle) with your value from the SPI/RDC.
  • 0 in reply to Adam D. Reynolds
    Intellectual 770 points
    hi,
    i try to remove enc_zero_offset from ENC_calcElecAngle(),

    // add in calibrated offset
    //temp += enc->enc_zero_offset;

    and the error look like didn't happen again, if the source code changed like this, dose it have a bad influence in other labs(position ctrl)?


    another quertion, which variable is the error source?did any variable had been overflow during incorrect control?
  • 0 in reply to ChrisClearman
    Intellectual 770 points
    i find a strange phenomenon about my RDC chip.

    qep->QPOSCNT always became a large number(65500 to 65535), whatever motor real angle is. but the postion value accquire from SPI was static(if motor's angle didn't change).

    because of enc_elec_angle is calculated according to the qep->QPOSCNT, so i couldn't use SPI result to figure out enc_zero_offset,unless i use the value all from SPI/RDC.

    for Simplify the system,i prefer to use the qep->QPOSCNT more than SPI value, so i want to find the way that can avoid the problem,may i remove enc_zero_offset?

    by this way, i guess motor will no longer have this error,right?
  • 0 in reply to chang lianqing
    Guru 12800 points
    If you use the A/B/I interface and remove the encoder offset there is little chance that the motor and the encoder will be aligned. When the system starts the assumed motor angle is 0 while it is actually something else. The alignment step allows for the incremental encoder to become aligned with the motor angle.

    You should be able to take the SPI angle and either calculate what the offset should be. Since the SPI angle is absolute, you would need to convert it so that when it is added to the QEP angle it will produce a 0 degree angle when the absolute angle should be 0 degrees.
  • 0 in reply to Adam D. Reynolds
    Intellectual 770 points

    hello Adam，

    first i think qep.QPOSCNT is a counter to count A/B signals as relative value.

    when system start up, assume that qep.QPOSCNT have a random value, so i could get an offset by  

    ENC_setZeroOffset(encHandle,ENC_getPositionMax(encHandle) -  ENC_getRawEncoderCounts(encHandle));

    1.does ((QPOSMAX - QPOSCNT) * mech_angle_gain) is the relative zero now? if so, why did zeroOffset setup until elec_angle = 0?

    2.what's the relationship between QPOSCNT and motor angle? i think QPOSCNT just show how far does the angle changed.

    how could i transform SPI angle into elec_angle and figure out the offset before motor start up?


     

  • 0 in reply to chang lianqing
    Guru 12800 points

    chang lianqing said:
    1.does ((QPOSMAX - QPOSCNT) * mech_angle_gain) is the relative zero now? if so, why did zeroOffset setup until elec_angle = 0?

    When the system starts up, the QEP is assumed to be 0.  The value for offset used by the ENC block ends up being ((QPOSMAX - QPOSCNT) * mech_angle_gain) once the value (QPOSMAX - QPOSCNT) is passed into the ENC_setZeroOffset function.  You should only set the zero offset when the motor is actually aligned to a zero degree electrical angle.

    chang lianqing said:
    2.what's the relationship between QPOSCNT and motor angle? i think QPOSCNT just show how far does the angle changed.

    QPOSCNT is the mechanical angle reported by the QEP.  The ENC block converts this into the electrical angle of the motor.  QPOSCNT is actually the true mechanical angle since it will be reset each mechanical revolution since it resets at the maximum encoder count.

    chang lianqing said:
    how could i transform SPI angle into elec_angle and figure out the offset before motor start up?

    My advice would be to collect some data on the electrical angles as the motor is rotated so that you can understand the relationship between SPI angle and electrical angle.  It would be best to start from a known electrical angle, i.e. during Rs recalibration at startup.

  • 0 in reply to Adam D. Reynolds
    Intellectual 770 points

    hello Adam,

    In general, my goal is find out the reason why motor accelerate to max speed uncontrollabe. 

    in  the initial condition, which part of the code may triggers this error?

  • 0 in reply to chang lianqing
    Guru 12800 points
    Like Chris mentioned, in sensored control if the motor and encoder are not aligned the motor will run uncontrollably. This occurs since the angle that the control system on the MCU is using does not accurately reflect the motor position.

    If this occurs each time the motor is started it could be related to phase order, so you would need to swap two of the motor phases. But if it occurs occasionally, than it is an alignment issue.
  • 0 in reply to Adam D. Reynolds
    Intellectual 770 points
    yes, it occurs very occasionally. but i think it is very dangerous.

    1.if i remove RSrecal and doing as follow,

    while(!(gMotorVars.Flag_enableSys))
    {
    if(Flag_SystemON == true)
    {
    //turn off MainISR first

    //clear QPOSCNT register,
    QEP_set_soft_init (hal.qepHandle[0], QEPCTL_Swi_Auto_Init_Counter);

    //clear zero_offset
    enc.enc_zero_offset = 0;

    //offset = 0, QPOSCNT = 0, so that elec_angle = 0 now
    ENC_calcElecAngle(encHandle, HAL_getQepPosnCounts(halHandle));

    ENC_setZeroOffset(encHandle, (uint32_t)(HAL_getQepPosnMaximum(halHandle) - HAL_getQepPosnCounts(halHandle)));

    //turn on MainISR now

    gMotorVars.Flag_enableSys = 1;
    gMotorVars.Flag_Run_Identify = 1;
    }
    }

    in this way, if i could have a correct value when i start up system?


    2.everytime MCU power on, QPOSCNT will reset to zero value, and if i spin my motor a little angle, QPOSCNT will increase or decreacse with the A/B signal. so i think elec_ange(QPOSCNT) indicate the relative angle that motor spin. so the motor absolutly angle will not have an effect on the angle which MCU using now.

    if my understanding is wrong, please correct my errors.thank you
  • 0 in reply to chang lianqing
    Guru 12800 points

    chang lianqing said:
    1.if i remove RSrecal and doing as follow,

    In this case, I'm not sure how your encoder is aligned to your motor.  In doing this have you made sure that the motor is at electrical angle 0?

    chang lianqing said:
    2.everytime MCU power on, QPOSCNT will reset to zero value, and if i spin my motor a little angle, QPOSCNT will increase or decreacse with the A/B signal. so i think elec_ange(QPOSCNT) indicate the relative angle that motor spin. so the motor absolutly angle will not have an effect on the angle which MCU using now.

    The QEP will indicate the relative angle from when the system powers on.  The labs align this relative angle to the actual angle by setting the zero offset during the rs recalibration.  

  • 0 in reply to Adam D. Reynolds
    Intellectual 770 points
    Excuse me,

    i had my best try to solve this problem these day,but i couldn't make it ok.
    so i asking for help again.

    1.what is the difference between enc_elec_angle and EST_getAngle_pu() result?

    2.i could find that elec_angle became 0 durning RSrecal , did EST_getAngle_pu() will also return 0?

    3.when RSrecal finished, motor will spin to a fixed absolutly angle everytime,
    and my USER_MOTOR_NUM_POLE_PAIRS = 2,
    the "fixed absolutly angle" have two value(maybe 110° and 290°) .
    if the motor actually aligned to a zero degree electrical angle at these two point?

    4.what decide motor spin how many angle durning RsRecal,
    EST_getAngle_pu() == 0 or elec_angle == 0, or other factor?

    5.if my max_current_res_est is too low to drive the motor during RsRecal, the error will occur(i lock my motor by hand).
    so i assume that if the motor have a very huge load and i set USER_MOTOR_RES_EST = USER_MOTOR_MAX_CURRNT * 0.5(it is really a high value), what will occur when motor still couldn't finish RsRecal correctly?
  • 0 in reply to chang lianqing
    Guru 12800 points

    chang lianqing said:
    1.what is the difference between enc_elec_angle and EST_getAngle_pu() result?

    The enc_elec_angle is the electrical angle produced by the encoder.  EST_getAngle_pu() will return the electrical angle estimated by FAST.

    chang lianqing said:
    2.i could find that elec_angle became 0 durning RSrecal , did EST_getAngle_pu() will also return 0?

    I don't think that EST_getAngle_pu() will return zero since it is the angle estimated by FAST.  What is even more critical is that after RsRecalc is completed if the motor hasn't moved the enc_elec_angle will still be reading 0, while EST_getAngle_pu() will be producing invalid angles since the motor isn't moving.

    chang lianqing said:
    3.when RSrecal finished, motor will spin to a fixed absolutly angle everytime,
    and my USER_MOTOR_NUM_POLE_PAIRS = 2,
    the "fixed absolutly angle" have two value(maybe 110° and 290°) .
    if the motor actually aligned to a zero degree electrical angle at these two point?

    During the RsRecal the motor should move to be aligned to an electrical angle of 0 degrees.  There will be a number of these locations equal to the number of pole pairs.  The absolute mechanical location will be dependent on the motor's internal windings.

    chang lianqing said:
    4.what decide motor spin how many angle durning RsRecal,
    EST_getAngle_pu() == 0 or elec_angle == 0, or other factor?

    The amount of rotation during RsRecal will be dependent on the rotor location relative to where the nearest electrical angle of 0 is.

    chang lianqing said:
    5.if my max_current_res_est is too low to drive the motor during RsRecal, the error will occur(i lock my motor by hand).
    so i assume that if the motor have a very huge load and i set USER_MOTOR_RES_EST = USER_MOTOR_MAX_CURRNT * 0.5(it is really a high value), what will occur when motor still couldn't finish RsRecal correctly?

    If the motor doesn't rotate to an electrical angle of 0, the electrical angle produced by your encoder will not be aligned with the motor and can cause a couple different failure cases.  It might have reduced torque capability or even spin the wrong direction and out of control.  

  • 0 in reply to Adam D. Reynolds
    Intellectual 770 points

    hello Adam,

    1. this is the variables screenshot when i start up motor,

    when i power up MCU, QPOSCNT = 120

    enc_elec_angle = 0.00366,  enc_zero_offset = 0

    and this is the value that RsRecal finished, the enc_elec_angle ≠ 0.

    but you said that "motor will rotate to an electrical angle of 0", but it really have more difference.

    and motor spin correctly with the result.

    2." If the motor doesn't rotate to an electrical angle of 0, the electrical angle produced by your encoder will not be aligned with the motor and can cause a couple different failure cases.  It might have reduced torque capability or even spin the wrong direction and out of control.  "

    i want to add some funtions to confirm whether the motor rotate to an electrical angle of 0 or not.

    if the encoder can't reach the correct angle(didn't rotate any angle, or rotate to elec_angle = 0.99, mainly 1.0), it should setup error flag and disable Flag_enableSys.

    How can I do it?

  • 0 in reply to Adam D. Reynolds
    Intellectual 770 points
    “If the motor doesn't rotate to an electrical angle of 0, the electrical angle produced by your encoder will not be aligned with the motor and can cause a couple different failure cases. It might have reduced torque capability or even spin the wrong direction and out of control. ”

    is there any error flag in motorware to indicate RsRecal occur some problem(something make motor couldn't rotate to electrical 0)
  • 0 in reply to ChrisClearman
    Intellectual 770 points

    1.Which signal or condition could be used to capture the encoder count while it is passes or arrives at electrical zero?

    2.How could I know that the rotor have aligned with the stator flux?

  • 0 in reply to chang lianqing
    Guru 12800 points

    chang lianqing said:

    and this is the value that RsRecal finished, the enc_elec_angle ≠ 0.

    but you said that "motor will rotate to an electrical angle of 0", but it really have more difference.

    and motor spin correctly with the result.

    Yes the enc_elec_angle is not perfectly equal to 0, but for all practical purposes the value you saw 0.002136 is approximately equal to 0.  I would bet that it moved one or two encoders ticks and this is why it isn't exactly 0.

    chang lianqing said:

    2." If the motor doesn't rotate to an electrical angle of 0, the electrical angle produced by your encoder will not be aligned with the motor and can cause a couple different failure cases.  It might have reduced torque capability or even spin the wrong direction and out of control.  "

    i want to add some funtions to confirm whether the motor rotate to an electrical angle of 0 or not.

    if the encoder can't reach the correct angle(didn't rotate any angle, or rotate to elec_angle = 0.99, mainly 1.0), it should setup error flag and disable Flag_enableSys.

    How can I do it?

    Without having some kind of absolute motor position knowledge it would be very difficult to know if the motor and encoder isn't aligned correctly.  

    chang lianqing said:
    is there any error flag in motorware to indicate RsRecal occur some problem(something make motor couldn't rotate to electrical 0)

    There isn't really any error flags to indicate if there is some problem with the RsRecal.  

    chang lianqing said:
    1.Which signal or condition could be used to capture the encoder count while it is passes or arrives at electrical zero?



    You can directly read the raw QEP position count value by using the interface functions found in the QEP block.  From this you can compare to the electrical angle from the ENC block and capture the QEP position count when the electrical angle is approximately zero.  

    chang lianqing said:
    2.How could I know that the rotor have aligned with the stator flux?

    There really isn't a way to have a flag that indicates that the motor is aligned to an angle of zero.  In the example project we assume that enough current will be applied along the d-axis that the motor will move into alignment.