C2000WARE-MOTORCONTROL-SDK: Motor control issues at high current and speed

You might have a look at the link below to add the patch library (fluxHF_coff.lib or fluxHF_eabi.lib ) into the project for high speed.

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/921747/tms320f280049c-fast-estimator-questions

We are using SDK 3.2.0.0 which already includes the fluxHF settings. I think this was added back in 3.01.00.00.

We are using the following settings:

//! \brief Defines the scale factor for the flux estimation
//! the default value is 1.0f, change the value between 0.1f and 1.25f
//!
#define USER_EST_FLUX_HF_SF                 ((float32_t)(0.12f))


//! \brief Defines the scale factor for the frequency estimation
//! the default value is 1.0f, change the value between 0.5f and 1.5f
//!
#define USER_EST_FREQ_HF_SF                 ((float32_t)(1.0f))


//! \brief Defines the scale factor for the bemf estimation
//! the default value is 1.0f, change the value between 0.50f and 1.25f
//!
#define USER_EST_BEMF_HF_SF                 ((float32_t)(0.75f))

Mick McRobot said:

We have tried disabling the single current sensor current reconstruction to make sure it is not that causing issues.

What do you mean above? Did you try to run the motor at the same higher speed with a light load? So we try to know the issue is from the high speed or high speed with heavy load.

In svgen_current.h we removed cases where SVGENCURRENT_ONE_PHASE_MEASURABLE was active. The code is below. However, this problem exists even with the default code in svgen_current.h.

    //define compensation mode
    if(Va_avg > Vlimit)
    {

        obj->compMode = SVGENCURRENT_TWO_PHASE_MEASURABLE;
        obj->ignoreShunt = SVGENCURRENT_IGNORE_A;

        if(Vb_avg > Vc_avg)
        {
            obj->Vmid = SVGENCURRENT_VMID_B;
        }
        else
        {
            obj->Vmid = SVGENCURRENT_VMID_C;
        }

    }
    else
    {
        if(Vb_avg > Vlimit)
        {

            obj->compMode = SVGENCURRENT_TWO_PHASE_MEASURABLE;
            obj->ignoreShunt = SVGENCURRENT_IGNORE_B;

            if(Va_avg > Vc_avg)
            {
                obj->Vmid = SVGENCURRENT_VMID_A;
            }
            else
            {
                obj->Vmid = SVGENCURRENT_VMID_C;
            }

        }
        else if(Vc_avg > Vlimit)
        {
            obj->compMode = SVGENCURRENT_TWO_PHASE_MEASURABLE;
            obj->ignoreShunt = SVGENCURRENT_IGNORE_C;

            if(Va_avg > Vb_avg)
            {
                obj->Vmid = SVGENCURRENT_VMID_A;
            }
            else
            {
                obj->Vmid = SVGENCURRENT_VMID_B;
            }
        }
        else
        {
            obj->compMode = SVGENCURRENT_ALL_PHASE_MEASURABLE;
            obj->ignoreShunt = SVGENCURRENT_USE_ALL;
        }
    }

Yes, we have run the motor at high speed with light load with no problem.

Unfortunately we can not run at at low speed with high load since we are using a propeller to load it up so the load is directly proportional to the speed.

Seems like the issue is from the current sensing, please try below two steps to see what happens

1. Don't enable the over modulation to run the motor at high speed.

2. Enable the over modulation, but limit the USER_MAX_VS_MAG_PU is lower than (0.57f).

We have tried as you suggested and we found that the problem still happens even with Over Modulation turned off. I will include the captures of this for completeness.

OVM turned on and USER_MAX_VS_MAG_PU (0.56f):

OVM turned on and USER_MAX_VS_MAG_PU (0.5f):

OVM turned off:

Also to note with most of these with the same Iq reference the motor will run for a short amount of time (about 20 seconds and then fail) for example 20 seconds before the last captures this was taken at the same Iq. However, it still appears that there is something wrong with the currents not lining up and over time this problem just gets worse until it fails.

We also did some test with the same phase currents but lower speeds (we have a larger propeller) and the issues don't seem to show up.

Here are the plots with an Iq ref of 36A (Same as is failing on previous plots):

1. What's the peak to peak current at this state? Is the peak to peak current over than the maximum sampling value of the ADC?

2. Did you try to use the different Kp and Ki of the speed PI controller for low speed and high speed? And change the gains of the PI controller for torque current as well?

1. Before it messes up the peak to peak current is ~72A. We have a range of 132A. When it starts run away the current approaches 132A peak to peak. However if we stop it from running away this should not be a problem.
2. We have tries using different PI values for the torque controller. We are not using the speed controller at the moment and are just directly controlling the current. We have also tried to directly control the Vq value directly, bypassing the control loops and had the same results.

Do you have the Ls/Ld/Lq vs. Current curve of the motor? If the inductances change significantly with the current, the motor mathematics model will be not correct for motor control with FAST estimator. You have to change the motor parameters online for the FAST estimator to calculate the rotor angle correctly.

We do not have a curve for the motor. However, we have made our own mathematical curve for it. The curve has adjustable parameters that we are able to change. We have tried many values for the curve to try approximate any changes that do happen as the current increases without any noticeable improvements.

You have to get the current-inductance curve from the motor manufacturer. The FAST estimator of InstaSPIN-FOC is sensitive to the motor parameters (Rs, Ld and Lq).

We are going to work on getting these parameters, it may take a little while. We will follow up when this is done.