• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 83 subscribers
  • Views 401 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28069M: Wrong estimator values

Asier Lamariano
Prodigy 40 points

Part Number: TMS320F28069M
Other Parts Discussed in Thread: CONTROLSUITE, MOTORWARE

Hi,

We are using sensorless Instaspin MOTION software on a custom board to control the speed of a BLDC motor, but we are not able to make it spin. As soon as we enter a speed command the motor starts to vibrate and barely spins. The readings of the estimator speed (EST_getSpeed_krpm) are nonsense, swithing positive and negative values randomly. 

We are not designing the software from scratch, we are using a previous sensored Instaspin MOTION project that works perfectly. The changes we have made are disable QEP modules and replace STPOSCONV functions with the FAST estimator ones.

For example, the speed in the sensored project was calculated as follows: _IQmpy(STPOSCONV_getVelocityFiltered(stObj->posConvHandle), _IQ(fSpeedKRPMPerPU))

And the sensorless speed is obtained like this: _IQmpy(EST_getSpeed_krpm(obj->estHandle), _IQ(fSpeedKRPMPerPU))

In both cases fSpeedKRPMPerPU = ((0.001 * 60.0 * gUserParams.iqFullScaleFreq_Hz) / gUserParams.motor_numPolePairs)

As the control was unsuccessful, I checked the estimator variables in the sensored project and compared them with the correct speed. What I found out is that the estimator measurements are incorrect (both EST_getSpeed_krpm and EST_getFm_pu), but besides that:

  • EST_getSpeed_krpm is suppose to be per unit, but it is not.
  • Both EST_getSpeed_krpm and EST_getFm_pu are giving an incorrect value with a factor of 1.4. I mean, if the correct value is 1.5 krpm, they are giving 1.07 kprm approximately.

Indeed, I applied the 1.4 factor correction and the results of the estimator values and the sensored values are almost the same (and correct). These are the variables used to check the problem.

gspeedKrpmPU = _IQmpy(EST_getSpeed_krpm(obj->estHandle), _IQ(1.4)); //Corrected
gspeedFmPU = EST_getFm_pu(obj->estHandle);
_iq pu_to_khz_sf = _IQ(gUserParams.iqFullScaleFreq_Hz/1000.0);
_iq khz_to_krpm_sf = _IQ(60.0/gUserParams.motor_numPolePairs);
_iq Mechanical_Freq_kHz = _IQmpy(gspeedFmPU,pu_to_khz_sf);
gspeedKrpmFm = _IQmpy(_IQmpy(Mechanical_Freq_kHz,khz_to_krpm_sf), _IQ(1.4)); //Corrected

So, my first question is, why EST_getSpeed_krpm is not per unit if the documentation says so (in fact, it is the actual speed)? I thought it may be a code bug, but the values are obtained directly from the estimator which is in ROM and we cannot access to it.

My second question is, why in both cases the error is 0.71 times the real value? Again, the data is obtained from functions in ROM, so I don't know what could be wrong.

All control parameters are taken from the sensored project, so they are tested and correct. 

Any idea on how to proceed with this? We could just multiply the estimator speed by 1.4, but this is not a real solution, and the rest of the estimator values could be also wrong.

Thank you in advance,

Best regards

  • 0
    TI__Intellectual 2910 points

    Hello Asier, Right motor parameters are needed for the estimator to work correctly. while we look into the reported issues, can you confirm if motor parameters were set right? 

  • 0 in reply to Navaneeth Narayanasamy
    Prodigy 40 points

    Hi Navaneeth,

    Yes, the motor parameters are correct since they are the same parameters we used in the sensored project. These parameters were set according to the Instaspin labs, and worked fine with the sensored software.

  • 0 in reply to Asier Lamariano
    TI__Intellectual 2910 points

    Hello Asier, Thank you for the confirmation. Quick follow up - does your SW is based on example from controlSUITE or from Motorware? if so which example.

  • 0 in reply to Navaneeth Narayanasamy
    Prodigy 40 points

    Hi Navaneeth,

    Yes, our project is based on Motorware's Lab 12b.

  • 0 in reply to Asier Lamariano
    TI__Guru** 117020 points

    You may try to run the lab02b and lab05c to identify the motor parameters and inertia again, and use the identified values to run the motor with sensorless InstaSPIN motion.

    And you may refer to lab05d or lab06a to run the motor with sensorless InstaSPIN motion. And make sure that the motor pole pairs is set correctly.

  • 0 in reply to Yanming Luo
    Prodigy 40 points

    Hi Yanming,

    As soon as I can i will identify the motor parameters again and compare with the defined values. It will take me a couple of days since I have not the hw here. Anyway, as I said, the motor is working fine with the sensored software, so I guess the parameters will be quite accurate.

    Regarding sensorless implementation, I used the lab05d to port the sensored to the sensorless software as you suggest, so we agree in this point. The number of poles is correct (4 pairs).

  • 0 in reply to Yanming Luo
    Prodigy 40 points

    Sorry for the delay. I finally ran the identification in our custom board since I couldn't access to the board we use to id motors. The results are not accurate, and the problem may be related with the problems we got with the project's estimator values. Next I share the datasheet values, the previous id values and the current id values.

    This is the motor datasheet:

    These are the previous id values:

    #define USER_MOTOR_Rs (0.188085973)
    #define USER_MOTOR_Ls_d (0.000188112)
    #define USER_MOTOR_Ls_q (USER_MOTOR_Ls_d)
    #define USER_MOTOR_RATED_FLUX (0.054863885)

    And these are the current id values:

    #define USER_MOTOR_Rs (0.0998572633)
    #define USER_MOTOR_Ls_d (7.1340458e-09)
    #define USER_MOTOR_Ls_q (USER_MOTOR_Ls_d)
    #define USER_MOTOR_RATED_FLUX (0.18651098)

    You can notice that the inductance has never been very accurate, but the performance of the motor was fine. The current id values, as you can see are completely wrong, and I think the reason may be something is interfering with the estimator (just a theory, but in both cases the problem is the values given by the estimator).  

    Please ask me more detailed information if needed.

  • 0 in reply to Yanming Luo
    Prodigy 40 points

    Hi Yanming, any ideas on this?

  • 0 in reply to Asier Lamariano
    Prodigy 40 points

    Is there anyone who could help? We don't need all estimator parameters since the control is made with hall sensors, but we need at least Iq, Id, Vq and Vd values to be correct in order to calculate battery and phase currents.