• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 81 subscribers
  • Views 272 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.

C2000WARE-MOTORCONTROL-SDK: FAST estimator. Speed estimated wrong

Javier Vara
Expert 1585 points
Part Number: C2000WARE-MOTORCONTROL-SDK
Other Parts Discussed in Thread: TMS320F280049

Hello,

We have an inverter we have developed some time ago based on TMS320F280049 using the example projects initially but without sensorless control (using an external resolver and a resolver to encoder interface). The project now has evolved a lot so the original code doesn't look very much like the original one but the control core (park, clarke, svgen, etc.) is still very much the same. Now our customer requires the usage of sensorless control so I am trying to add this functionality by analysing the code in the example project is_06_torque_control_eabi and adding the necessary parts to our project.

I have reached a point where I can run the inverter/motor sensorless at low speeds, I have scoped the estimated angle and it looks good. However, I am having a problem with the estimated speed. The output of the FAST estimator is twice the value I am expecting. Coincidentally, the estimated flux value (I think this two problems are linked) is roughly half the value I am expecting too (It should be around 0.6VpHz). If I use the real motor flux value (0.6VpHz) then I can't run the motor/inverter. If I double the number of pole pairs of the motor, then I get the correct estimated speed but the flux is still half the value I am expecting. Under this configuration I can run up to full torque at low speeds (up to 600rpm or so) but the moment I start going a little bit higher than that the speed/angle goes all over the place and the inverter goes into fault.

Any ideas what might be happening?

Motor specs:

- 25 pole pair

- 450Arms

- 500 Vdc nominal

- Max speed of 1200rpm

- 2050 Nm max torque

- 220kW max power

- Rs = 0.013 Ohm

- Ld/Lq = 70uH

- Flux = 90mWb = 0.6VpHz

Inverter config:

- We are using 10kHz switching frequency (and control frequency)

- USER_MAX_VS_MAG_PU = 0.5774 (we use in-phase hall effect sensors so no current reconstruction needed)

- USER_VOLTAGE_FILTER_POLE_Hz = 530 Hz

  • 0
    TI__Guru** 110290 points

    You may try to run the lab03 and lab04 to verify your hardware board, and run the lab05 to identify the motor parameters for FAST estimator. Set the right pole pairs and hardware parameters according to the motor and hardware.

    You can check the frequency of the motor phase current by using the oscilloscope with a current scope, to see if the frequency is the same as the feedback/ estimated frequency of the motor.

  • 0 in reply to Yanming Luo
    Expert 1585 points

    Hi Yanming,

    It would be very difficult for me right now to be able to run any of the labs on my current controlboard as there are loads of things the microcontroller interfaces with that are required to be able to run the inverter (for example, SPI communications to another microcontroller, SPI comms to a resolver to encoder chip, CAN communications to interface with our testrig, a CPLD, etc.). This is the reason I had to take the other approach of copying over the estimator parts of the labs to my project.

    I am currently running the motor/inverter in a testrig against a dyno motor so I am sure the estimated speed doesn't match the real speed. Also, we have manufactured the motor so I am sure about the motor parameters as well, so identification shouldn't be necessary.

    Any ideas?

  • 0 in reply to Javier Vara
    Expert 1585 points

    I think I have found my problem. The controfrequency and estimator frequency set on the userParams structure was twice the real value (it was been passed as 20kHz instead of 10kHz). We changed this and now we are getting both good flux estimation as well as good speed estimation.