• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 458 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.

LAUNCHXL-F280049C: SDK (FOC) State Changes

Genatco
Guru 55913 points
Part Number: LAUNCHXL-F280049C

It would seem SDK (FOC) state machine lacks any grace and is very rude to x49c hardware! There is no soft start (ramp_up) state machine rudely slams phase current entering EST_STATE_RS.

1. The problem is 2 fold as it requires excessive ADC channel input capacitance to counter measure instantaneous start period current spikes. 

2. Low pass filter excess of 2200pF is simply a crude counter measure that leads to (transient) hang time in the crest of current wave peaks. We add (0) capacitance in our other HV systems since 1nF loading is expected from external differential amplifier. Any attempt to add low pass filer capacitance changes the precision of the current amplifier and invites transient hang time to the party.  

That said why was there no ramp up wait time between EST_STATE_ROVERL and EST_STATE_RS? Might the crude methods of the few lead to the downfall of all at some point in this experiment?

Why is there no soft current startup between EST_STATE_CONSTSPEED and EST_STATE_RATEDFLUX_OL?

Can soft start (wait_time) be added begin EST_STATE_RS as to stop it from slamming CCMPS's DACS? Then a reasonable bypass filter value can be used rather than 2200pF. Also this missing wait time seems to cause major issues for the CMPSS DACA/B filters higher values being required to counter measure transient spikes that occur between state machine changes further into motor ID process. 

  • 0
    Guru 55913 points

    BTW: The only WA has been to increase USER_MOTOR_RES_EST_CURRENT_A  to a much higher value say 9.2A >10.2A between states R/L & RS. 

    Yet wait time between CONSTSPEED and OL state change into EST_STATE_RATEDFLUX always trips ePWM faults USER_MOTOR_FLUX_EXC_FREQ_Hz = 50Hz.

    Then counter measure USER_MOTOR_MAX_CURRENT_A  from 11.2A >12.25A and still almost always trips ePWM fault.

    SW can't just slam PWM duty cycle up to 50% at the beginning of these state tests and produce current spike!  

    Then set USER_MOTOR_RES_EST_CURRENT_A = 12.2A, USER_MOTOR_MAX_CURRENT_A = 13.2A, USER_MOTOR_FLUX_EXC_FREQ_Hz = 60Hz and SW enters EST_STATE_RATEDFLUX for short 2 seconds time and trips OC fault from very high current peaks 13.5A.

    The problem seems to be soft start is missing between state changes and PWM synchronization is easily lost without a very high duty cycle.  

  • 0 in reply to Genatco
    Guru 55913 points

    The state change machine code ignores the wait times set in (user.c) for each state. It seems to have a mind of it's own since the real time debug remains on rampup as the time wait never expired. Yet is05_motor_id.c has launched the next state change and SLAMS current up to peak.

    If we set below to 30 the next state (EST_STATE_RATEDFLUX) starts to run before estWaitTime[] has has expired. So one state ends up inside the next state change causing an over run of states.

    pUserParams->estWaitTime[EST_STATE_RAMPUP] =
(int32_t)((USER_MOTOR_FLUX_EXC_FREQ_Hz / USER_MAX_ACCEL_Hzps +
(float32_t)30.0) * USER_EST_FREQ_Hz);

    The trouble being the while loop below is not keeping synchronous with the mainISR() interrupts. 

            else        // No estimator error
        {
            motorVars.Id_target_A = EST_getIntValue_Id_A(estHandle);

            flagEstStateChanged = EST_updateState(estHandle,
                                                  motorVars.Id_target_A);
            /* Estimator current state changed */
            if(flagEstStateChanged == true)
            {

  • 0 in reply to Genatco
    Guru 55913 points

    Why does estWaitTime[n] cause state over run when EST_STATE_RAMPUP is >20. Yet <20 estWaitTime[EST_STATE_RAMPUP] and state over run is less noticeable but still occurs.

    It is becoming quite clear there are a few bugs in the SDK (FOC) state machine. And 2 interrupt counts did not help decimation times in the state machine estWaitTime[EST_NUMSTATES].

    Perhaps magic TI can give us clues as to why over run is occurring in the state machine?

  • 0 in reply to Genatco
    Guru 55913 points

    State RatedFlux is finally showing what happens to DC supply voltage along the buzz saw motor noise. Why does Rated Flux require >10A to keep the rotor from stalling (65Hz)? That mostly trips CMPSSx DCA/B faults at the very start Rated_OL/Flux wait times. Tripping current spike did not occur 20Hz speed and somehow BoosXL determined correct LC flux from a stalled rotor should not occur. Oddly the motor would accelerate Online after motor identified true. Yet does not accelerate Online at all after 20Hz with INA240A1 40mV/A current monitors, remains a baffling mystery!

     

      

     

  • 0 in reply to Genatco
    TI__Guru** 115440 points

    The state and running frequency will be set automatically during the identification process, you just need to define the identification variables in user.h based on the specs of the motor. You might set and tune these identification variables to keep the motor run smoothly when the Ls and Flux are identifying. Of course, you must ensure the current and voltage sensing signals are good for motor identification and running. If not, please run the lab is02/03/04 to verify your hardware board first.