SDK (FOC)

Genatco

Part Number: LAUNCHXL-F280049C
Other Parts Discussed in Thread: BOOSTXL-DRV8320RS

Oddly if we set the current ramp time +30 (below) then rated OL 17 Amps PTP for several seconds lab5, until we enable=0 it never leaves state assume is OL. But if ramp wait time is reduced to say +5, Rated Flux OL shows up in CCS watch window after it trips DC fault every time. Otherwise it seems to run in the background but the state machine CCS debug watch window is stuck on current ramp up 60HZ.

This same 24v 14.6A SMP works same motor, only 4.2A via 6 step sensorless commutation. So it has to be some issue how rated flux OL enter with PWM drive set very high duty cycle. Also have the DC filter count set very high to exceed SMP peak current shown below. This SDK has issues not to easily ID motors or even run from previous user.h parameters via BoostXL-drv8320rs. How can this be such an efficient way to run motor when 10x as many amps? I suspect the user FS amps some part and feel 84mV/A shunt PGA gain (x12), ADC FS is more close to 35A Peak.

Note (motorVars.flagEnableUserParams = true) does not get motor parameters from user.h. It only gets user.c time wait and sets a few parameter values near bottom user.c. The GUI has the same flag check box and it is supposed to use online motor settings as user enters for user.h. So to run the motor and skip motor ID, motor goes online from user.h settings, not user.c some kind of mix up there?

1.What needs to be changed so rated flux can soft start from state machine control loop?

OL ramp up time wait is missing or was never added.

2. What determines the PWM duty cycle for current ramp up and rated flux OL?

Perhaps 17A PTP ramp up is a bit excessive (60Hz) as 20Hz stalls rotor every time.

3. How will a 48v 20A SMP make any difference if rated flux OL is tripping DCA/B faults very close 1/2 FS?

There has to be a better solution as SDK past ID this same SPM motor (42v 10A SMP) with stalled rotor (20Hz). Can not duplicate with DC-A/B (OSHT) protecting BoostXL. The 3 CCMPx were not functional and nFault pin via VDS set 15.6A is not tripping faults as it should, DCA1/B1 (OSHT) knows better.

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);

    3856, /* +17.32A/805µV, 3856-2048=1808*805µV=1.46v/84mV, dacValH */         
   -3856, /* -2.30A/805µV, 4096-3856=240*805µV=.1932/.084, dacValL(invert) */  
    2048, /* dacaVal */                                                        
   -2048, /* dacbVal */

    //
    // initialize the user parameters
    //
    USER_setParams(&userParams);

This function is not updating motor.parameters from (user.h) values for later online motor runs after the ID process completes. Seems someone has used flag to load values from user.c when it should load from user.h. Perhaps another flag must be added. The GUI does not load user.h values (check box) and we have to save motor.parameters with GUI context. It still did not run motor from past session with user.h values entered after motor ID with user.h box selected. How motor ran closed loop is a great mystery but it only run via Online CCS real time debug session that same day, never able to test user.h very next day.

true, /* flagEnableUserParams */

over 6 years ago

0 Genatco over 6 years ago

Guru 56398 points

The 24v 14.6A SMP current limit often starts chirping when OL rated flux starts. Generally when I hear SMP chirps, the CUT is under stress so I quickly disable the source. Yet DC A1/B1 OSHT (+/-17.32A) often has the last word when current reach >27A Peak as see on scope current probe .

Also added 40mm Fan (+5v) above NexFETS cooling during CUT stress, 60-62Hz rated Flux OL. Had to power Fan from USB +5v pass up on 2 booster pins. It was to much load for +3v3 boost +5v into JP9, would immediately bounce MCU POR into fault condition.

So it seems the stalled 20Hz rotor gave necessary flux for motor to run online, perhaps debunks SDK method for motor ID. Seemingly ID information required to run SPM can be acquired via low current condition of stalled rotor if CCMPx DCA/B are disabled. I simply did not like how stalled method differs from documentation and could not get our DC inverter to duplicate the boostXL stalled method. Thus decided it was futile to keep going in that direction but it had worked without any real cautions of user FS ADC current 42A. Otherwise this poster would not be here asking why and how come.

Social distancing is good time to debug the SDK code, is it not?

0 Yanming Luo over 6 years ago in reply to Genatco

TI__Guru** 117210 points

As replied to other threads you posted, could you please tell us what changed did you do in the example lab? And which board are you using? Can you post some test current waveforms if possible? Please post the user.h you used also. That should help us to understand your questions, I don't remember I ever met similar problems as you mentioned above.

BTW, as we have answered the similar questions many times you posted, the motor identification must be done without any loading on the motor. It seems like a load is added to the motor you used. And don't change any wait time for identification in user.c.

0 Genatco over 6 years ago in reply to Yanming Luo

Guru 56398 points

Yanming Luo said:
BTW, as we have answered the similar questions many times you posted,

You really have not answered any question to why the SDK was released without proper DC comparator trips and nFault 15.6A again seem to fail on BoostXL-drv8320rs today stalled rotor 20Hz. It seems the nFault should trip before shunts start to burn? One reason we stopped using those type shunts long ago, all metal to handle odd switch currents.

The 48v 20A SMP with same DC A1/B1 trips (+/-17A) used with 24v 14.6A SMP has tried to burn 7mohm shunts, EST-5.2A 20Hz stalled rotor. Yet it runs up to 60Hz and faults DC every single time entering Rated Flux OL with user motor 9.2A, 11.2A max. If we don't set the current high the rotor stalls before ever reaching even 30Hz. Oddly the higher the motor current, Rated Flux would sometimes start to run but quickly drags down SMP. This ain't no hobby motor!

Yanming Luo said:
the motor identification must be done without any loading on the motor.

There is only the weight of the rotor and belt sprocket, has no problem 3.8A, 24v SMP, speed 300 RPM with 6 step commutation.

There is no problem 6.3A, 48v SMP, speed 630 RPM with 6 step commutation.

Yanming Luo said:
And don't change any wait time for identification in user.c.

That is contrary to what is stated SPRUHJ1H–January 2013–Revised June 2019 that in order to reach 50Hz speed the state ramp time must be extended. Oddly it don't matter what state ramp time is set as the trip of DC occurs rated flux OL due to slamming PWM 100% duty cycle it seems. Please enable the DC in the SDK ePWM trip actions so it can protect HW from burn when ID states do not work correctly. It is bad engineering to slam PWM so hard as Rated Flux OL state has been doing from the very first time to ever test this kit with smaller Nidec motor.

Yanming Luo said:
could you please tell us what changed did you do in the example lab?

ACIM locked rotor flag false (labs.h) and put (if) check lock rotor for induction IdRated_A as the flag was not being checked. Lab5 REM note states be run for ACIM magnetic and this is SPM. It was locking the SPM rotor on Nidec motor after ramp up, slammed rotor to immediate stop.

if(motorVars.flagBypassLockRotor == false)
{
    //
    // get the magnetic current for ACIM
    //
    motorVars.IdRated_A = EST_getIdRated_A(estHandle);
}

Rated Flux OL drags down +24v 14.6A SMP to 8v bus voltage prior to DC trip fault. Oddly BoostXL VDS nFault never trips 15.6A as it was configured. Yet the CMPSSx are at times wiser but not always and never tripped as shunts started to burn after 20Hz stalled rotor ID and only run 48v SMP.

0 Genatco over 6 years ago in reply to Genatco

Guru 56398 points

Below change necessary to lab5 so SPM can reach 50-60Hz speed or rotor will stall as SPRUHJ1H talks about. TI has to make SDK compatible with low inductance SPM [1 uH < Lphase < 10 uH] stator windings. Rated flux OL will not begin PWM cycle/s on stalled 20Hz rotor, scope show PGA_OUT has high current square waves. It is clearly outlined that stalled rotor is not acceptable to determine rated flux OL or LC. Oddly stalled rotor ID online could run to 550Hz (40vdc) being an indicator something in SDK is not correct as outlined in text. Below was forced to 20Hz in and over rides user.h user entry of Hz.

Again user motor parameters (user.h) are not being directly input lab5 parameters. Motor current often peak well above MAX entered user.h. Seemingly FAST estimator does check USER_MOTOR_RES_EST_CURRENT_A but always overshoots USER_MOTOR_MAX_CURRENT_A constraint. Reason why it burn two 7mohm shunts after ID online we can not click disable fast enough. CCS debug real time watch ignores several mouse clicks pointer directly over hex value to toggle 0x1 back to 0x0.

    motorVars.speedRef_Hz = USER_MOTOR_FLUX_EXC_FREQ_Hz;  // set reference frequency to 20Hz-50Hz

0 Yanming Luo over 6 years ago in reply to Genatco

TI__Guru** 117210 points

The MotorControlSDK software is using a floating-point format that can support low inductance motor without any change. You just need to set the identification variables according to the motor specifications. We have tested the low voltage, high current, and low inductance motor with these labs and didn't have any problems as you mentioned. I don't think the issue is from the software, please check if the hardware board is good to drive the motor, and set the parameters according to the hardware board as well.

Please post the schematic and user.h if you still have questions, those should help us to understand and solve your questions.

Btw, the board seems like having an overcurrent fault, the motor should be stopped by setting the flags to false as the below code in the project.

if(motorVars.faultUse.all != 0)
{
motorVars.flagRunIdentAndOnLine = false;
motorVars.flagEnableRunAndIdentify = false;
}

C2000™︎ microcontrollers

C2000 microcontrollers forum

SDK (FOC)