TMS320F280025: Why FAST give wrong estimated speed at some specific operating points?

Hi,

A new information:

I have used EST_getFlux_Wb to check the real time Flux calculated by FAST.

When speed is correct, the flux in Wb is closed to 0.227 which is close to the value in user_motor1.h (considering flux_VpHz =Flux_Wb * MATH_TWO_PI). The value oscillate a bit.

When speed becomes incorrect, the value is around 0.19 and the value is totally fixed, no more update...

Regards.

I just try using FULL_LIB instead of SIMPLE_LIB and it seems that the issue disappear. I was thinking SIMPLE_LIB use only the minimum function but I was thinking that the different function which are in the different lib were exactly similar (same code). Is seems I'm wrong.

Can you please confirm? 

I want to use the smaller lib (code size) possible so it would be better for me to use SIMPLE_LIB. Based on the difference beeween those lib, can you help me to solve with simple_LIB?

Regards.

Hi Manu,

Yes, please use the "fast_full_lib", this is the library that has been verified with the universal motor lab example.

Thanks,

Jiaxin

Hi,

I'm not sure the final code size will fit the flash size if I used the fast_full_lib.

Also Simple_lib is used for example tidm_02010_dmpfc which is really similar.

The issue can come from the flux estimated value which is not allowed to reduce below a defined with simple_lib.

I have a look at those value, because it seems it is where min and max allowed flux are defined:

// *******************************************************************************************************
// BELOW IS RESERVED
float32_t freqNearZeroSpeedLimit_Hz; //!< 1. Defines the low speed limit for frequency estimation, Hz
float32_t directionPole_rps; //!< 2. Defines the pole location for the direction filter, rad/sec
float32_t directionPole_2_rps; //!< 3. Defines the second pole for the direction filter, rad/sec
float32_t fluxPole_rps; //!< 4. Defines the pole location for the flux estimation, rad/sec
float32_t RoverLPole_rps; //!< 5. Defines the pole location for the R/L estimation, rad/sec
float32_t estKappa; //!< 6. Defines the convergence factor for the estimator

float32_t flux_Wb; //!< 7. Defines the default flux value, Wb
float32_t flux_min_Wb; //!< 8. Defines the minimum flux value allowed, Wb
float32_t flux_max_Wb; //!< 9. Defines the maximum flux value allowed, Wb

float32_t oneOverFlux_min_sf; //!< 10. Defines the scale factor for the minimum 1/flux value allowed
float32_t oneOverFlux_max_sf; //!< 11. Defines the scale factor for the maximum 1/flux value allowed
float32_t Dir_fe_min_Hz; //!< 12. Defines the minimum electrical frequency to still use direction estimation, V/Hz
float32_t Dir_fe_max_Hz; //!< 13. Defines the maximum electrical frequency to still use direction estimation, V/Hz

// BELOW can be added user own varaibles
float32_t maxFrequency_Hz; //!< Defines the maximum frequency value,
//!< Hz
} USER_Params;

Result with full_lib:

result with simple_lib:

As you can see, there is a shift of the value starting from directionPole_2_rps which make the value to be wrong.

Hi Manu,

Manu36 said:

Other signal are corrects (current, angle,...), only the estimated speed is wrong.

Which variable did you read for estimated speed? Could you share a screenshot of the expressions when there is issue?

Manu36 said:

I'm not sure the final code size will fit the flash size if I used the fast_full_lib.

You can check the memory allocation under the view tab and compare with the space that FAST_SIMPLE_LIB takes.

Manu36 said:

I have a look at those value, because it seems it is where min and max allowed flux are defined:

I noticed for FAST_FULL_LIB, it also contains these limit definitions.

Thanks,

Jiaxin

Hi,

Jiaxin Teng said:

Which variable did you read for estimated speed? Could you share a screenshot of the expressions when there is issue?

I use this one : 

obj->speedEST_Hz = EST_getFm_lp_Hz(obj->estHandle);

I also try  EST_getFe_Hz and EST_getFm_Hz (to see if it can come from the low pass filter) but the issue is the same. See below some comparative screenshot:

At 1500RPM (no issue):

As you can see, speed = speedRef (a few speed oscillation but this is OK)=speed mesured by external speed mesurment system.

Flux between simple_lib and full_lib is similar.

At 3100RPM => flux weakening needed at low input voltage to reach the target speed:

No issue with FULL_LIB :

-speed=speedRef=speed mesured with external sensor.

-Flux is reduced regarding to test at 1500RPM due to field weakening, flux is continuously updated and the value change a little bit over time.

Issue with SIMPLE_LIB:

-real speed is higher than setpoint but estimated speed is lower so all the regulators push to increase even more the speed...

-Flux is stuck at 0.209 but real value should be lower 

Jiaxin Teng said:

You can check the memory allocation under the view tab and compare with the space that FAST_SIMPLE_LIB takes.

Yes, we already check the difference, It save about 8% of FLASHBANK0_CODE, considering the use of SIMPLE_LIB will help to use a different part number with half flash size (really important for us for cost reasons).

Jiaxin Teng said:

I noticed for FAST_FULL_LIB, it also contains these limit definitions.

Yes it also contains those limitation but if we consider the shift in the data, you can see that the limitation do not have any more the same value.

Hi Manu,

Thank you for the detailed explanation. I think your analysis is reasonable. Since the FAST library is not open-source, so it may not easy to make any improvements on that. Would it be possible for you to continue using the FAST_FULL_LIB?

Thanks,

Jiaxin

Hi,

Not sure FAST_FULL_LIB can be used, difficult to say because at this time, functionnal SW is not 100% written.

If the issue is due to the shift, perhaps adding some empty data in the structure can help but I cannot be sure without knowing how the data are read/written by the lib, I'm also afraid it can have some catastrophic results for my boards (destruction).

I can also try PMSM_LIB but I will not have time in the following days to do it.

Do you have on your side some feedback from the team which develop the libs?

Regards.

Hi Manu,

I have consulted the team who developed the libs, they recommend to use FAST_FULL_LIB for developing customized projects.

Thanks,

Jiaxin