• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 3 answers
  • Subscribers 82 subscribers
  • Views 216 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.

TMS320F280049C: InstaFOC Servo Control

Alistair Kitchen
Prodigy 20 points
Part Number: TMS320F280049C
Other Parts Discussed in Thread: TMDXIDDK379D, C2000WARE

Hi,

I just need confirmation on the limitations of sensorless FOC control.

We are currently testing our prototype PMSM inverter (based on an Infineon driver) controlled by the TMS320F280049C Launchpad and the sensorless FOC example solutions from C2000 Motor Control SDK 4.00. An external PID controller closes the servo loop and controls the motor via a PWM signal to the Launchpad for torque control.

Everything seems to work well even at quite low speed, however for servo control I think  we will need to add a sensor (A/B/Z encoder -> QEP) for low/zero speed control.

Can you confirm that this is correct, and is it feasible for the InstaSPIN-MOTION sensored software to work with an external PID controller, i.e. for it to only use the encoder information for commutation and let the external controller handle the position/speed.

Any advice/examples would be greatly appreciated.

  • 0
    TI__Guru** 109810 points

    Yes, you can use the encoder based sensored-FOC for low speed, but the F280049C doesn't support InstaSPIN-Motion, you have to implement the other/your own motion/servo control algorithm on F280049C.

  • 0 in reply to Yanming Luo
    Prodigy 20 points

    Hi, and thanks for the response, getting back onto this project now after a short break.

    The motor is controlled by an external PID controller driving the motor with a torque signal (the F280049C reads a PWM signal using eCap) and getting feedback via the encoder.

    I have modified Lab 06 (Torque Control) to include a quadrature sensor based on the Servo Drive With CAN example. After the encoder is calibrated (index detected) the offset between the encoder electrical angle and the estimator electrical angle (EST_getAngle_est_rad()) is found. This offset is then used at very low speeds (0.3 - 0.4 rad/s) to calculate the phasor angle (angleFoc_rad) from the encoder position in the ISR. The encoder also updates the speed reference (motorVars.speed_Hz) in the main loop.

    This works, but the torque isn't consistent through the full rotation of the motor; in some segments the torque is good, in others it is very weak, even unable to maintain a stationary position. I suspect this is because the calculated offset isn't perfect.

    After that long explanation my question is - have I approached this the right way? I have based the approach on Section 18 of the InstaSPIN-FOC and InstaSPIN-MOTION manual, combined with the Servo Drive With CAN example, neither of which is ideal.

    Is there a newer/equivalent of Section 18 that references the current SDK, or better examples of Sensored FOC for the F280049C?

    Thanks,

    AK.

  • 0 in reply to Alistair Kitchen
    TI__Guru** 109810 points

    You don't need to implement the InstaSPIN-FOC that's sensorless based FOC for motor control if the motor has position encoder as you used. And the InstaSPIN-Motion doesn't support F28004x device.

    Yes, you can refer to the Servo Drive With CAN example. Or you may refer to the FCL example in motor control SDK as below.

    C:\ti\c2000\C2000Ware_MotorControl_SDK_<version>\solutions\tmdxiddk379d\f28004x\ccs

  • 0 in reply to Yanming Luo
    Prodigy 20 points

    Thanks, I'll refer to that project.

  • 0 in reply to Yanming Luo
    Prodigy 20 points

    Hi,

    I finally resolved the issue regarding low/zero speed control. The issue was that Lab 06 (which I used as a basis for the torque control) doesn't use the user Park_run() function that takes the phasor derived from angleFoc_rad, it uses the EST_getIdq_A() call which uses a Park function internal to the estimator.

    Updating angleFoc_rad from the encoder only affected the IPark transform, the Park transform always used the angle derived from the estimator, which is unreliable at low/zero speed.