• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 5 answers
  • Subscribers 83 subscribers
  • Views 1190 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.

TMS320F28069: Motor alignment process with absolute encoder

j.seydoux
Intellectual 740 points
Part Number: TMS320F28069

Hello,

I'd like to double check the following process with you to ensure that we are aligning the motor the right way.

We are using an absolute encoder that returns an absolute position (multiturn count + single turn position) via SPI.

We are actually doing the following process:

  • At first power-up, the motor is aligned using Rs calibration.
  • During Rs calibration, the QEP position count is reset to 0 using the following code snippet (in the main ISR):
  if (EST_State_Rs == EST_getState(m_ctrlHandle->estHandle))
  {
    HAL_resetQepPosnCounts(m_halHandle);
  }
  • As soon as the Rs calibration is done, we set the actual position of the absolute encoder with the position of QEP POSCNT.
  • At this point, the motor is aligned and the absolute encoder is synchronized with the QEP.

After a power cycle (when the motor is already aligned):

  • The absolute encoder position is read.
  • The QEP POSCNT is set with the absolute encoder singleturn position.
  • At this point, the motor is aligned and FOC controller can be started.

Please note that we use a zero offset for the electrical angle equal to 0, this is why we reset the QEP during alignment.

Could you please confirm this process and give us proposals in case of not optimal?

Regards,
Johann

  • 0
    TI__Guru** 114050 points

    The QEP module is used for an incremental encoder as a motor position and speed sensor. It can't provide the absolute position of the motor rotor, so the controller needs to know exactly the rotor position before the motor is started.  Using the Rs calibration process to implement the alignment during the first motor start, the rotor is aligned to a known position (zero position), and then reset or set the QEP related registers after some stabilization periods. You might have a look at the following link as well.

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/616625

    For an absolute encoder, you might use the alignment process to calibrate the position offset too, but I don't think you need to reset/set the QEP registers if you don't connect the encoder to QEP module.

  • 0 in reply to Yanming Luo
    Intellectual 740 points

    I forgot to mention that our absolute encoder generates an ABZ signal that we use for position and speed control. We only read the absolute position of the encoder at startup via SPI, set the QEP with this value and then use the QEP for "online" position management. The reason why we do this is that we want to avoid SPI transactions while controlling the motor.

    So, by knowing that we use ABZ signal of the absolute encoder, does our alignment process described above make sense and is correct? Or is there any better way (or correct way if our solution is wrong) to do it?

    Regards,
    Johann

  • 0 in reply to j.seydoux
    TI__Guru** 114050 points

    You can still use the force alignment process as a typical incremental encoder if you don't care about the motor position during the inverter first power-up.

    Or you might get the rotor position data from the absolute encoder, and then convert and set the position data to the counter register of QEP. You have to write a function to do this by yourself since we don't have such a reference.

  • 0 in reply to Yanming Luo
    Intellectual 740 points

    Hello,

    The process we use now is the following (alignment is only done at the first system power-on):

    1. Read the position of the absolute encoder via SPI.
    2. Set the QPOSCNT of the QEP register to the value read in the absolute encoder (between 0..4095).
    3. Start the FOC controller and the velocity controller block:
      1. These blocks are based on the ABZ signals sent by the absolute encoder.

    Sometimes the motor goes to full-speed and cannot be stopped anymore by setting a speed setpoint to 0 (uncontrollable). We face this issue after startup.

    Do you have any idea about what could happen knowing that most of the time the system behaves as expected?

    To already answer potential questions on your side:

    • This uncontrolled full-speed issue can occur as soon as a speed different from 0 is set. In other words, it can occur at low speeds.
    • This issue also occurs sometimes when the ST Velocity controller is regulating in position with 0 speed setpoint.
    • There are no errors reported by the FOC controller nor the ST Velocity and ST Position Converter controllers.
    • The motor can only be stopped by disabling the FOC controller. A speed setpoint of 0 using function CTRL_setSpd_ref_krpm does not stop the motor which continues spinning at full-speed.
    • This issue was also seen after motor alignment. The current used during alignment (RES_EST_CURRENT) is already more than 10% of the motor rated current.
    • This issue occurs on different motors (we have 6 motors in our system / two different motor parameters / one C2000 per motor) and is thus not dependent on particular motors parameters. Motors parameters have been set using InstaSPIN identification process.
    • There is normally no ADC ISR overrun despite the fact that, sometimes, an ISR is delayed due to high-priority UART communication as shown below (PWM freq. = 18kHz, ISR execution = 6kHz, FOC controller execution = 6kHz, ST velocity + position controller execution = 1kHz) - GPIO set low at the beginning of the ISR and set high at the end of the ISR:

    We really need to figure out what is the origin of this strange behavior ASAP since the system cannot tolerate any "uncontrolled" motor movement.

    Regards,
    Johann

  • 0 in reply to j.seydoux
    TI__Guru** 114050 points

    It seems like the alignment and control process you used is right for motor running.

    Is it possible to disable the high-priority UART communication to see what happens? We want to know that the issue is from the control algorithm or form system control logic.

    Or you might optimize the codes in both motor control and UART communication, make sure all of these codes are running in RAM without branch calling functions in these two ISRs.

  • 0 in reply to Yanming Luo
    TI__Guru** 114050 points

    An updates? Just wanted to check in and see if there is any update from your side, I haven’t heard from you for about two weeks, so I’m assuming you were able to resolve your issue. Please let me know if you have any questions. We would like to close this thread if no any further questions. Thanks.

  • 0 in reply to Yanming Luo
    Intellectual 740 points

    I think you can close this post since I've created the following post to address the issue:

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/908293