FAST states

Note if we pause lab5 prior to enabling it can be noted state RatedFlux (8) rather than state Idle (1). So it seems the states control is using the incorrect call to determine when to change states. Oddly state 8 defaults exactly what I have been posting about - StateRatedFluxOL wait times out it trips DC fault for good reason. 

1. There are a few changes in the main loop control on identification and running without using controller (CTRL) state in motorControlSDK, but the FAST estimator state machine in motorControlSDK is the same as it in motorWare.

2. As replied to the other thread you posted. The force angle flag will be not used in the identification process even though the flag is enabled, the estimator will enable/disable the force angle function according to the state. Set the userParams.flag_bypassMotorId to false before calling EST_setParams(estHandle, &userParams) that will enable the motor identification.

3. The answer as Q2.

As I have replied to many threads you posted, please make sure the current and voltage signals are sensing well on your own board and set the correct ADC scaling values in user.h according to the sampling circuit.

Please post your user.h and the specification of your motor as we have required many times, we might find a similar motor in our lab to verify if there are any similar questions as you mentioned. Since we have tested almost all of the motors listed in user.h, it seems like we didn't meet the problems as you posted.

Yanming Luo said:

The force angle flag will be not used in the identification process

Yet most the issue unexpected sudden current spike remains consistent with state count and PWM generation in each state. Obviously documentation is not consistent with design changes made to FAST estimator ROM module. Yet it seems state count during RUN is choking perhaps due to missing defines shown below. If this ID process choking can not be resolved there is no need to continue on this path as C2000 is obviously not the solution to use for motor control.

Yanming Luo said:

Please post your user.h and the specification of your motor

It is a custom SPM 36 pole motor >12KW depending on load conditions weighs 90 pounds +25lbs sprocket, is now removed. Odd to see >250Nm torque peaks watch window during ramp up to 60Hz. The SDK does not show the same ld/lq flux as FEM predicted with DELTA winding but not seem to matter as further explained. FAST must divide RS phase L-L / 3 (Delta/3) but assumes STAR winding (STAR/2)? Yesterday read FAST differs RS by stator winding type WYE or Delta but where to set stator type in user.h so SDK account for RS value difference? 

Yanming Luo said:

As I have replied to many threads you posted, please make sure the current and voltage signals are sensing well on your own board and set the correct ADC scaling values in user.h according to the sampling circuit.

Even bigger issue being SDK is not passing any user.h motor parameters via pointers top user.c into labs.h ->typdef USER_Params, userParams. Do see user.h USER values loaded via user.c pointers (pUserParams) but values get lost on pointer names on left side = sign. So USER_SetParams(&userParms) never instantiates lab.h values setupControlers() with start values of inductance, e.g. (motorVars.Ls_d_H or  motorVars.Ls_q_H) and loads odd value from who know where (0.9999999e-7)? That occurs (motorVars.flagEnableUserParams = true)  and explains why we can not use ID values added to user.h,  bypass motor ID and run motor again via ID settings that actually run motor 550Hz online. It only runs in current CCS debug session after ID completes never again. That is due to pointer names it seems being different do not get linked when controller is setup. If that indeed is occurring explains why sudden current spike state LC test begins. Perhaps the pointer parameters get setup later via FAST but that is not so obvious and does not explain later CCS debug session motor runs fail.

Note the timer count may be overflowing compounding issues to properly ID motors via FAST run motor ID. An instantaneous OC spike occurs state LC when the motor current user.h set typical but forced higher _IA/Hz speed LC test faults somewhere in the middle. Since smaller motors vibrating burning up with very low currents the SDK has inerrant SW issues. TI must check out what leads to them and why user parameters are being lost. Excessive motor vibration State Online seems due to state LC not producing correct motor inductance due to pointers not loading pUserParams. I don't see manifest where reported issues have been debugged in SDK 3.0 and this one below seems the ice breaker.

INT_LEAST32_MAX and INT_LEAST16_MAX  has not been defined does not exist that CCS can find or perhaps a symbol that must be added to project?

//! \brief     Increments the state counter
//! \param[in] handle  The controller (CTRL) handle
static inline void CTRL_incrCounter_state(CTRL_Handle handle)
{
  CTRL_Obj *obj = (CTRL_Obj *)handle;

  int_least32_t count = obj->counter_state;

  // increment the count
  count++;

  // limit to 0 to INT_LEAST32_MAX - 1
  if(count == INT_LEAST32_MAX)
    {
      count = 0;
    }

  // save the count value
  obj->counter_state = count;

  return;
} // end of CTRL_incrCounter_state() function

//! \brief     Increments the speed counter
//! \param[in] handle  The controller (CTRL) handle
static inline void CTRL_incrCounter_speed(CTRL_Handle handle)
{
  CTRL_Obj *obj = (CTRL_Obj *)handle;

  int_least16_t count = obj->counter_speed;

  // increment the count
  count++;

  // limit to 0 to INT_LEAST16_MAX - 1
  if(count == INT_LEAST16_MAX)
    {
      count = 0;
    }

  // save the count value
  obj->counter_speed = count;

  return;
} // end of CTRL_incrCounter_speed() function

pUserParms broken pointer links often occur do not produce an CCS compile error. Struct pointer values seem to get lost when evaluated.  

/* 
   According to footnotes in the 1999 C standard, "C++ implementations
   should define these macros only when __STDC_LIMIT_MACROS is defined
   before <stdint.h> is included." 
*/

Must add to project so state count is not over run, symbol __STDC_LIMIT_MACROS must be added:

Yanming Luo said:

2. As replied to the other thread you posted. The force angle flag will be not used in the identification process even though the flag is enabled, the estimator will enable/disable the force angle function according to the state.

That contradicts written text states it is required for low speed observer (<1Hz) of FAST, can be checked for minimum speed Hz yet FAST neglect slow speed observer remain enabled during high speed observer >1Hz. Again R/L trips FA disabled in below test any point enable while loop or mainINT() startup handler, R/L set 150Hz.

I added a minimum speed limit define (user.h) to control ForceAngle (FA) but FAST leave FA enabled after ramp up >1Hz without code snip added to startup handler. So FAST is not controlling FA as expect for zero speed limit but only when snip below check disabled FA during R/L 150Hz. How was that possible unless the state count is perhaps being over run?

So a minimum speed limit define is required to disable _IA drive current for zero PI speeds, put FAST back to low speed observer. Several forum posts question why PI zero speed heats motor and spin shaft by hand it start to roll under very high torque, believe was lab 6 motor control suite. The zero speed limit may be better to add below test or other code area so FA re-enabled any time zero speed occurs. 

//! \brief Defines the R/L excitation frequency, Hz
//!
USER_R_OVER_L_EXC_FREQ_Hz 150


//! \brief Defines the forced angle frequency, Hz
//!
#define USER_FORCE_ANGLE_FREQ_Hz            ((float32_t)(1.0))

//! \brief The estimated angle will be bypassed if the flux
//!        frequency falls below zero speed threshold, 1Hz
#define USER_ZEROSPEEDLIMIT       ((float32_t)(0.001 * USER_MAXIMUM_SCALE_FREQ_Hz))

mainISR(void)

{

  //~~~~~~~~~~~~~~~~ startup handler

            //
            // run the space vector generator (SVGEN) module
            //
            SVGEN_run(svgenHandle, &Vab_out_V, &(pwmData.Vabc_pu));

            /* Get the forced angle flag status */
            //EST_getFlag_enableForceAngle(estHandle);

            /* Check rotor speed >1Hz, disable ForceAngle */
            if((motorVars.speed_Hz > USER_FORCE_ANGLE_FREQ_Hz) &&
            		(motorVars.flagEnableForceAngle == true))
            {
               EST_setFlag_enableForceAngle(estHandle, false);
               //
               motorVars.flagEnableForceAngle = false;
            }

}

I don't think the above code you added is useful, actually, the EST_setFlag_enableForceAngle() function will be passed during the identification process even though the flag is set or not set. The force angle will be enabled and disabled automatically according to the state and running speed in the FAST estimator which has another internal flag to do this. 

Sorry, we can't repeat almost all of the problems you mentioned above if you didn't modify anything in the example project. Please provide more details about what changes did you do in the example lab if you still have further questions.