• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 225 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.

Original question:

TMS320F280049C: InstaSPIN Instability at High Speed - 280049C & DRV8353

TMS320F280049C: Instability and loss of proper speed control at and above dutyLimit transition

EE Guy
Intellectual 280 points
Part Number: TMS320F280049C
Other Parts Discussed in Thread: DRV8353,

I believe I'm seeing the same behavior mentioned in this post at certain combinations of higher speed and lower bus voltage.

TMS320F280049C: InstaSPIN Instability at High Speed - 280049C & DRV8353 - C2000 microcontrollers forum - C2000Tm︎ microcontrollers - TI E2E support forums

the following issues are observed.

1. Unstable current draw from the input DC power supply

2. Loss of proper speed control (ie the commanded and measured speed in Code Composer does not match measured shaft speed on the torque/speed sensor in our setup...could differ by 10s of rpms)

3. Occasional peak current faults when operating high output loads (high speed/high torque) on the motor even though the peak current limit is set to 1.5x the measured current limit.

4. USER_ISR_FREQ_Hz  shifts (we measure this by timing the ISR in firmware and capturing min/max/average, at lower speeds the frequency is constant, at higher speeds it jumps around)

Primary inputs that affect when and how severely items 1-4 occur

A. Bus Voltage (lower bus voltage results in lower speeds at which these issues begin and vice versa)

B. PWM Frequency (lower PWM frequency results in higher speeds at which these issues begin and vice versa)

Based on issues A and B, the observation of the behavior of the duty cycle on one of the PWM outputs on the processor, and the value of the parameter motorVars.Vs_V, we determined that this line of code directly affects the point at which issues 1-4 begin. And because the duty cycle is determined by bus voltage it makes sense why bus voltage and PWM frequency would affect the transition speed at which we see these issues.

float32_t dutyLimit = 0.5 - (2.0 * minWidth_usec * USER_PWM_FREQ_kHz * 0.001);

By changing this line of code to the following (ie setting the dutyLimit value to the max allowed - minWidth_usec, 0.5 - 0.02), it eliminates issues 1-4 and stable operation up to the speed that corresponds to the max allowed speed for a modulation index value of 0.5774 is achieved:

float32_t dutyLimit = 0.5 - (2.0 * minWidth_usec * 5 * 0.001);

QUESTION 1:

Why does PWM frequency result in a decrease in the dutyLimit value as it pertains to overmodulation?

QUESTION 2:

If I change the dutyLimit equation as proposed, what are the consequences for other aspects of the control algorithms?

QUESTION 3:

Is the FluxHF code file designed to improve the issues we are observing regardless of whether we have a low inductance motor? The two motors we are observing issues with have the following characteristics and we see the same issues 1-4 on both motors.

Motor 1: 0.0045 H, 0.433 VpHz

Motor 2: 0.00036 H, 1.188 VpHz

QUESTION 4:

What SDK version was the FluxHF file introduced as a bug fix?

Thanks for the help with this.

  • 0
    TI__Guru** 115480 points
    EE Guy said:
    Why does PWM frequency result in a decrease in the dutyLimit value as it pertains to overmodulation?

    What PWM frequency are you using? You should measure the PWM frequency by detecting the PWM output signals.

    EE Guy said:
    If I change the dutyLimit equation as proposed, what are the consequences for other aspects of the control algorithms?

    That's limit to the inverter board and current sensing circuit. Recommend the USER_MAX_VS_MAG_PU is limited to less than (0.57) if using the over modulation and current re-construction function.

    EE Guy said:
    What SDK version was the FluxHF file introduced as a bug fix?

    This is for running the low inductance low flux motor to high speed. The latest version after 3.03 should include this FluxHF file.

  • 0 in reply to Yanming Luo
    Intellectual 280 points

    I was missing an important word in question 1. Let me rephrase.

    QUESTION 1:

    Why does increasing PWM frequency, USER_PWM_FREQ_kHz, result in decreasing the dutyLimit value as it pertains to overmodulation? This relationship comes directly from an equation in SDK version 3.00.01.00 as shown here in blue text. As PWM frequency increases, the dutyLimit value decreases. The comment at the beginning of this code suggests this section has to do with over modulation. 

    // setup svgencurrent for over modulation function
    {
    float32_t minWidth_usec = 2.0; // set minimum pwm width to 2.0us
    uint16_t minWidth_counts = (uint16_t)(minWidth_usec * USER_SYSTEM_FREQ_MHz);

    // maximum output voltage duty: 0.5
    // convert the minimum pwm width to duty by divide Tpwm
    // Tpwm = 1/(USER_PWM_FREQ_kHz * 1000) = * (USER_PWM_FREQ_kHz * 0.001)
    // The minimum pwm width is the same in two zero vectors for svpwm
    float32_t dutyLimit = 0.5 - (2.0 * minWidth_usec * USER_PWM_FREQ_kHz * 0.001); 

    SVGENCURRENT_setMinWidth(svgencurrentHandle, minWidth_counts);
    SVGENCURRENT_setIgnoreShunt(svgencurrentHandle, SVGENCURRENT_USE_ALL);
    SVGENCURRENT_setMode(svgencurrentHandle, SVGENCURRENT_ALL_PHASE_MEASURABLE);
    SVGENCURRENT_setVlimit(svgencurrentHandle, dutyLimit);
    }

    Now that I have explained this better, can you provide a more appropriate answer for question 2. When I changed the equation in blue above to the equation in red below, issues 1-4 in my original post were fixed. In both cases (using red or blue code) I set USER_MAX_VS_MAG_PU to 0.5774.

    QUESTION 2:

    If I change the dutyLimit equation to this float32_t dutyLimit = 0.5 - (2.0 * minWidth_usec * 5 * 0.001), what are the consequences for other aspects of the control algorithms?

  • 0 in reply to EE Guy
    TI__Guru** 115480 points
    EE Guy said:
    float32_t dutyLimit = 0.5 - (2.0 * minWidth_usec * USER_PWM_FREQ_kHz * 0.001); 

    The maximum duty will decrease with the PWM frequency to ensure the minimum sample time as shown in "minWidth_counts".

    EE Guy said:
    If I change the dutyLimit equation to this float32_t dutyLimit = 0.5 - (2.0 * minWidth_usec * 5 * 0.001), what are the consequences for other aspects of the control algorithms?

    Not right. The dutyLimit is not a absolute time value, that's the modulation ratio.

  • 0 in reply to Yanming Luo
    Intellectual 280 points

    I did some tests and looked into the code in more detail and identified the problem. Your responses are accurate for the code as written assuming the use of the 8320 dev kit or any inverter stage hardware that uses low side current sensors.

    I am using the F280049C Launchpad, SDK 3.00.01.00 based code, and custom hardware that has phase current sensors (not low side sensors). I should have mentioned this in a previous post. The variables dutyLimit and minWidth_usec are used in SVGENCURRENT_RunIgnoreShunt and SVGENCURRENT_compPWMData in the labs code to determine when low side current sensor measurements are valid. Because I have inline phase current sensors, I do not want to implement this code. I assumed that setting these lines and other that set the use of all current sensors is all I had to do to choose the appropriate current measurement approach.

    SVGENCURRENT_setIgnoreShunt(svgencurrentHandle, SVGENCURRENT_USE_ALL);
    SVGENCURRENT_setMode(svgencurrentHandle, SVGENCURRENT_ALL_PHASE_MEASURABLE);

    After commenting out the lines below in the lab code that call these functions, issues 1-4 were resolved.

    SVGENCURRENT_compPWMData(svgencurrentHandle,&(pwmData.Vabc_pu), &pwmDataPrev);

    measurableShuntThisCycle = SVGENCURRENT_getMode(svgencurrentHandle);
    SVGENCURRENT_RunRegenCurrent(svgencurrentHandle,&adcData.I_A, &adcDataPrev);

    A couple things I took away from this are:

    1. Setting these values in the labs code does not ensure that the correct code function inside of svgen_current.h. This was not expected. 

    SVGENCURRENT_MeasureShunt_e measurableShuntThisCycle = SVGENCURRENT_ALL_PHASE_MEASURABLE;
    SVGENCURRENT_IgnoreShunt_e ignoreShuntNextCycle = SVGENCURRENT_USE_ALL;

    SVGENCURRENT_setIgnoreShunt(svgencurrentHandle, SVGENCURRENT_USE_ALL);
    SVGENCURRENT_setMode(svgencurrentHandle, SVGENCURRENT_ALL_PHASE_MEASURABLE); 

    2. The current decision algorithm in svgen_current.h can cause issues like the ones I observed for some configurations and I would expect that the higher the PWM frequency the more likely these issues are to occur because the dutyLimit value at which these decisions are made occurs sooner in the duty cycle which means more and more of the duty cycle has a current waveform that must be estimated instead of measured when using low side current sensing (covered in lab 8).