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: Trajectory overshoot & SVPWM

Guru 54027 points
Part Number: LAUNCHXL-F280049C
Other Parts Discussed in Thread: CONTROLSUITE, BOOSTXL-DRV8320RS, , DRV8320, UCC27714, MOTORWARE, INA240

DC inverter connected to launchXL Booster pack headers J5-J8 via short jumper wires. ADC voltage feed back A,B,C phases consist 3 x 6" twisted pairs, ground common to both boards.

Does SDK v2.01 Lab05 and Lab07 have constraints to control speed trajectory overshoot for >1Kg rotor? Setting target >10Hz motor stalls on startup no matter acceleration adjusted any <10Hz/sec. Then the trajectory can only be increased 10Hz increments <60Hz or trajectory engine overshoots target and cause CMPPx trip >18.5A. Typical 20Hz trajectory target speed pulls down +24v BUS and stalls motor, cogs rotor in one to several pole places. Small Nidec series 25 motor <0.05 kg rotor mass has no trajectory speed issues quickly reaches >200Hz via 24VDC supply.

A large part of issue hours trying to determine reason for cogging was linked to J7 pins 64,65 (voltage feedback) being reversed, perhaps on J7 header launchXL? 

Oddly >2Kg rotor mass tops 300 RPM +24vdc (trapezoidal FOC via PI speed control) and only 168 RPM via FAST, refuses >60Hz unless 40vdc supply, feedback resistor divider has 57.42vdc MAX.

Should the USER_ADC_NOMINAL_BUS_VOLTAGE be set for actual DC supply Peak (user.h) only? Is voltage feedback divider used for USER_ADC_FULL_SCALE_VOLTAGE_V only? Simpy put is Nominal Bus Voltage an independent stand alone parameter? Obviously parameter helps to determine sector middle point but is it directly part of or tied to ADC full scale voltage as described (5.2.3 SPRUHJ1H–January 2013–Revised June 2019)?

To sum it up, can the nominal DC bus voltage be made 50% less than feed back resistor dividers without effecting the trajectory engine or speed controller actions?

  • Hi,

    Thank you for your question. An expert will get back to you for this question.

    In the future, please provide the full software name ("MotorControl SDK v#.##" or "ControlSUITE") and application you are using this for "Speed control" etc. This will allow us to provide faster assistance.

    Regards,

    Vince

  • Should the USER_ADC_NOMINAL_BUS_VOLTAGE be set for actual DC supply Peak (user.h) only?
    Simpy put is Nominal Bus Voltage an independent stand alone parameter?
    To sum it up, can the nominal DC bus voltage be made 50% less than feed back resistor dividers without effecting the trajectory engine or speed controller actions?

    This USER_ADC_NOMINAL_BUS_VOLTAGE is not critical, it's only used for motor identification, you might set its value to the rated voltage of the motor. It doesn't affect motor control functions during running.

    Is voltage feedback divider used for USER_ADC_FULL_SCALE_VOLTAGE_V only? Simpy put is Nominal Bus Voltage an independent stand alone parameter?

    Yes, the USER_ADC_FULL_SCALE_VOLTAGE_V is dependent on the voltage sensing circuit....

  • Hi Yanming,

    Regarding J7 pins 64,65 reversal (Vsense-B, Vsense-C) were they crossed on J7?

    The motor now starts up and runs but Labs.h forced acceleration delta trajectory speed 10 and over rides the user.h USER_MAX_ACCEL_Hzps ((float32_t)(2.0)) adding to acceleration errors Lab07. The motor should easily reach 190-200Hz via 40VDC bus supply and phase current 6-8 amps peaks. The SPV current peaks now occur 90Hz compared to trapezoidal FOC 190-200Hz.

    The phase current wave form has random odd sinusoidal shapes and motor will not reach 80Hz from 40VDC without large current oscillations, trips CPMSSx @90Hz 16 amps. Could the current sense leads J7 pin 45/B and pin 48/C also be reversed in table 3? The issue started after referring  BoostXL-drv8320rs quick start guide table 3 voltage and current sense inputs on J7 as identified.  

  • Since your motor is a low voltage motor, we would recommend that you might use the DRV8320RS kit to identify and run the motor first and see if there are any issues as you mentioned above. If not, you have to check the current and voltage sensing. 

  • we would recommend that you might use the DRV8320RS kit

    Already done did all that and BoostXL can not handle the higher test voltage >56V Nor the HV kit motor current load >10A. I don't recall BoostXL ever reaching >120Hz speed also very disappointing to say the least. 

    Since your motor is a low voltage motor

    The 36 pole SPM motor voltage is very dynamic and not related to this SPV slower speed and crossed J7 pins 64/65 issue. Rotor speed via 6 step FOC Trapezoidal versus SPV commutation has odd degraded performance. Perhaps due to FAST estimator rotor position detection being skewed?

    The current wave form/s (below) are not exactly fully sinusoidal seemingly sectors are misaligned. Sector misalignment in this case results in poor peak speed at any current level, hence current oscillations start >15A peak trip CMPSSx >80Hz rotor speed @40vdc. Yet the Vsense input wave forms A,B,C to Clarke/Park are very symmetric. Again 6 step FOC via the same DC Inverter current sensors reaches >190Hz @40v. 

    If the LauchXL49c has crossed J7 pins 64/65 is that not a hardware issue? Is it not proper for FE to reveal it to the community. If we have to dig Clarke/Parke transforms to verify odd crossed contention between voltage sense inputs, that is self defeating to the end cause of TI launch pads. Please verify BoostXL drv8320rs hardware issue may exist SPRUIJ3A–November 2018–Revised August 2019 as Booster header J7 pins 64 and 65 were misidentified VsenseB/C are reversed some where down the line.

    Edit: Notice there is only negative half cycles center, both ends are 1/2 wave!

  • I have a sneaking suspicion the pole pairs count (user.h) is being divided by Clarke/Park or somewhere else. Hence only half our Typical speed Hertz of 6 step trapezoidal FOC without over driving Id in each sector.

  • you have to check the current and voltage sensing. 

    Seems that is not the problem, BoostXL-drv8320rs produced similar current waves. This AM reduced 1nF LP filters on 3 current amps to be 200pF. and notice minor improvement phase A current symmetry. Motor commutation crashes 98-100Hz (oscillates), smooth 95Hz indefinitely. 

    Again 36 pole SPM motor speed should top out roughly 190-200Hz, 600-666 RPM @40vdc. 

    Speed formula: RPM=120*95Hz/36. Speed laser also confirms rotor max speed 316 RPM. 

    That being said the USER_MOTOR_NUM_POLE_PAIRS (18) perhaps has divided the rotor speed in half? Hard to imagine TI would abandon Trapezoidal commutation if SPV causes loss of rotor speed issues. We can live with trapezoid current noise, it never losses rotor flux linkage. 

    We now accumulate EMF at 100% PWM duty cycles to arrest current perturbations that lead to flux linkage crashes. Why SPV duty cycle seems to be 100% at 95Hz 300 RPM is a mystery.

  • Finding Boostxl-drv8320rs determined ld/lq ID flux value via Lab05 was partly to blame for non symmetrical sine wave but not the half cycles.

    It seems the truer ld/lq flux value occurs early in first 200-800ms x 20k capture of EST_STATE_RATEDFLUX almost triple the value. Otherwise far less then default value Estimated flux LS states FluxWaitTimes.  Yet the motorVars.flux_VpHz is very high (>3v) during this capture time and during motor ID current ramp produces full cycles of pure sine wave >60Hz speed. Why not after ID?

    That lab05 motor ID current ramp up is a pure sine wave >60Hz remains missing in above/below posted capture but why?   

  • If you have a chance to take a look at the instaspin user's guide, you might know the identification has different states with open-loop control or closed-loop control, so the current waveforms will be different in these states.

    What PWM and control ISR frequency are using in this project?

  • If you have a chance to take a look at the instaspin user's guide, you might know the identification has different states with open-loop control or closed-loop control, so the current waveforms will be different in these states.

    User guide Lab5 opening header claims ID allows closed loop control sensorless motor, never mentions open loop control. Anyway Lab7 has similar speed trajectory handle issues as Lab5 online. The current wave form Lab5 motor ID process has proper sine wave end to end, the online mode has issues.

    Current control Issue is revealed Lab5 ID accelerates heavy rotor like feather mass (10Hz/sec to 60Hz) several times, no flux crash. Yet Lab5, Lab7 both must set USER_MAX_ACCEL_Hzps extremely low to slowly reach 100Hz. We don't see these issues with small rotors <1Kg mass. Oddly the test motor reacts well to full sine wave Lab5 ID process and hates 1/2 wave current online run time. Other vendors SPV phase current wave forms do not show similar 1/2 wave current, something is oddly wrong.

    Last check CCS register view EPWM module Gens 1,2,4 CMPA had up/dn counts, CMPB zero update counts. Seemingly if CMPB has no updates it can't produce power cycles on low side MOSFETS, saturated switching never occurs. Perhaps a plausible reason for 1/2 wave pulses being produced. Other wise current should always be zero crossing, only magnitude must vary. You may not see this issue via PGA current monitors unless SW output to PGA_OF filter pins.

  • The figure below indicates PMW-B action signals on all 3 generators. Also indicates there are no CPMB load counts in the picture.

    Typically for PWMB to toggle the output drive, CMPB must have an initial load count and PWMB should remain in a Low state. Seemingly figure is depicted incorrectly showing only CMPA load points. Technically PWM-B output drive should remain low as CMPB was not loaded with any compare point values. Perhaps this is why a more robust sine wave is not being produced in Lab5 or Lab7?

    DeadBand generator A is likely inverting A loosing PWMB to make new B output. Perhaps such may not produce pure sine wave Inverse Park transform is control enabled by PI or other input source. With Trapezoidal PWM we use dynamic DeadBand SW controlled cycles, only assert for last on NFETs. This allows PWMB to pass through DeadBand and use the CMPB update.  

      

  • Yesterday changed current 1nF filters to 200pF and today 2200pF. Rotor speed now reaches 110Hz and crashes rotor flux accelerating to 120Hz (0.5Hz/sec) is not a good feeling. 

    The current wave form above appears to have FAST Irated control enabled, sometimes auto enables lab5 ID process EST_STATE_IDRATED. When FAST Irated auto enables motor has buzz noise zer zer zer zer zer zer  etc... Yet ID process continues on after J7 pin 64/65 reversed no longer trips CMPSSx faults and rotor accelerates again 60HZ (10Hz/sec) to finish ID process. Could it be FAST Irated (red line) switch is being enabled when it should not and distorting the current wave form when motor ID flag becomes false?

      

  • Whether the CMPB is used for PWM output depends on the EPWM configuration. 

    Let's focus on the running issue with the TI EVM kit first, to know if the issue is from the hardware or software.

  • Oddly Lab5 the R/L ohms test sinusoidal current also has 1/2 wave on both ends. My gut tells me PI controlled current is not well since it appears to truncate ends of SPV code switch table sectors 0,7. There should be two linked quadrant sinusoidal currents the entire cycle. Something in FAST control of Inv Park and later PI being enabled perhaps is chopping phase current drive? Motor >1kg rotor mass only run well with full phase current applied Lab5 ID process, seems a far reach to me.

    Whether the CMPB is used for PWM output depends on the EPWM configuration. 

    How motor ID process Lab5 forms a perfect sine wave the entire cycle controlling rotor 10Hz/sec acceleration mystifies one. Sine wave current control of rotor torque when PI is enabled falls apart in both captures. Lab7 does not care how accurate motorVars.LS ld/lq values are if PI control distorts the sinusoidal current on each end of cycle into 1/2 wave. How can we make Lab5 online and Lab7 produce pure sine wave?

    Let's focus on the running issue with the TI EVM kit first, to know if the issue is from the hardware or software.

    Seemingly both since the phase current inductor peaks reach edge of BoostXL capability, lab5 ID process. Perhaps due to J7 pin 64/65 reversal the LS half of ID process fails to complete and posts odd ld/lq values even burns B shunt. The motor runs >100Hz but is no indication of how well and had a somewhat reduced speed for the Bus voltage (40v) applied.

    After pin 64/65 swap Lab5 LS process completes without tripping CMPSSx fault via our test inverter. It even accelerates rotor when only move rotor 30° increments <1Hz speed before swapping J7 pins 64/65. Otherwise slow speed estimator never passes the ball to the high speed loop of FAST estimator. That swap appears to be a hardware issues of LaunchXL since it affects both ours and TI kits does it not?

  • How can we make Lab5 online and Lab7 produce pure sine wave?

    The shape of the phase current waveform depends on the BEMF shape of the motor.

    The observer (FAST) needs precise motor parameters like Rs, Ls, Flux to estimate the rotor position for implement sensorless FOC.

    That swap appears to be a hardware issues of LaunchXL since it affects both ours and TI kits does it not?

    I can't fully understand your questions on this. I think you can identify the motor on the launchxl-F280049C + boostxl-drv8320rs without any changes, even run the motor to a high speed if you don't add a heavy load on the shaft of the motor.

  • The shape of the phase current waveform depends on the BEMF shape of the motor.

    Not exactly true as 5 phase SVPWM has known dead band harmonics where 7 phase SVPWM does not, question is why exactly 7 claims not? If the two sectors (000,111) are not handled correctly EPWM module sinusoidal output will be distorted and chopped by dead band times truncating SVM code table output.

    Seemingly CMPB action qualifier has not being enabled for 7 phase on down count mode. Seems to fit the issue many reported this forum with current falling apart at certain speeds. The Vsense feed back signals (ABC) do not have 1/2 wave PWM cycles. 

    Also as I pointed out lab5 motor ID current ramp produces full wave sinusoidal via InvParke/SVM control of EPWM module. That same proper sine wave form is not being produced after motor ID or runtime PI control. Yet lab5/lab7 online run time with/out PI speed control EPWM output is distorted by 1/2 wave current cycles in above 1st capture. The 1/2 wave cycles seem to be generated by EPWM module, not the feed back loop.

    Your reasoning seems to be Vsense feed back loop is not being used during current ramp up? How is it possible the SVM code table can produce pure DSP sine wave without feed back loop, via FAST module layout depicted above?

    I can't fully understand your questions on this.

    It was not a question rather report J7 pin 64/65 (VsenseB/C) launchXL49c were crossed likely affecting BoostXL too.  The motor would not accelerate after the ID process but did via BoostXL. It could be the PGA_OF inputs J7 pin 64/65 are miss-identified in the launch pad guide or TRM tables. It would be good to know why one works the other does not, when J7 pins 64/65 Vsense inputs are not in configured in correct order shown BoostXL quick start guide.

    I think you can identify the motor on the launchxl-F280049C + boostxl-drv8320rs without any changes, even run the motor to a high speed if you don't add a heavy load on the shaft of the motor.

    The motor speed lags by >40% via the BoostXL for the same 40VBus compared to Trapezoidal FOC commutation. Top rotor speed was only 150Hz, should easily reach 190Hz. Again the current wave DSP via BoostXL produced 1/2 wave current distortions Lab5 ID and online Lab7 PI control. One Pro for SVP current generation is less vibration improved efficiency this relates to improved rotor speed for less energy expent. EPWM module control in SDK FOC seems to be configured incorrectly in my opinion.

  • I believe loss of inverter power issues are related to EPWM module type 4 configuration hal.c. The SW Action qualifiers (epwm.h) have incomplete defines missing action control states shown in TRM table 18-8 . Typical EPWM module control for SPV requires EPWM-A/B drives to be symmetric complementary pair. Improper dead band control states seem to be the issue causing 1/2 wave pulse ends onto sinusoidal current generation. Otherwise overlapping wave forms are generated from dead band generators depicted Fig.18-34.

    The typical DC inverter will Not develop full power in fast decay current mode. When LO driven MOSFETS are Not kept mostly saturated to cause slow decay current cycles in HO driven MOSFETS a loss of power is known to occur. Seems to explain 40% loss of rotor speed via SPV modulation for the same 40v bus voltage in each modulation technique being compared via BoostXL and Trapezoidal FOC with real time dynamic dead band control states.

    Since the current drive is not 100% for a 10Hz/sec acceleration to target, a commutation crash occurs as rotor flux linkage is rapidly lost. To counter fast decay current cycles direct control of dead band via local generator updates and global ctrl reg period updates works well. Or by SW control of action qualifiers as stated in TRM action qualifier section 18.6 but was unable to find the reference as stated in dead band section 18.7.  

    A dead band overlap occurs with BoostXL installed on site 1 or site 2. Yet hal.c did not configure dead band pass through for EPWM-A/B drives. This dead band redundant action control is unnecessary and seems to cause modulation issues for BoostXL-drv8320rs hardware. The SDK FOC has dead band configuration issues that can not be easily dismissed and may lead to poor DSP sinusoidal current waveform generation of any DC inverter. Placing #ifdef DRV8320SPI to enable pass thorough dead band mode 1 is a logical patch.  

    These two dead band controls 18.7.14 are missing epwm.h v1.07 driverlib

    – Active high complementary (AHC)
    – Active low complementary (ALC)

    • Mode 2-5: Classical Dead-Band Polarity Settings:
    These represent typical polarity configurations that should address all the active high/low modes required by available industry power switch gate drivers. The waveforms for these typical cases are shown in Figure 18-34. Note that to generate equivalent waveforms to Figure 18-34, configure the action-qualifier submodule to generate the signal as shown for EPWMxA.

  • There is a missing mask include to call EPWM_setDeadBandDelayMode() as to include hw_epwm.h  (EPWM_DBCTL_OUT_MODE_M 0x3U) dead band mode 3. Seemingly EPWM module then produces a complementary pair, non overlapping A/B signals to each half bridge.

    Oddly both DB modes are 0x3 table 18-8 but polarities are different binary code and missing complement polarity defines (epwm.h).

  • You are right. You don't need to enable or configure the dead band if the DRV8320 is used. The dead time will be set and generated by DRV8320. So that's why a very small deadband is set in hal.c in the projects using drv8320.

  • Yet the DB mode is set 4 and not 2 as it should be for either one. It requires symmetric complementary pairs to produce proper sinusoidal wave form. Perhaps the clue being EPWM is producing trapezoidal shapes on the ends but is center aligned thus oddly produces full sine wave dead center or when the duty cycle and periods are very short. That trapezoidal ends issue perhaps is more noticed when the DC Busvoltage is lower than the motor rated voltage for testing for proper EPWM module configurations.

    BTW: SDK preforming immediate updates direct to counter registers is an unwise practice and causes inverter to drive phases when clearing fault status bits. The result is a loud pop/snap sound from motor as output gates toggle from high impedance to active state. Sudden and rapid current flow occurs if the 1/2 bridge does not have an enable control pin such as the ucc27714 gate driver or drv8320rs. 

    So that's why a very small deadband is set in hal.c in the projects using drv8320.

    Yea that does not seem to work so well, report some have changed dead-band configuration disabled RED/FED (mode 4?) for use with BoostXL. 

  • The PWM output depends on the AQCTLA/B and DBCTL, and select the right operation mode of deadband is used according to the gate driver and inverter. The deadband mode is not related to the current waveform as your understanding. In most cases, the user implements the software dead time compensation to improve the current waveform.

    The PWM outputs are forced all sides to low, or high side to low and low side to high that depends on the EPWM control registers.

  • The deadband mode is not related to the current waveform as your understanding.

    Yet 1/2 wave on the ends of cycles have improved via mode 2 DB, but the 1/2 waves are still present. SDK dead band handling is less than cool since CMPB is not being used and DB mode 1 can not be enabled as to pass through complementary signals EPWM-A/B to BoostXL-drv8320rs. Yet a simple Bool switch was added to do just that in EPWM_setDeadBandDelayMode(RED/FED, false) DB mode 1. 

    Case mode 2 DB produces complementary active high A/B pairs (TRM Fig.18-34) required for SPV control of 1/2 bridges. Mode 4 DB produces active high overlapping A/B pairs, that is not proper for SPV control of any 1/2 bridges. Active high signal pairs work but seems to rob power cycles from phase current drives during odd DB time insertions. That is one reason why we use dynamic SW control of DBCTL registers in ARM based PWM modules to allow Slow Decay of hihg side MOS.

  • As mentioned in another thread you posted. Generally, the dead time value is dependent on the gate driver and power FET, and it's a fixed value. Of course, you can online change the dead time value as the codes below if a dead time compensation is implemented.

    // setup the Dead-Band Rising Edge Delay Register (DBRED)
    EPWM_setRisingEdgeDelayCount(obj->pwmHandle[cnt],HAL_PWM_DBRED_CNT);

    // setup the Dead-Band Falling Edge Delay Register (DBFED)
    EPWM_setFallingEdgeDelayCount(obj->pwmHandle[cnt],HAL_PWM_DBFED_CNT);

    I don't understand what do you mean "SPV" for motor control. Is it solar photovoltaic? We use SVM or SVPWM to calculate the duty cycle for motor control.

  • Again the 2 calls overwrite DBCTL S3,S2 register polarity 0x0000, DB mode 4. Perhaps a quick fix is to load DBFED=0 then DBRED=1 to assert DB mode 2.

    SPV = space vector phase control.

    We use SVM or SVPWM to calculate the duty cycle for motor control.

    Right but the sector look up table should be located in SVM block, CMPA register value loaded by SVM block RAM/Flash, not ROM! Please post the code snip where EPWM module is loading CMPA register with any values of SVM block shown in Fig.55 above.  The new x49c FAST estimator topology is nothing like Fig.55 

  • You might find the SVM code and calculate PWM duty cycle in SVGEN_run() in svgen.h, calculate and write CMPA in HAL_writePWMData() in hal.h. Both functions are open source in the project.

  • I don't care for hidden ROM objects that do not expose the registers being input to EPWM module via SVM block. I'd rather not even mess with CMPB just to determine where or why 1/2 wave current pulses are modulated. Seemingly that is TI engineering to fix since the ROM hides SVM block sector lookup table.

      

  • BTW: SDK v2.01 kgm^2 inertia calculation (labs.h) produced unusable high motor.Vars_Kp_spd value. Same issue formula Pg.72 (labs guide) Kp-series BWc decimal is shifted right, L=n.nnn, actually L= 0.nnnn.  A rotor mass >1kG the PI speed integral is far to high and the proportion worse. The fix below helps PI speed controller quickly stabilize, reduces over shooting target. The original formula causes immediate flux crash from Kp_spd being several hundred over the value required to quickly stabilize current.

    (user.c)
       #endif
        }
        else
        {
           	/* Lab7 determined BW required for kp_spd/ki_spd */
            pUserParams->BWc_rps = MATH_TWO_PI * (float32_t)100; //Filter pole: 100 rads/sec
            pUserParams->BWdelta = (float32_t)5.598;
    (user.c)
    #if(!USER_MOTOR_INERTIA_EN)
       	   	/* Motor has not been ID */
        	pUserParams->flag_bypassMotorId = false;
    
            pUserParams->BWc_rps = MATH_TWO_PI * (float32_t)100.0; //20
            pUserParams->BWdelta = (float32_t)8.0;
    
            	/* Is not motor intertia user.h */
            	pUserParams->Kctrl_Wb_p_kgm2 = (float32_t)3.0 *
    										   pUserParams->motor_numPolePairs *
    											(float32_t)(0.001) /
    											(float32_t)(2.0 * 0.000001);
       	#endif
        }
        
    (user.h)
    #define USER_MOTOR_INERTIA_EN             1
    #define USER_MOTOR_INERTIA_Kgm2           (0.352838295721)  
    
    (labs.h)
    #if(!USER_MOTOR_INERTIA_EN)
        //
        // set the speed controller
        //
        PI_setGains(piHandle_spd, motorVars.Kp_spd, motorVars.Ki_spd);
    #else
       
        float32_t Kctrl_Wb_p_kgm2 = (float32_t)3.0 *
                                  userParams.motor_numPolePairs /
                                  userParams.motor_ratedFlux_Wb /
                                  (float32_t) (USER_MOTOR_INERTIA_Kgm2 / 2);
                                  //Kgm2*2, * numPolePairs

  • If you look at the  SVGEN_run() in svgen.h, the SVM doesn't need any SVM block sectors lookup table, and any SVM/SVPWM algorithm doesn't need a lookup table since there are only 6 sectors with 2-level for motor control.

    Yes, you need to select the right BWc_rps and BWdelta according to your motor and system, the default value is just for some motors defined in user.h

  • If you look at the  SVGEN_run() in svgen.h, the SVM doesn't need any SVM block sectors lookup tabl

    All space vector motion require lookup table to produce correct phase drive via firing each 1/2 bridge NFET frames of ld/lq orders. The fact we don't see a table as it exists in ROM. Code 000 - 111 require switch table lookup on all EPWM modules industry wide.

    The SDK or EPWM are not producing proper sinusoidal 3 phase current. Proper 3 phase current drive does not have void breaks or 1/2 wave mixed in. Trapezoidal PWM current 2 phases active 1 of 3 has off time. Yet 3 phase sinusoidal all 3 phases remain active, no breaks as the EPWM is producing. Also motor stalls, current oscillates >90Hz rotor does not reach trajectory Hz speed even driven by all 3 phases.

    Perhaps by adding 120° phase shift offsets to slave EPWMx SDK might produce always active 3 phase current sine waves?  

    The float32_t Kctrl_Wb_p_kgm2 formula was not correct when BWc_rps, BWdelta are >0. The Kp_spd value was so increased motor not even start but current goes very high. Have to imagine odd errata x49c MCU where x79D MCU may differ?

  • There are different methods to implement SVM, and the method used in motorWare/MotorControl doesn't need to calculate the sector.

    The float32_t Kctrl_Wb_p_kgm2 formula was not correct when BWc_rps, BWdelta are >0. The Kp_spd value was so increased motor not even start but current goes very high. Have to imagine odd errata x49c MCU where x79D MCU may differ?

    I am difficult to follow you. Can you have a detailed description of this?

  • There are different methods to implement SVM, and the method used in motorWare/MotorControl doesn't need to calculate the sector.

    I have Motorware TI documents state how to, even show SVM requires tables to control DC inverter to produce full wave sinusoidal current. The SDK current has trapezoidal attributes on each cycle and wide breaks in phase current generation. Perhaps why SPM motor looses 45% top speed for same 40vdc. Seemingly TI SVM should surpass trapezoidal FOC motor speed by producing full wave sinusoidal currents Clap.  Notice CMPA load value only updates when PI speed change occurs and the duty cycle remains 50% during steady state. The 1/2 period pulses by CMPA loads on each end of current makes no sense where/how the pulses originate.

    The first image below is from Motorware SVM code tables for ACIM/SPM motors. Most all vendors use lookup tables to produce SVM sine wave current, why has TI vectored away from the proven method?

    BTW: The trajectory acceleration interrupt ticks(1) (user.c) was partly to blame start crashes 10hz/sec Lab7. The trajectory interrupt tick count is missing (user.h) and may be part of flying start issues Lab9. I set 5 ticks to slow down start trajectory, sort of like EMF skip counts for PI controller integral to take action.  

    I am difficult to follow you. Can you have a detailed description of this?

    Look at the code snips above and compare to SDK v2.01 or v3.01 has made several changes to user.c. The problem was the kgm2 define causes CCS compiler error when user adds kgm2 intertia to motor parameters user.h  

  • The first image below is from Motorware SVM code tables for ACIM/SPM motors. Most all vendors use lookup tables to produce SVM sine wave current, why has TI vectored away from the proven method?

    The implemented method in motorControl is also a classic SVM algorithm that can be found in some textbooks and papers.

    Add the motor macro definition in user.c. These calculation parameters are just for speed and current controller as a reference.

  • The implemented method in motorControl is also a classic SVM algorithm that can be found in some textbooks and papers

    Not any I have researched via TI wiki or other published articles or patents. This SDK sensorless FOC method (hal.h) is not producing proper phase currents and phase shift well behind ADC sense voltages to Clarke. 

    doesn't need a lookup table since there are only 6 sectors with 2-level for motor control.

    Notice the above SVM switching table notes 2 level inverter codes.  Oddly we see 170ms gaps of no current to motor 80-100Hz speed, inverter is not 7 phase controlled FOC. It seems that could be due to CMPA load truncates from x49c tool chain register directives. The load count CMPA register bits 32:16 and TBCTR bus bit 15:0, the counter has extremely high memory mapped decimal value via CCS debug. Oddly the period remains 50µs with duty cycle but FOC commutation is missing switching pulses during 170ms voids.

  • Perhaps a remote possibility x49c EPWM module unknowingly defaulting to HR mode 4, 24 bit CMPAHR bits (24:0).  Datasheet x49c/TRM mentions EPWM mode 0 CMPA defaults 16 bit symmetrical PWM.

    If the EPWM CMPA register is actually in mode 4 even though HRPE bit was never enabled what would happen to CMPA 16 bit match counts? Seemingly EPWM only loads lower 8 bit TBCRT match count bits (24:16) via 328µs main_ISR interrupt loads CMPA and not effect 50µs TBPRD periods and still allow small dutycycle changes to TBPRD.  

  • If the EPWM CMPA register is actually in mode 4 even though HRPE bit was never enabled what would happen to CMPA 16 bit match counts? Seemingly EPWM only loads lower 8 bit TBCRT match count bits (24:12) via 328µs main_ISR interrupt loads CMPA and not effect 50µs TBPRD periods and still allow small dutycycle changes to TBPRD.  

    It seems like you are discussing this topic in another thread, please don't repeat the same question in this thread. Thanks!

    Not any I have researched via TI wiki or other published articles or patents. This SDK sensorless FOC method (hal.h) is not producing proper phase currents and phase shift well behind ADC sense voltages to Clarke. 

    You might search "Low cost digital signal generation for driving space vector PWM inverter" in google and find a paper about the SVPWM that shows how to implement SVM without sector identification.

  • It seems like you are discussing this topic in another thread, please don't repeat the same question in this thread. Thanks!

    Because you do not acknowledge any kind of PWM modulation issue exist with the way SDK. The hardware platform to function correctly via SDK FOC motion code is not just a SW related topic due to interrupt timing and other aspects . Many posters have reported current and speed issues for good reason, the SDK is failing to perform correctly on the x49c hardware platform. The Iq skew angle of high speed current seems to be another great clue something is horribly wrong.

    "Low cost digital signal generation for driving space vector PWM inverter"

    Again you refuse to even consider missing PWM modulation pulses are plaguing the sensorless FOC BoostXL as well. The PWM generated sinusoidal current wave form CH2 above capture is complete nonsense according to several book sources, you too can research. I doubt seriously Clarke transform is causing missing PWM pulses show CH2 of first capture. 

    These links are knowledgeable sources for how SVM functions to produce Proper sinusoidal 3 phase motor currents. The 1st link has animated SVM sector wheel, very cool as it shows inverter switches changing states as sector changes occur.

    https://www.switchcraft.org/learning/2017/3/15/space-vector-pwm-intro

    https://community.nxp.com/thread/466420 

    https://www.researchgate.net/profile/Ayman-Yousef-6/publication/282859193_Space_Vector_Pulse_Width_Modulation_Technique/links/574db33a08ae8bc5d15bf37b/Space-Vector-Pulse-Width-Modulation-Technique.pdf

  • You might search "Low cost digital signal generation for driving space vector PWM inverter"

    SVM as coined by industry do not remove the sector look up table to drive the 3 phase inverter via a single EPWM comparator. It would be proper to append SVM with the word (Modified) as to set it apart from what is know to be proven theory for the last decade.

    I seriously doubt author of modified SVM drive (SDK motion FOC) had any idea EPWM module omits necessary pulse periods producing dead time gaps 3 phase current drive. That seems completely opposite from how TI inverter power stages do produce simulated 120 VAC sinusoidal voltages.  

  • You might have a look at the two links below. The CSVPWM is implemented in the motorControlSDK. BTW, the SVM is an algorithm to calculate the duty for the EPWM modules, but it's independent of the EPWM module.

    http://aboutme.samexent.com/classes/spring09/ee5741/Space_Vector_PWM.pdf

    https://www.ijera.com/papers/Vol3_issue5/S35102109.pdf

  • Hi Yanming,

    The first link discuss space vector wheel but the second link starts via;

    Abstract: This paper presents Space Vector based Generalized Discontinuous Pulse width modulation (GDPWM) algorithms for VSI fed Induction motor drive. 

    The problem with SDK on x49c seems to be EPWM is producing 100% divided duty cycles main__ISR Instaspin 382µs decimation periods when it should not be. That issue seems to cause voids in AC current drive and produces DC pulses on either side. The GDPWM link pulse train has smaller breaks as EPWM is producing mid center and distorting induction current. This issue in my opinion is related to x49 tool chain and CMPA binary location in memory mapped address space relative to counter compare sub module registers address bits 15:0. 

    I get GDPWM reduced switching via 0.5v binding periods. Yet PWM pulses are producing a 100% AC sinusoidal current wave form in the article examples. That is a far cry from what is actually occurring in the SPM motor from Vsense where No slip ever occurs.

  • Yanming,

    I asked forum several times if Instaspin produces 7 phase or 5 phase SVM codes. Answer was, 7 phase SVM. GDPWM was not meant for SPM motors, rather ACIM to reduce the sector tracking complexity of ld/lq rotor slip angles. Motorware SVM past used position sensor integrated into FOC for ACIM motor drive and 6 sector code tables for both ACIM and SPM motors.

    Why would the SDK not include the same sector code tables as Motorware sensorless FOC? It seems to me something is not working correctly on x49c if GDPWM is so robust as CSVM. Seemingly a good reason TI engineering to try SDK on x79 EPWM.  Again there is 45% loss to motor speed for the same voltage applied 6 step trapezoidal commutation. That alone rings the warning bell something ain't working as it should.

  • One observation, GDPWM has two modulation schemes. CMPA alone makes one sided all positive modulations. GDPWM is like fast decay trapezoidal PWM and CMPB generates low side bridge pulses, CMPA generates high side bridge pules. Perhaps CMPB addition EPWM can generate inversions shown below, for negative -Vabc_pu[n] and CMPA +Vabc_pu[n] values. That is If the goal was to mimic GDPWM by producing the same modulation pulses. It seems the SDK modulation could be improved by splitting HAL_writePWMdata() into two distinct comparator load routines.

  • CSVPWM uses the 7-phases with two zero vectors, V0(000) and V7(111), the DPWM like DPWMMAX or DPWMMIN uses 5-phase with only one zero vector V0 or V7.

    As mentioned above, the SVM is independent of the EPWM modules. You can just use CMPA to implement the PWM output for SVPWM or DPWM if the ePWM is set to symmetric output with deadband. Of course, you can use CMPA and CMPB to get a more flexible output.

    The link below is a good brief introduction about SVPWM for your reference.

    www.switchcraft.org/.../space-vector-pwm-intro

  • the DPWM like DPWMMAX or DPWMMIN uses 5-phase with only one zero vector V0 or V7.

    Notice too SDK signal is more closely related to 5 phase, two legs active one not. The point I also make above SDK modulated PWM output is neither GDPWMAX or GDPWMIN since it missing bottom half (-pu) of wave form.  Seems that may be due to missing duty cycle CMPB and CMPA has issue with high order match counts. The PWM wide signal voids do not belong and cause mayhem for large mass rotors. Note the Tesla-S/GM Bolt rotors alone are roughly 60 pounds. 

    BTW: Adding float32 front of inline declared variables (hal.h) caused large phase current transients. The change below reduced THD 2% or more. This was a nice change and scope signal capture 10K samples deep is very clean. I thought transients were coming from INA240,  no it was SW.

    HAL_writePWMData(HAL_Handle handle, HAL_PWMData_t *pPWMData)
    {
        HAL_Obj *obj = (HAL_Obj *)handle;
        uint16_t pwmCnt;
        float32_t V_pu;
        float32_t V_sat_dc_pu;
        float32_t V_sat_pu;
        float32_t period;
        
        // Remove inline floats being decalred above

  • The link below is a good brief introduction about SVPWM for your reference.

    The link I put above was to you Laughing. I have used Wiki PDF documents on TI methods to generate SVM, one below in particular is very good read. I based my early SVM understanding on below PDF and creating sector lookup tables for ARM based PWM.

    /cfs-file/__key/communityserver-discussions-components-files/171/TI_2D00_TMS320F243-SVPWM-spra524.pdf

  • DPWM like DPWMMAX or DPWMMIN uses 5-phase with only one zero vector V0 or V7.

    After some thought GDPWM text states 2 legs active, 2 NFET's not 5 or 7. A phase leg consists of one sided H/L co-partner bridges being active, 2 phase active at any given time. GDPWM as discussed outlines 2 phase active switching. Has less switching losses, THD since only 2 NFET (brances) fire at any time Kissing heart. The 5/7 phase signals are specifically generated by SVM sector tables U0 to U7.

    Seemingly DPWM-Min/Max consist of active high overlapping EPWM A/B outputs with dead band B inversion FED. Reason we also see upside down houses -400v modulation signals, trapezoidal fast decay commutation Stuck out tongue winking eye. The difference; SDK has single CMPA duty cycle and omits the negative modulation signal needed for proper DPWM-Min/Max as discussed GDPWM text.

    Yet it also shows CSVM Vsense signal (as an example only), without sector look up table how can such modulation ever be produced. Point is CSVM (example) is only a primmer for GDPWM.

    A typical type 0 PWM module can easily produce fast decay ± PWM modulation signals via CMPB duty changes. Adding CMPB to SDK split the V_pu algorithm for ± comparator load events produced erratic current after saturation math. Yet the x49c dead band gen outputs remained complementary rather than active high, mode 2 dead band may be reason.  

       

  • The PWM module you mentioned above is different from the ePWM module of C2000, and the C2000 ePWM is more flexible. You can set the ePWM according to your requirement.

    Currently, the motorControlSDK just needs to use the CMPA for implementing the SVM. We might use both CMPA and CMPB to achieve more complex outputs in the future as you mentioned. Thanks!

  • BTW there is no documentation on SDK modulation technique in htm or PDF. The co/sin math svgen.h, hal.h leg clamp method deviates from math shown in various sources. Article below mentions SVPWM is superior only low frequency and  DPWM higher frequency, my book 50Khz - 100Kh constitutes Hi frequency. The best SDK could achieve was 150Hz via BoostXL on J5-J7.  

    Have a look at high performance DPWM research paper. The math formulas uses digital 60° space vector rotations, determined via max V of highest phase only. I notice some minor difference how CMPA loads duty cycle values that differ from SDK method. The phase currents were was uneven C phase peaks, A/B fell behind. All were reduced by several amps in steady state after moving float32_t defines into declare area. The CCS compiler produces finer granularity output, float is typedef was added to each statement of inline code, slows down the CPU.  

     https://minds.wisconsin.edu/bitstream/handle/1793/9932/file_1.pdf;sequence=1

  • Only CSVPWM is implemented in motorcontrolSDK, the motor phase current is not obviously impacted by the SVPWM/DPWM modes.

    The floating-point is used in motorControlSDK since the F28004x device support hardware FPU32.

    Let's close the topic since you don't have a specific device or software related questions. Thanks!

  • Only CSVPWM is implemented in motorcontrolSDK,

    Contrary to these several text links only CSVPMW uses lookup tables for rotation switching of VSC/VSI. Where DPWM-x uses rotational calculations and no look up tables for switching inverter legs.

    The FOC seems it matches DPWM1 since it has no switching table and the rotation calculations are very similar almost direct copy. Motorware once produced 7 phase switching codes 000-777 so that is why anyone would assume SDK is no different in switching scheme.

    Oddly launchXL does not work properly with non vendor VSI hardware and reverses Vsense leads B for C and 1/2 bridge B for C. If the phase drive order and Vsense leads are connected typical (A,B,C) order of BoostXL the VSI will not function correctly. The VSI produces 60° to 90° phase angle error in the current drive the only way the slow speed estimator will function correctly without large current spike transients when ABC order to VSI. Why is the phase order being reversed for non vendor VSI making current very distorted with 1/2 wave pulses?

    The VSI has no difference in Vsense and 1/2 bridge GPIO connections than BoostXL. And the slow speed estimator will not start the motor via ABC order again does not bode well for sensorless FOC of the SDK. What is the reason to make V_pu negative input to math_sat(V_pu, 0.5, -0.5) then multiply +0.5 Dc sum of the period? Seems to wash out the saturation value just calculated. CMPA period load algorithm makes no sense when evaluated to make negative Leg CMPB load values. CMPB works but the duty cycle starts out very small values on CMPA too.

    The floating-point is used in motorControlSDK since the F28004x device support hardware FPU32.

    The function declared variables are used to define floating point numbers within a function. It is not necessary to do inline floats on every variable since FPU will process decimal numbers listed in the declarations, from that point on without stack manipulations pushing/popping return addresses for every floating typedef call float_32t was inline referenced. We can turn on assembler output verbose in the project to see how floating point is being assembled for FPU handling. Again 2% reduced THD transients are worth having a look at.

  • The VSI according to text must have high Mi=0.7 to produce GDSVM - DPWM0,1 or DPWMMin, Max results. The phase shift rotation approach (π/6, π/3) removes the overhead typical of CSVM rotation calculations. Again removing inline float32_t from CMPA duty cycle updates improved CPU interrupt handling of the called function times. Yet many forum posters still complain of current drive issues on custom PCB's similar to my postings but at much greater currents. My point is if SDK code can't take the heat at low voltage, low current something is the cause driving said effect. 

    I tried again aligning EPW1,2,4 into ABC order doing the same for Vsense ABC and motor refused to start. Even tried changing the INA240 input order A,B,C then B,C,A and several other combinations. If EPWM1,2,4 are fully synchronous 1Master/2Slaves (Synci/SyncO). Why does changing the order EPWM1,4,2 even work when Vsense order is same but motor fails to start (EPWM1,2,4) order? 

                    // setup the Time-Base Control Register (TBCTL)
            EPWM_setTimeBaseCounterMode(obj->pwmHandle[cnt],
                                        EPWM_COUNTER_MODE_UP_DOWN);
            // disable PHSEN bit in TB submodule
            EPWM_disablePhaseShiftLoad(obj->pwmHandle[0]);
            // enable PHSEN bit TBRD phase shifted load by TBPHS counts
            EPWM_enablePhaseShiftLoad(obj->pwmHandle[1]);
            // enable PHSEN bit TBRD phase shifted load by TBPHS counts
            EPWM_enablePhaseShiftLoad(obj->pwmHandle[2]);
    
            // set the period load mode quiet shadow loading /
            EPWM_setPeriodLoadMode(obj->pwmHandle[cnt], EPWM_PERIOD_SHADOW_LOAD); //EPWM_PERIOD_DIRECT_LOAD
            // Set EPWM1 Master Sync Out pulse, on count zero.
            // Default: set Master sync pulse SW generated by EPWM_forceSyncPulse()
            // function is called or by EPWMxSYNCI signal.
            EPWM_setSyncOutPulseMode(obj->pwmHandle[0], EPWM_SYNC_OUT_PULSE_ON_COUNTER_ZERO);
            //EPWM_SYNC_OUT_PULSE_ON_COUNTER_COMPARE_D //EPWM_SYNC_OUT_PULSE_ON_SOFTWARE
            // set EPWM4, EPWM2 Slaves Sync pulse In/Out PWMxSYNCI/O.
            EPWM_setSyncOutPulseMode(obj->pwmHandle[1], EPWM_SYNC_OUT_PULSE_ON_EPWMxSYNCIN); //EPWM_SYNC_OUT_PULSE_ON_SOFTWARE
            EPWM_setSyncOutPulseMode(obj->pwmHandle[2], EPWM_SYNC_OUT_PULSE_ON_EPWMxSYNCIN);//EPWM_SYNC_OUT_PULSE_ON_SOFTWARE
            
            // setup the Time-Based Phase Register (TBPHS)=Zero
            EPWM_setPhaseShift(obj->pwmHandle[1], 0);//832
            // setup the Time-Based Phase Register (TBPHS)=Zero
            EPWM_setPhaseShift(obj->pwmHandle[2], 0);//415    

    The INA240 sensor output is discontinuous sinusoidal (CH2) and seemingly not synchronous with EPWM modulations. Even though phase current seems continuous via current clamp (1st capture) that is no indication sector rotation is keeping synchronous to/with CMPA load events via (main_ISR) 384µs Instaspin EPWM decimation timing.

    Why does INA240 have 1/2 wave pulses in the EPWM duty cycles and bypassing Vsense inputs into Clarke transform shown as separate Block Labs guide? The FOC current sense via EPWM SOC ADC triggered interrupts for (Ia,Ib,Ic,Va,Vb,Vc) inputs are seemingly Not synchronous with FAST when Ia,Ib,Ic are externally input analog sub module.