LAUNCHXL-F280049C: RS impedance high ID current

Genatco said:

Also started to provision MCSDK for BSXL-DRV8320RS via x49c launch pad but there are many places (hal.c) and other files the projects active configuration touches. Like to keep 3 ADC's in MCSDK via x49c, is that possible without too much effort?

Do you mean that you want to migrate this example to a customer's board? You just need to change the hal.c, hal.h and user.h according to the hardware board.

Genatco said:

Are the RS impedance and RoverL_rps values linked to the design of the BSXL_DRV83xx chip gate driver switching characteristics?

No. It's related to the motor if the current and voltage sensing signals are correct on the hardware board.

Yanming Luo said:

Do you mean that you want to migrate this example to a customer's board?

No to migrate MCSDK for LauchXL-F280049c board to use 3 shunts via 3 ADC's. Again already added BXLS-DRV8320RS to active project properties and many || (define BXLS-DRV8323RS). Only use DRV8320 for motor ID confirmation of custom inverter since SDK LAB is05 has issues with custom inverter RS impedance being accurate.

Please answer if you can what SDK (user.h) #defines or motor ID controller variables can lead to very wrong RS impedance readings in custom inverters? Investigations so far seem to point to estimator state machine wait times (user.c) being the prime suspect!

Genatco said:

Secondly phase current jumps from USER_MOTOR_RES_EST_CURRENT = 0.35 to ADC 14 amps during first part of ramp up 60Hz and USER_MOTOR_IND_EST_CURRENT_A = -0.315.

Notes above post: Saturation current immediately jumps 0.4 up to 14.2 amps motor shake violently. Why IPARK cause current windup in motor ID is07? Are TI engineers aware windup can occur via IPARK and saturation current become unconstrained? Perhaps PLL or use of PPB (MCSDK) corrects windup aspect of IPARK, not mention in PDF? Why was PARK (phasor) used for motor ID is05 and IPARK for motor online in is07, not mentioned in PDF?

Note SDK is05 use PARK (phasor) for motor ID and is07 use IPARK for motor speed control. Must have something to do with RampUp current PWM duty cycle in is07 winds up. And adding is05 Park transform code for motor ID code into project is07, the controller does not come online. Whoever coded SDK4.0 labs did not keep consistent run time motor ID algorithms and did not disclose such in PDF text for developers to know. All aspects of motor ID process and hidden library flag states for FAST ROM or LSRAM libraries must be disclosed, a no brainer  

            //
            // run the estimator
            //
            EST_run(estHandle, &estInputData, &estOutputData);

            //
            // compute the sin/cos phasor
            //
            phasor.value[0] = cosf(estOutputData.angle_rad);
            phasor.value[1] = sinf(estOutputData.angle_rad);

            //
            // set motor ID phasor in the Park transform
            //
            PARK_setPhasor(parkHandle, &phasor);

            //
            // run the motor ID Park transform
            //
            PARK_run(parkHandle, &(estInputData.Iab_A),
                     (MATH_Vec2 *)&(Idq_in_A))

Yanming Luo said:

No. It's related to the motor if the current and voltage sensing signals are correct on the hardware board.

There is more to that as previous mention PARK (phasor) versus IPARK somehow impacts RampUp current in ID process. Good project coding would not switch duty cycle transforms and keep (main.c) code build the same all builds or Labs. Seemingly the same motor ID issues exist in MCSK and need to be checked to use either transform in the build, not both! At the very least elaborate why PARK versus INVPARK used for proprietary FAST library calls we have no way to see via CCS, even in Outline view.

The motor ID process and runtime motor drive need simple block diagrams showing Required Transforms each step motor ID process, not shown InstaSpin User guide SPRUHJ1I – JANUARY 2013 – REVISED OCTOBER 2021. 

Genatco said:

Please answer if you can what SDK (user.h) #defines or motor ID controller variables can lead to very wrong RS impedance readings in custom inverters?

What parameters did you change? Please provide the details about this.

The identification and running processes use the different flow. As replied to you before, you may refer to the Universal Motor Control Lab that can meet the requirements you want and saves your time on the development.

Yanming Luo said:

What parameters did you change? Please provide the details about this.

The parameters shown for RoverL-rps current gains are not correct as depicted SPRUHJ1I – JANUARY 2013 – REVISED OCTOBER 2021. The ID process can not have any KP/KI_Id current gains set tor Motor ID process, even during RoverL_rps. The text is only relative for Online motors, not motor ID. Highly ambiguous text is for Online motors or older Motorware Suite and stuck in the middle of flow charts showing motor ID process discussing (user.c) controller wait times. The only motor ID settings allowed (KP/KI_spd) shown CCS debug below, any values >0.0 (red box) cause high saturation current during RampUp.

Let me repeat, any KP/KI_Id  >0.0 cause rapid saturation current during (EST_Rs_State_RampUp), these two Online motor controller values must be cleared. The ROM estimator should clear these values as anyone would expect embedded ROM code to automate. The KP/KI_Id seemingly has no effect on RoverL_rps during motor ID since (KP/KI_Id=0.0 below red box) still produce RoverL_rps in low inductance motors. Perhaps by the phase current being injected at 200Hz in this case. The KP/K_Id values >0.0 adversely affect peak saturation current in a bad way when the motor inductance is not yet known. How has such a seemingly well-established motor ID method ROM estimator to find inductance gotten so little attention?

6.6.3 CTRL_State_OnLine and EST_State_RoverL

This state of the estimator is used to measure the electrical time constant of the stator circuit by dividing the measured resistance and inductance. The RoverL time constant is used by the controller object in order to set the current controller gains, KP and KI of both IQ and ID current controllers. If the motor identification is bypassed, parameters provided in user.h are used to set the current controller gains.  

Are you working on the TI EVM kit or your own board?

Are there any issues to run the example labs on the supported TI EVM kit?

Any changes you did in the example lab? What's the target if you want to change the example lab?

Yanming Luo said:

Are you working on the TI EVM kit or your own board?

Both

Yanming Luo said:

Are there any issues to run the example labs on the supported TI EVM kit?

Yes the code require CCS debug and is not transportable between project LABS, does not keep consistent syntax architectures! The LAB is05 is not following the PDF outline SPRUHJ1I – JANUARY 2013 – REVISED OCTOBER 2021 RoverL_rps, RSOhms are not correctly divided and Ki/Kp_spd, Ki/Kp_id are not being shown is CCS debug also deviates from PDF text disclosure of motor ID process. How does is05 spin motor, open loop or closed loop? Seeing is07 ISR asserts closed current control loop, may be why the Ki/Kp_spd Ki/Kp_Id parameters show up in CCS debug during motor ID and cause unconstrained saturation currents? Seemingly is05 is open loop, might explain why motors have difficult time in RS RampUp.

Yanming Luo said:

What's the target if you want to change the example lab?

LauchXL_F280049c with BXLS_DRB8320RS_RevA on booster header J5-J8 would be a good start to add MCSDK updates. Put the DAC board on J1-J4  has 6 PWM channels there too.

Apparently motor ID LAB is05 does not set trajectory via (Ki_spd or Kp_spd) though clearing KI/KP_Id values 0.0 (is07) and Rs RampUp current no longer saturates. Yet the rotor does not spin at all and has minimal hold torque since the saturation current is only 400 milliamps. Lab is05 method of using IA current to determine estimator state changes is highly subjective and seemingly Not the way to do a proper motor ID. That can be witnessed by the undocumented behavior of speed controller causing extremely high saturation current when PARK transform is not used to control PWM duty cycle is07. Instead PARK has been replaced by inline estimator call is07, a huge difference to say the least!  

  EST_getIdq_A(estHandle, (MATH_Vec2 *)(&(Idq_in_A)));

These is05 speed calls added to is07 after motor ID sets userParams.flagMotorIdentified = true does not set ki/kp_spd or ki/kp/id after motor ID state breaks and sets motorVars.trajState = EST_TRAJ_STATE_IDLE to end the ID process. CCS debug expressions are not being updated with the new values set in the code snip.

float32_t speed_min_Hz = -USER_MOTOR_FREQ_MAX_HZ;
float32_t speed_max_Hz = USER_MOTOR_FREQ_MAX_HZ;
float32_t speed_maxDelta_Hz = motorVars.speedRef_Hz / userParams.trajFreq_Hz;
// setup the spd trajectory
EST_setMinValue_spd_Hz(estHandle, speed_min_Hz);
EST_setMaxValue_spd_Hz(estHandle, speed_max_Hz);
EST_setMaxDelta_spd_Hz(estHandle, speed_maxDelta_Hz);

Edit 04/07/23: Below speed current control calls do's (est.h) do not seem to return a bool flag, they are to set the bool flag (true) in controller setup. So is05 never shows Kp/Ki_id/iq values in debug motor ID flag true. Note controller setup copied from is05 mainISR() cause immediate controller error when placed in is07 ISR with condition flags of course. A switch case ISR motor ID method changes estimator states in the ISR time context more precisely than the while loop does. Yet requires clearing Ki/Kp_spd Ki/Kp_Iq (0.0) in is07 or motor shakes violently during ID. The controller setup is not what anyone might expect to encounter odd issues in the SDK coding topology. The inline est.h return bool flags from both (do's) inside the controller setup function do not set Ki/Kp_Id/lq in CCS debug expressions window, remains 0.0 in is05.

EST_doCurrentCtrl(estHandle), EST_doSpeedCtrl(estHandle), are the bool flags: Why are Ki/Kp_ld/lq values not being set for is05 motor ID or are they but not showing up in debug expressions window? Obviously I'm trying to make the is05 project work correctly without debug issues, present in HID motor ID process via is07. Seemingly we should be able to do motor ID in closed double control current loop of is07. Mainly by reducing Ki/Kp_ld/lq similar to is05 Ki/Kp_ld/lq not showing up in debug expressions. Note the code snip below enables the current controller is05. Why are Kp/Ki_ld/lq values (0.0) during motor ID RoverL_rps, RS Rampup? Perahps need to add foot notes to explain FAST estimator Bool flags for motor ID deviates from flow charts & text shown InstaSpin user guide SPRUHJ1I – JANUARY 2013 – REVISED OCTOBER 2021?

//Seemingly enables (do) estimator functions in the inline setup function below.
// Do they actully retunr a bool state or set the bool state for the controllers actions?
           
//! \brief     Determines if current control should be performed during motor identification
//! \param[in] handle  The estimator (EST) handle
//! \return    A boolean value denoting whether (true) or not (false) to perform current control
extern bool     EST_doCurrentCtrl(EST_Handle handle);
extern bool cla_EST_doCurrentCtrl(EST_Handle handle);


//! \brief     Determines if speed control should be performed during motor identification
//! \param[in] handle  The estimator (EST) handle
//! \return    A boolean value denoting whether (true) or not (false) to perform speed control
extern bool     EST_doSpeedCtrl(EST_Handle handle);
extern bool cla_EST_doSpeedCtrl(EST_Handle handle);
           
           
            //
            // setup the controller
            //
            CTRL_setup(ctrlHandle,
                       estInputData.speed_ref_Hz,
                       estOutputData.fm_lp_rps * MATH_ONE_OVER_TWO_PI,
                       (MATH_Vec2 *)&(Idq_in_A),
                       (MATH_Vec2 *)&(Idq_ref_A),
                       &null,
                       EST_doSpeedCtrl(estHandle),
                       EST_doCurrentCtrl(estHandle),
                       false);

Note: MCSDK code is currently not compatible LaunchXL-F280049c or BXLS_DRV8320RS_RevA and requires major changes to make it work anywhere close to the SDK 4.01. MCSDK motor ID still requires elementary copy paste, not achieved via HID updates for multiple motors &userParams. Using #defines to express motor parameters is not a prudent way for production end build levels as all motors vary inductance and resistance, even the same model. The MCSDK includes CAN connection, though can a remote station make changes to (userParams.Ls_Hd/Hq) parameters by calling selecting motor ID update from a user-friendly menu? That seems the future of AI interfacing, let the genius of AI do the hard work in milliseconds. 

Genatco said:

These is05 speed calls added to is07 after motor ID sets userParams.flagMotorIdentified = true does not set ki/kp_spd or ki/kp/id after motor ID state breaks and sets motorVars.trajState = EST_TRAJ_STATE_IDLE to end the ID process. CCS debug expressions are not being updated with the new values set in the code snip.

Answer: Requires set enable controller state flag Online next motor run after motor ID, is07 or is05. Seems the controller state is never switched from idle to online. though Online state flag is checked (labs.h) updateControllers(). So the Kp/Ki_Id/Iq current controllers were never being updated called in while loop. Note the controller state machine code sometimes triggers the enumerated states expressions window view, often does nothing at all. Controller states box was omitted is05.asp, nobody is aware what the controller is doing in the background unless they load scrip is07.asp and run is05 firmware. 

Though it makes sense is07 speed mode would not simply enable the controller but also set the enumerated state flags. Yet the motor would run with controller state CCS debug showing CTRL_STATE_IDLE since the user Kp/Ki_Id/Iq were initiated on entry to main.c, never in the forever while loop is05. This issue was due to missing enumerated state flag also missing in most state changes of trajectory and estimator checks is05 and is07. Suggest all engineers to add these enumeration flags where missing. Might be good idea to check MCSDK for missing enumerated state flags. Verify Ki/Kp_ld/lq values show in the debug expressions window for motor ID RoverL_rps, RS Rampup per InstaSpin User guide SPRUHJ1I – JANUARY 2013 – REVISED OCTOBER 2021.

// enable the controller
CTRL_enable(ctrlHandle);
//
motorVars.ctrlState = CTRL_STATE_ONLINE;

 Lab is05 does not seem to follow Fig.41 path or the FAST block model PI Iq/Id source blocks are fictional. Below code snip added to is05 forever loop should update motorVars.Kp/Ki_Id/Iq debug Expressions view during motor ID process. Oddly we have no idea what PI block is05 is doing to set the current slope as to compare with motor ID via is07 using FAST via ROM Park.

How can we trouble shoot motor ID issues when the code is not working as expected? Added is05 PI control into is07 omitting ROM PARK and really like to have debug visual what PI blocks are doing is05 to set the motor ID current slopes. That topic is not being elaborated in PDF text, hence SDK is questionable as it was developed to be a foundation to build a functional system from. Then x25 arrives with MCSDK and better not have the same idiotic behavior as SDK not being able to set current slope in motor ID closed loops. Perhaps time to have a pow wow with all the little endians get motor ID code working in MCSDK upper build levels and upper project labs is6 to is13. Otherwise it's not very useful for on-the-fly updates as the weather changes so rapidly. Wait for me guys my EV computer has to do motor ID and requires firmware upload before I can come join the party .

        /* Configure controller current gains */
        if((userParams.flag_bypassMotorId == false) &&
                (motorVars.flagEnableOffsetCalc == false) &&
                (motorVars.flagRunIdentAndOnLine == true))
        {
            if(motorVars.flagSetupController == true)
            {
                //
                // update the controller fromn RoverL_rps check
                // set custom current and speed controllers gains
                //updateControllers();
                
                // update the Id controller
                PI_setGains(piHandle_Id, motorVars.Kp_Id, motorVars.Ki_Id);
                // update the Iq controller
                PI_setGains(piHandle_Iq, motorVars.Kp_Iq, motorVars.Ki_Iq);
                // update the speed controller
                PI_setGains(piHandle_spd, motorVars.Kp_spd, motorVars.Ki_spd);

            }
            else
            {
                //motorVars.flagMotorIdentified = true;
                motorVars.flagSetupController = true;

                // set up estimator conrollers
                setupControllers();

            }
        }
        /* Update Kp/Ki_id/iq current gains
         * derived via RoverL_rps motor ID */
        getControllers();

InstaSpin's Projects and Labs User Guide SDK LAB is07 states: 

As a reminder, the PI analysis that came up with these (Ki/Kp_spd) calculations is based on the series PI loop. InstaSPIN uses a series PI loop for the current controllers and a parallel PI loop for the speed controller. The speed PI gains have to be converted from the series form to the parallel form. Equation 12 and 13 shows the conversion. 

Why are all 3 calculations is07 using series PI loop when is07 is a speed controller (PI) project? It would make sense for is06 torque control to use series PI seemingly not is07 speed control. That is if the reminder statement is correctly worded.

Anyway patching is07 with PARK transform sniped code from is05 only toggles Idq_ref_A.value[1] a few times and motorVars.Ki/Kp_Id/Iq remain 0.0 during motor ID. Odder yet Idq_ref_A.value[0] remains 0.0 at all times even in is07 speed control running a motor only Idq_ref_A.value[1] has saturation current. Yet the code references Idq_ref_A.value[0] in all the calls related to idq_ref.

You can use any regulators for current and speed you want like serial or parallel PI controllers that is not dependent on the FAST estimator.

The Lab05 uses the PI controller from the ctrl and the park from FAST estimator. The lab07 can use the one as lab05 or use the external Park as the existing example.

Any issues you met when you used these examples? Yes, you can change the control flow as you want, these example labs just show how to use the FAST estimator.

Yanming Luo said:

The Lab05 uses the PI controller from the ctrl and the park from FAST estimator. The lab07 can use the one as lab05 or use the external Park as the existing example.

That Block diagram is not shown in (Fig.55) or any TI literature of SDK labs. Hence the issues mentioned arise as internal PARK is an obscure term we have no visual representation to work from. The motor ID method connects to INVPARK, so how and where does internal PARK connect to it INVPARK? 

Yanming Luo said:

he lab07 can use the one as lab05 or use the external Park as the existing example.

Yet it causes an immediate controller error when is05 ISR function is executed from within is07 main.c. I will PM you the new mixed ISR module, perhaps you can find why external PARK causes an controller error. It can be called from main.c set the bool flags to reflect motor ID rather than speed control, shown in the top snip of main.c.

It's not an issue, please refer to the example lab. If you want to use a single project for both identification and running, please refer to and use the Universal Motor Control Lab as mentioned before.

Yanming Luo said:

It's not an issue, please refer to the example lab. If you want to use a single project for both identification and running, please refer to and use the Universal Motor Control Lab as mentioned before.

Please try to stay focused on the thread issues, documentation is critical for SDK speed control is07 using internal ROM PARK. Again where is internal PARK being illustrated as having any connections to INVPARK any TI document????

More-over PI control block is not being set in is05, you should know that! The PI control setting is07 min/max seemingly is causing ID issues and is counter intuitive, does not follow Fig.41 verbatim. Hence the code snips below prove such is vital as we want to use the PI control block in both is05 and is07 also shown SPRUHJ1I – JANUARY 2013 – REVISED OCTOBER 2021. It illustrates we need to ser RoverL_rps and RS online to use Ki/Kp_ld/lq values as being the correct way F280049c MCU class for ROM embedded motor ID functions. The SDK example code is not strictly by the book! Note below states fast RTS function but it is simple C lib call to find square root.

Yet it sets the min/max for Nominal Bus Voltage 24v was (9.3nnn paused mouse hover) though I don't know how Vdq relates to USER_MOTOR_RES_EST_CURRENT_A or USER_MOTOR_IND_EST_CURRENT_A in any illustration motor ID. The MCSDK baseline for motor ID process is in no way seamless, requires build levels. And Fig.55 above shows we simply flip a bool switch after adding very few parameters in any test LAB. Are you are saying that has been fixed MCSDK without specific level too ID or run motor in same build but still require copy paste of 4 motor parameters?

Please explain why PI control block is being left of out of is05 motor ID process, presumably MCSDK as well? The MCSDK was written to support NON embedded FAST estimator LSRAM library, seemingly for x25 MCU class.

You might say TI also try to make SDK work with fast_full_lib.lib via x49c and produces hundreds of Symbols missing and not defined errors during compile, it's futile to even try that for x49c MCU class!

// calculate Iq controller limits, and run Iq controller using fast RTS
// function, callable assembly
// using the Nominal Busvoltage
outMax_V = sqrt((userParams.maxVsMag_V * userParams.maxVsMag_V) -
(Vdq_out_V.value[0] * Vdq_out_V.value[0]));

PI_setMinMax(piHandle_Iq, -outMax_V, outMax_V);

Yanming Luo said:

please refer to and use the Universal Motor Control Lab as mentioned before.

The MCSDK code supporting so many MCU classes highlight code covers in every C module is mind boggling. can you guarantee it will not have the same motor ID issues as SDK. I already show you places MCSDK suffers the same limited userParams LS_ld/lq and requires build levels user to copy paste too make it even work. How can MCSDK be so great it suffers the same issues to update motor parameters, easy answer it's not dependable in any way to build an industrial motor control system without complete tear down costing millions of dollars no startup has or wants to spend.

Seems TI after Covid has catered more toward the learning community and lost desire to sell more than few hundred C2000 MCU's. It's very noticeable in all forums, TI has lost a huge fowling over the last two years. Seemingly that is related to all the Space Vector control issues and code examples being unreliable for practical use in products. I have tried to show there are better ways to improve the motor ID process so it's more Seamless into run time without copy paste or CCS debug.

Remarkably MCSDK project strived to add more safety motor alerts and better ESMO enhanced slow speed observer with PPB control of ADC samples, 

If you want to run the motor identification with the InstaSPIN labs on F28004x, you have to use the lab05 since the identification needs the "ctrl" object and the related functions. And you can use the lab05 to run the motor as lab07 after that.

All of the InstaSPIN labs in motorWare and Motor Control SDK use the same PI controllers for current and speed, you can refer to the descriptions in the InstaSPIN User's Guide.

That's why the Universal lab is recommended to you, this lab can meet most of the requirements you want, you may take look at it.

A software FAST library can support  all of the C2000 devices with FPU includes F28004x for InstaSPIN. You may refer to the lab for the newer C2000 device in motor control SDK. The universal motor control lab is available in the current MCSDK, which can support a set of hardware kits and control algorithms for BLDC/PMSM drive. The kits include LAUNCHXL-F280025C, LAUNCHXL-F280039C,  LAUNCHXL-F2800137 with BOOSTXL-DRV8323RS, BOOSTXL-DRV8323RH, DRV8353Rx-EVM,  BOOSTXL-3PHGANINV, DRV8316REVM, or  DRV8329AEVM inverter board for low voltage motor (max: 100Vdc) . TMDSCNCD280025C, TMDSCNCD2800137 , or TMDSCNCD280039C with TMDSHVMTRINSPIN inverter board and TMDSADAP180TO100 for high voltage motor (max 350Vdc). And The control algorithms include sensorless InstaSPIN-FOC with FAST, Sensorless-FOC with eSMO, Sensored-FOC with incremental encoder, Sensored-FOC with hall sensor.

C2000WARE-MOTORCONTROL-SDK: https://www.ti.com/tool/C2000WARE-MOTORCONTROL-SDK

Universal Project and Lab User’s Guide: https://www.ti.com/lit/spruj26

Example lab project at the folder: C:\ti\c2000\C2000Ware_MotorControl_SDK_<version>\solutions\universal_motorcontrol_lab\f28002x

or                                                         C:\ti\c2000\C2000Ware_MotorControl_SDK_<version>\solutions\universal_motorcontrol_lab\f28003x

or                                                         C:\ti\c2000\C2000Ware_MotorControl_SDK_<version>\solutions\universal_motorcontrol_lab\f280013x

Yanming Luo said:

If you want to run the motor identification with the InstaSPIN labs on F28004x, you have to use the lab05 since the identification needs the "ctrl" object and the related functions. And you can use the lab05 to run the motor as lab07 after that.

Umm LAB is07 uses the control object (ctrl.c/labs.c/h) to regulate PI speed controls (Ki/Kp_Id/Iq or Ki/Kp_spd). The controller should not go into error condition, when is05 ISR code is added into is07 ISR and asserted at different times. The Instaspin troubleshooting text does not cover the error condition I'm reporting. Odd thing is RS impedance closed loop motor ID via is07 ISR code produces accurate results but rampUp pushes torque mode A_Iq min/max no matter we subsitute PI_setMinMax(piHandle_Iq, -outMax_V, outMax_V) to use USER_MOTOR_RES_EST_CURRENT_A versus Nominal BusVoltage AKA (userParams.maxVsMag_V).

The SDK project LAB user guide states first part of is05 motor ID open loop but fails to elaborate what exactly it means or why must be open loop?

The controller error rapidly occurs during RoverL_rps as LAB is07 ISR asserts is05 ISR function. PM code snips should prove that something is simply wrong with the approach TI engineered as separate examples are useless for real-world machines. Perhaps a dual core MCU could have two main.c, make is05 and is07 coexist in the same code space in memory but that is simply nutty processor idea. Please ask TI to create a proper flow chart of the modules required to invoke and assert motor ID in ROM code and new FAST library. Namely what the current controller is doing related to the FAST estimator and state machines wait times in motor ID process (ctrl.c/labs.c/h ) , not presently documented.

Nobody can make SDK motor ID seemlessly work with any other LAB other than TI engineer who brain-stormed it as separate object code. That is not a logical approach at all, hence I'm here asking the same question many times in different ways not getting a logical answer. 

Please try to get the PM code to work using is07 main.c with is05 motor ID process ISR code without causing a controller error. Perhaps we can share the code on the forum once it is working without causing a current controller error during RoverL_rps.

Yanming Luo said:

Recommend that you can use the Universal Motor Lab that only uses a single project for both identification and running.

Motor identification is hidden not easy to find among DmcBuildLevel4 (enabled) and some #if defined ESMO parts are not being unhighlighted.  Spent better part of hour reviewing this structure and still could not find (motorVars.flagMotorIdentified) or the C code module to do that.

Yanming Luo said:

As replied to you, if you want to run and identify the motor, you may use the lab05 as an example to add the other features you want

That was not my question to begin with. Seemingly the issue of controller error with PARK after RoverL_rps is due to a typo mentioned few years ago was never corrected. The words Recalibration and Recalculation are being mixed up in the InstaSpin PDF and the LABS text does not elaborate how motor ID sets open loop. Yet the PI control is being set to limit rated motor current in both is07 & is05. One difference, is07 never enables RsRecalculation and seemingly bypasses Iq current control Fig.5-1 above post or is part of it but not illustrated as such.

The existing LAB figures are inadequate to explain requirements needed (transforms or estimator functions) to do motor ID. A simple illustration would clear up the typo shown below since is05 Motor ID enables RsRecalculation() and never enables RsRecalibration() as stated in SPRUHJ1I – JANUARY 2013 – REVISED OCTOBER 2021. So is07 starts out in double closed loop otherwise still sets PI control (Ki/Kp_Id/Iq) as does is05. The primary difference is RsRecalculation() must somehow bypass Iq controller. Hence the Iq current controller is somehow mangled and throws error exception. 

Page 57 InstaSPIN Projects and Labs User’s Guide:  USER_MOTOR_RES_EST_CURRENT  The motor will have to initially be started in open loop during identification. This value sets the peak of the current used during initial startup of the motor. If the motor has high cogging torque or some kind of load, increase this current value until the motor will start spinning. After motor identification, this value is never used.

SPRUHJ1I – JANUARY 2013 – REVISED OCTOBER 2021 

6.6.4 CTRL_State_OnLine and EST_State_Rs: Once the coarse process has finished, the fine Rs recalibration starts. The time taken by the identification process to complete the fine Rs recalibration is set by default to 4 seconds, and again the user has flexibility to
change this by modifying the value stored in RsWaitTime [EST_Rs_State_Fine].

This flag text should state (RsRecalibration) perhaps sets the wrong flag (reCalculaiton), should set flag reCalibration? And the Rs reCalculaltion flag set is asserted online. Otherwise make no sense when controller is ONLINE during RoverL_rps into Rs Recalibration then the ReCalibration (fine) state never shows in CCS debug expressions window. Hence the control State machine has never shown the correct status via is05 as controller state remained IDLE during motor ID.

//! \brief     Sets the enable stator resistance (Rs) re-calculation flag in the estimator

/* Rs ReCalibration flag state (Offline motor still)
* runs motor open loop up to set trajectory Hz */
EST_setFlag_enableRsRecalc(estHandle, false);

Sorry for the Universal Lab is so complex with supporting multiple control algorithm. You can try to search "flagEnableMotorIdentify" for identification.

The bigger problem with trying to follow SDK/MCSDK examples being naming conventions shown in Fig.55 above (FAST estimator) are not consistently being followed verbatim relative to PI control and current controller blocks. The other issue with the entire SVM project model is the ROM/FAST libraries do not have a supporting block diagram for the trajectory generator. So est.h calls to internal FAST blocks do not make it any easier to configure the code especially around Motor ID process. So far I see the similar issues with MCSDK, needs to be more transparent with named labels (inputs/outputs) of all SVM control blocks asserted in C code.

The SDK controller error is07 due to inline calls return bool flags, when forced state the motor ID controller runs without error via is07. The odd part is the trajectory generator state changes relative to (Id_target_A) current is05 (not in is07) and motor does not spin during RampUp. Below call there is no documentation of what the two inline (do Speed/Current) calls are required for motor ID process. The Id_target_A is used in RsOnline per notes but does not give any details how that current changes indicate window to update the trajectory generator.

Does Id_target_A revolve 60° inside the frame (Ls_dH/Ls_qH) as PI block/s Kp/Ki_Id/Iq cycles for control block inputs? Or can we instead use FAST Irated theta to replace the Id_ref input data and to sense the window as to update trajectory generator? 

Why are two inline FAST estimator do in below calls and why are they required to assert the motor ID process? Was that madness changed in MCSDK?

//
// setup the controller
//
CTRL_setup(ctrlHandle,
estInputData.speed_ref_Hz,
estOutputData.fm_lp_rps * MATH_ONE_OVER_TWO_PI,
(MATH_Vec2 *)&(Idq_in_A),
(MATH_Vec2 *)&(Idq_ref_A),
&null,
EST_doSpeedCtrl(estHandle), //true
EST_doCurrentCtrl(estHandle), //false
false);

Yanming Luo said:

flagEnableMotorIdentify

CCS search tool cannot find this flag in motor1_drive.c/h, motor_common.c/h, sys_main.c/h userParams.h , user_mtr1.h files. Where is the motor ID code located? Not the bool flag set in expressions window rather the C module that executes motor ID?

Also driverlib,h is missing MCSDK src_driver folder and there are missing driver includes. The CCS project installer produced MCSDK links/folders below SDK4.0 installation, the driverlib files are above MCSDK, seemingly should have installed imported project above SDK4.0.

Yanming,

MCSDK is not improving the motor ID process is not a dynamic FAST control feature.  Perhaps safra GUI can aid to copy motor parameters without project rebuild? My code scheme SDK is07 incorporates is05 to produce dynamic motor ID update of 4 user.h as variables, not #defines. Hence no compilation is required after motor ID runs as parameters are stored to LSRAM, later to Flash sector if user desired. How has that been so easy to achieve via ARM Cortex MCU class yet so difficult for C2000? Recompile of C code seems so juvenile 

6. Set the variable motorVars_M1.flagEnableRunAndIdentify to' 1 in the Expressions window as shown in Figure 2-41, the motor identification will be executed, the whole process will take about 150s. Once motorVars_M1.flagEnableRunAndIdentify is equal to 0 and the motor is stopping, the motor parameters have been identified. Copy the variables value in the watch window to replace the defined motor parameters in user_mtr1.h as follows:
• USER_MOTOR1_Rs_Ohm = motorSetVars_M1.Rs_Ohm’s value
• USER_MOTOR1_Ls_d_H = motorSetVars_M1.Ls_d_H’s value
• USER_MOTOR1_Ls_q_H = motorSetVars_M1.Ls_q_H’s value
• USER_MOTOR1_RATED_FLUX_VpHz = motorSetVars_M1.flux_VpHz’s value
7. Set userParams_M1.flag_bypassMotorId value to 'true' to disable identification after successfully identify the motors parameters, rebuild the project and load the code into the controller.

Yanming Luo said:

There are two methods for motor identification in Universal Lab. One just needs to change the "flagEnableMotorIdentify" to indietify a motor and can save the identified motor parameters without re-building the projec

Can it run the identified motor without copy paste CCS debug 4 values, seemingly not. That is where motor ID structure breaks down as a human must be present an manipulate the code simulate an HOT online motor ID process.

The problem with is05 motor ID is mainISR code is not part of the ID process. Since the controller state was not set online the main function code does not execute during motor ID and the est.h two bool do flags (above snip) are meaningless. The is05 Id D axis injection current is asserting in the forever loop and mainISR code is mainly for runtime testing when all 3 states go Online and (motorVars.flagMotorIdentified=true) copy paste 4 debug values to user.h. That is not being explained User guide flow chart Fig.41 above misleads shows global updates with no bypass block of the mainISR primary runtime function depicted.

LAB is05 shows the controller state (Online) but it is actually (Idle) during motor ID forever loop for SPM motors. Fig.41 shows Online for ACIM locked rotor and mainISR logic flow falls through, SPM remains in forever loop until identification completes but for global updates asserting. So mainISR is still asserting SOC interrupts but it does not execute the main function until the controller is online. That is the big got you in the is05 mainISR code. Nobody being aware as is05_debug.asp omits enumerated controller states.

Seemingly why current controller posts an error exception when is05 mainISR code is copied into is07 speed control, the motor does not spin for RampUp when Ki/Kp_Id/Iq values are set to MAX during motor ID process torque builds up. Code changes can flag the areas of speed PI equation and insert user.h motor ID Min/Max values. The snip below shows where the forever loop is incorrectly setting trajectory Id saturation current for motor ID, should have user.h motor ID EST/IND values used in forever loop. The saturation current can be updated after Identification is run. 

I can't seem to find in MCSDK hidden motor ID functions seemingly embedded into fast.lib triggered by a single state flag.  

//
// configure the fwc reference trajectory
//
TRAJ_setTargetValue(trajHandle_fwc, 0.0);
TRAJ_setIntValue(trajHandle_fwc, 0.0);
TRAJ_setMinValue(trajHandle_fwc, -USER_MOTOR_MAX_CURRENT_A);
TRAJ_setMaxValue(trajHandle_fwc, USER_MOTOR_MAX_CURRENT_A);
TRAJ_setMaxDelta(trajHandle_fwc,
(USER_MOTOR_RES_EST_CURRENT_A / USER_ISR_FREQ_Hz));  

Yanming Luo said:

Yes, don't need to copy and paste the values If you are using the Universal Motor Control Lab

It seems to say such in user guide though the wording is a bit obscure.

8. The example can support online identify the motor without reloading the code as the following steps.

9. Once complete motor parameters identification or set the correct the motor parameters in user_mtr1.h file.

Yanming Luo said:

many save you a few time to integrate lab05 and lab07.

I gave up on integrating since is05 into is07. Oddly is05 seems to be a work around for ROM estimator is not producing motorVars.speed_Hz during motor ID ramp up. When is07 PI control is used with Ki/Kp_Id/Iq values and D axis injection current ramps down the motor suddenly stops spinning, entering state Ls. So idq_A[1] = min/max of Dc_BusVolts / 3, that reduces rampup current and PI injection current into D axis.

Why motorVars.speed_Hz = EST_getFm_lp_Hz(estHandle) returns 0 hertz during motor ID? Perhaps undocumented ROM bug? Yet the motor is spinning 50Hz set by USER_MOTOR_FLUX_EXC_FREQ_Hz = 50 during RampUp.

The default ramp down time /3 is far to short, acts like OL_flux has lock rotor even bypass lock rotor flag is set true. Again these are very low currents 250-320mA min/max PI values. The motor is very touchy rated 1.3A - 18W, SVM never consumes the same current it was seemingly rated for BLDC trapezoidal.

6.6.6.1 Current Ramp-Down
The first thing that happens when identifying the flux is for a closed-loop to be enabled internally by the motor identification state machine. This closed-loop is not enabled by the user. Current consumption lowers to a minimum current value needed to keep the mechanical load spinning at the same frequency when this closed-loop is enabled. The slope at which current is lowered is a fixed value, Rs estimation per second divided by 3. The dividing factor of 3 was selected during design of the motor identification process to provide a slower slope.

Yanming,

LAB is05 LS state produces very low values of motor inductance via custom DC inverter. Oddly more exact LS executing motor ID via is07 with ISR switch case following enumerated control states. Noteworthy LAB is05 uses Vdq_out_V to RampUp PI speed via same Kp/Ki_Id/Iq, not controlled by trajectory generator as is07 speed control saturation current (Iq). Why is saturation current (Iq) not being controlled during motor ID via LAB is05? Seemingly that is why small motors can easily burn the windings. Has this issue been corrected in MCSDK?

LAB is05 controller states appear to update ROM via an undocumented address vector (CTRL_run / CTRL_setup). Seemingly engineers will never be able to comprehend what that is doing since Fig.41 flow chart omits a block to show speed and current address vectors via main_ISR interrupts.

Oddly LAB is05 injection current into D axis occurs via idq_ref_A.value[0] monitored debug. Yet is07 main_ISR uses idq_ref_A.value[1] for PI speed control trajectory state updates. That is a double standard not being explained in any text. Again no answer why is05 Ki/Kp_Id/Iq are not being updated in expressions window when the call below is asserted main_ISR. Hence another confusing standard exists in motor ID process via inline bool flags (do) to control speed and current that cause controller error after importing is05 code into is07 main_ISR. Regarding the PM code - why does the forever loop of is07 cause an unexpected controller error of is05 imported code trajectory changes via forever loop seemingly to switch EST states? Has MCSDK changed the method of motor ID away from vector address shown below? 

The is07 forever loop and PI controlled (Ki/Kp_Id/Iq) state changes and LS_Id_H/Iq_H are more accurate via custom inverter than is05 has ever produce. The motor ID flag true runs in is07 via the calls below to reduce (Idq) current and seems to be in the wrong PI block, should be high PI? Again Fig.55 above uses different nomenclature than is07 code odd variable names not depicted. Seems someone cut and paste existing figure never updated to reflect code changes. 

Add to debug expressions is05 to see Vdq_out_V and note Idq_ref_A.value[1] holds the (Idq) data, not value[0].

// Maximum voltage output
userParams.maxVsMag_V = userParams.maxVsMag_pu * adcData.dcBus_V;

/* Motor ID Min/Max PI output */
if(motorVars.flagMotorIdentified == false)
{
   userParams.maxVsMag_V = userParams.maxVsMag_pu * (adcData.dcBus_V / 3);
}
PI_setMinMax(piHandle_Id, (-userParams.maxVsMag_V), userParams.maxVsMag_V);

// run the Id controller
// Low Pi block Vdq_out-0 returns -5Vq into InvPark
PI_run_series(piHandle_Id,
Idq_ref_A.value[0] + Idq_offset_A.value[0],
Idq_in_A.value[0],
0.0,
&(Vdq_out_V.value[0]));

The MCSDK may have dynamic motor ID library calls and also have the very same issues monitoring switch case enumerated motor ID wait time steps (mtr1_user.c) via SCI ISR function. Does the MCSDK update Ki/Kp_Id/Iq during motor ID in debug expressions window?

//! \brief Run the controller
//! \param[in] handle The controller (CTRL) handle
//! \param[out] pVdq_V The pointer to the direct/quadrature voltage vector, V
static inline void CTRL_run(CTRL_Handle handle,MATH_Vec2 *pVdq_V)
{
CTRL_Obj *obj = (CTRL_Obj *)handle;

// when appropriate, run the PI speed controller
if(CTRL_getFlag_enableSpeedCtrl(handle))
{

// when appropriate, run the PI Id and Iq controllers
if(CTRL_getFlag_enableCurrentCtrl(handle))
{

// run the Id PI controller
PI_run_series(obj->piHandle_Id,refValue_A,fbackValue_A,ffwdValue_V,&(pVdq_V->value[0]));

The lab05 uses the "CTRL" object and functions that include the current and speed controllers. The lab07 doesn't use the "CTRL" object, so it uses the additional PI controllers. The FOC flows are similar in both labs, but only lab05 can support motor identification since the identification needs a few functions in CTRL object.

Yanming Luo said:

The lab05 uses the "CTRL" object and functions that include the current and speed controllers.

Both LAB is05 and is07 use PI control blocks and MCSDK motor ID asserts Pi_Run() for speed/current control and is07 asserts Pi_run_series(). When we look closely at MCSDK motor ID function does both motor ID and run the motor closed loop. The same EST bool (do) tests assert for speed and current set PI Ki/Kp_Id/Iq seemingly via Idq inputs both PI blocks as Idq_in_A[0/1]? The difference is negligible and again where is the diagram depicting these EST bool (do) control functions? The MCSDK code below (buried in highlights) is bit more inline with what I was attempting to do with SDK is07.

Below code is nearly same PI construct I was testing in LAB is07 to do motor ID but the motor would stop spinning in LS and the trajectory would not ramp up it was target speed or nothing. Note the below code Idq/ Vdq are not well documented above Fig.55, again is highly ambiguous as to where Vdq is being output into INVPARK. Figure 55 only shows Vq/Vd into INPARK where is Iq/id from PARK in MCSDK? We can see Clarke_run() but no PARK in motor ID code below.

#else     // !SFRA_ENABLE
            PI_run(obj->piHandle_Id, obj->IdqRef_A.value[0],
                   obj->Idq_in_A.value[0], (float32_t*)&obj->Vdq_out_V.value[0]);
#endif  // !SFRA_ENABLE

        // calculate Iq controller limits
        float32_t outMax_V = __sqrt((objUser->maxVsMag_V * objUser->maxVsMag_V) -
                          (obj->Vdq_out_V.value[0] * obj->Vdq_out_V.value[0]));

        PI_setMinMax(obj->piHandle_Iq, -outMax_V, outMax_V);

        // run the Iq controller
#if defined(SFRA_ENABLE)
        PI_run(obj->piHandle_Iq, (obj->IdqRef_A.value[1] + sfraNoiseIq),
               obj->Idq_in_A.value[1], (float32_t*)&obj->Vdq_out_V.value[1]);
#else     // !SFRA_ENABLE
        PI_run(obj->piHandle_Iq, obj->IdqRef_A.value[1],
               obj->Idq_in_A.value[1], (float32_t*)&obj->Vdq_out_V.value[1]);

As you see below MCSDK HAL does not keep consistent naming conventions with SDK symbols and macros. There were over 200 errors adding BSXL-8320RS_REVA to work with F280049c MCU class, excluding SFRA code. The x25 TRM does not even list SFRA, that's a bit puzzling. The MCSDK should have been backward compatible at very least x49c MCU class. The extensive use of Boolean #if / #endif opens the door for compiler mayhem. To me the SDK set precedence for construct of C language objects that MSCDK has deviated far left that which was well tested and established as HAL object code. Do not TI programmers ever have meetings to discuss code construct and who determined such a giant change to HAL was even prudent. I don't say that to be mean though REX installed the code well below SDK4.0 and were over 450 errors (types.h) (device.h) had to add project include paths and still does not fix many simple errors float32_t and unit32_t* is incompatible with unit32_t*, over 50 warnings let alone 95 errors after several hours debugging this beast.

Which example lab are you using? If you want to implement the Universal lab on F28004x, you need to follow the Universal Lab guide to change the hal.c and hal.h accordingly.

Yanming Luo said:

If you want to implement the Universal lab on F28004x, you need to follow the Universal Lab guide to change the hal.c and hal.h accordingly.

Not so easy as the build now has 5 compile errors. Where or what is BSXL8323_REVA vars handle code defined? So code can be added to make  DRV8320RS_REVA compile the same? I got all the other defines converted but 8320 vars handle shown below seems to be duplicate of the SPIVars_t define? Many of the errors came from filterfo.c/h and filterso.c/h, hundreds of float32 type.h errors when FAPI Types.h in is07 project above is15 was being discovered by the Indexer. 

Notice the DRV8320Vars_Handle is indeed defined via drv8320.h. There is even #include to motor_common.h above inside motor1.drive.h. Why arre there multiple drive object handles being defined for BSXDRV8323RS_REVA? This obj handle seems to be a redundant define SDK4.0 drv8320.h never had two drive handles.

#include "motor_common.h"
#include "motor1_drive.h"

//! \brief Defines the DRV8320 object
//!
typedef struct _DRV8320_Obj_
{
uint32_t spiHandle; //!< handle for the serial peripheral interface
uint32_t gpioNumber_CS; //!< GPIO connected to the DRV8320 CS pin
uint32_t gpioNumber_EN; //!< GPIO connected to the DRV8320 enable pin
bool rxTimeOut; //!< timeout flag for the RX FIFO
bool enableTimeOut; //!< timeout flag for DRV8320 enable
} DRV8320_Obj;

//! \brief Defines the DRV8320 handle
//!
typedef struct _DRV8320_Obj_ *DRV8320_Handle;

/* Expressions watch window variables */
typedef struct DRV8320_SPIVars_t_ *DRV8320Vars_Handle;

#if defined(BSXL8320RS_REVA)
#define DRVIC_Obj               DRV8320_Obj
#define DRVIC_VARS_t            DRV8320_SPIVars_t
#define DRVIC_Handle            DRV8320_Handle
#define DRVICVARS_Handle        DRV8320Vars_Handle

#define DRVIC_init              DRV8320_init
#define DRVIC_enable            DRV8320_enable
#define DRVIC_writeData         DRV8320_writeData
#define DRVIC_readData          DRV8320_readData

#define DRVIC_setupSPI          DRV8320_setupSPI

#define DRVIC_setSPIHandle      DRV8320_setSPIHandle
#define DRVIC_setGPIOCSNumber   DRV8320_setGPIOCSNumber
#define DRVIC_setGPIOENNumber   DRV8320_setGPIOENNumber
#endif  // BSXL8320RS_REVA

You may need to refer to the file for DRV8323 to define the control/status registers for DRV8320RS, and define the handle and object for DRV8320RS as well. The original DRV8320RS driver in motor control SDK can't be used directly in the Universal Motor Control Lab.

Yanming Luo said:

You may need to refer to the file for DRV8323 to define the control/status registers for DRV8320RS, and define the handle and object for DRV8320RS as well

The drv8323 handle as it was defined is not valid, according to C2000 compiler warnings. The code snips above handle is exactly the same structure for drv8320rs as drv823rs. Seemingly this issue existed in the release UMCSDK with far too many macros being redefined from SDK 4.0 HAL. Oddly there is round robin when mouse CTRL tracking these defined symbols for the watch window motor1_drive.h and motor_common.h. Simply CTRL click on the name in either function and they loop into opposite *.h files with no watch window end point being defined anywhere in the code path.

DRVIC_VARS_t drvicVars_M1; loop into DRVICVARS_Handle  drvVarsHandle;

extern DRVIC_VARS_t drvicVars_M1;

As for future motor control code the HAL of any MCU should fit into the project build with any specific driver PCB to avoid code mayhem. The UMCSDK could be a static and separate snap in module to run with an older or newer MCU class HAL within reason. The SDK4.0 had individual motor IC control PCB's and kept the compile code clean and easy to follow. 

Removed copied drv8320.c/h files from the users build folder and replaced with imported links to the UMCSDK folder under c:\ti thus results in warnings that can't be debugged to any cause and effect! Had to add global externs for PGA and DAC's functions which is mind blowing. Even after adding PGA/DAC driverlib function links into (src_driver) folder, CCS still compiled the two warnings above post. How on earth is the call DRVIC_setGPIOENNumber declared implicitly????? Notice I also tried to make it work the old way and that caused errors shown above post.

Yanming Luo said:

Please take a look at the definitation in hal_obj.h t

Don't you think I had done just that prior to asking for help? There is a redundant looping bug in motor1_drive.h pointer object. That also cause the hal.c "declared implicitly" compile warning above. Seems to be an global extern in another module to update watch window SPI parameters. 

   //obj->drvVarsHandle = &drvicVars_M1;

Hi Yanming,

I did get the MCSDK to compile work with x49c but adding the HID became a stop point that est.h did not have extern was easy fix. However the motor1_drive.h exports were causing symbol redefined first defined errors on project compile with HID commands module.

So back to is05 run in is07 of PM code snips but it first caused immediate controller error to run motor ID in is07 forever loop. The fix add 50µs delay near bottom of main.c where controller gets updated and add some parts of user_mtr1.c from MCSDK for now. Still like to get UMCSDK to compile with the HID at some point.

Thanks for your suggestions