LAUNCHXL-F280049C: Trajectory overshoot & SVPWM

Guru 49855 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?

  • The INA240 sensor output is discontinuous (CH2) 2nd capture and not synchronous with EPWM modulations driven alpha/beta Vsense inputs. 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) 328µs Instaspin EPWM decimation timing.

    Why does INA240 have 1/2 wave pulses in sync with EPWM duty cycles. Perhaps single unbound Clarke transform leads to ADC input signal order collisions of some kind in FAST estimator inputs?

         

    Lab7 90Hz VSI 2ms PWM modulator versus Lab5 BoostXL-drv84320rs 150Hz PWM modulation:

  • Seemingly format contention exist in the input data struct skipping over a 32 bit typedef word position previously compiled. Symptom (dcBus_V) exists in a previously defined struct position shown below. Seemingly a coding violation that was missed by C++ code analysis tools. BusVoltage data exist in the first Globals typedef formatted data positions and voids 32 bit word gap when R/W of Globals formatted data strings.

    Either filling or omitting trajectory data in the process but it effects the trajectory in the rotation computation speed to target. Perhaps we shouldn't label format strings with typedef parts (cheery picking) over existing 32 bit words without a symbolic name/named in a formatted R/W string and referencing a typedef Globals format. 

    Seemingly Clarke digests or even omits certain data and sends it to FAST estimator, take your pick.

    My vote code 2 Clarke functions to keep inductive current (alpha/beta) and voltage (alpha/beta) data completely separate ADC input formats.

    Top Lab5 and Lab7 global names are entangled in two typedef structs using the same symbolic name for a variable not being formatted in the global name/s.  

    HAL_ADCData_t adcData = {{0.0, 0.0, 0.0}, {0.0, 0.0, 0.0}, 0.0};
    
    //! \brief Defines the estimator (EST) input data
    //!
    typedef struct _HAL_ADCData_t_
    {
        MATH_Vec3 I_A;         //!< the current values
        MATH_Vec3 V_V;         //!< the voltage values
        float32_t dcBus_V;       //!< the dcBus value
        float32_t throttle;      //!< the throttle input
    } HAL_ADCData_t;
    
    
    EST_InputData_t estInputData = {0, {0.0, 0.0}, {0.0, 0.0}, 0.0, 0.0};
    
    //! \brief Defines the estimator (EST) input data
    //!
    typedef struct _EST_InputData_
    {
      int32_t    timeStamp;        //!< a time stamp for the input data buffer
    
      MATH_Vec2        Iab_A;            //!< the alpha/beta current values, A
      MATH_Vec2        Vab_V;            //!< the alpha/beta current values, V
      float32_t          dcBus_V;          //!< the DC bus voltage value, V
      float32_t          speed_ref_Hz;     //!< the speed reference value, Hz
      float32_t          speed_int_Hz;     //!< the speed int value, Hz
    } EST_InputData_t;
    
    
    //What data do you need ??
            //
            // store the input data into a buffer
            //
            estInputData.dcBus_V = adcData.dcBus_V;
            estInputData.speed_ref_Hz = motorVars.speedTraj_Hz;
            estInputData.speed_int_Hz = motorVars.speedTraj_Hz;

  • Point in above code being dcBus_V was not included in the EST_InputData_t estInputData sting layout even though dcBus_V is a FAST input below Clarke block. The typedef code is questionable as to how adcData.dcBusV can be temporary saved to a Non existing location of estInputData format. Also questions how Vsense inputs to Clarke are being crossed (A,C,B) when using ADC PGA_OF inputs and omitting PGA outputs via the analog sub module. 

            //
            // store the input data into a buffer
            //
            estInputData.dcBus_V = adcData.dcBus_V;

  • It's difficult to follow your questions. Could you please create a new topic if you have a different question from the topic title?

  • Yet it's the same topic and I notice today phase A current has pure angle signature, not sine wave shape at all via current clamp. Something in the format strings into Clarke is not correct and BoostXL has crossed inputs (J7) VsenseB, VsenseC into Clarke. So Lab5 motor ID would stall with heavy rotor load 60Hz trip DAC over current, via the BoostXL-drv8320rs. 

    The two format strings top of lab05-07 seem to have overlapping ADC data using the same function call for two Clarke calls, data sent into FAST estimator.  The formatted data is not easy to follow or determine the input data strings order is consistent via ADC analog inputs. 

    Clarke needs to have separate input blocks into FAST estimator as depicted, not use the same function. Especially since there is no documentation on the subject matter of Clarke block sharing the ADC channels data via confusing multiple type def structs. Seemingly something in this part of the Clarke alpha/beta code is getting cross linked and degrading performance across the board. Notice above captures sinusoidal current (VSI) versus (BoostXL), proves ADC inputs to Clarke are better that SDK had produced via Vsense-B reversal Vsense-C. How is that so difficult to understand?

    The above captures compares BoostXL with typical VSI/VSC using proper ADC input order for Clarke Vsense and ISense channels. The PWM modulation is not keeping consistent into Clarke inputs and the synchronization is horrible in both examples the angle is skewed. Why is the order of the ADC inputs not keeping consistent in the format data strings?  

  • The Clarke.h transform (sense vectors) has minor GPIO position input issues. Clarke transform also does not use typical ╥ angles to calculate rotor position alpha/beta, why? Phase current is not keeping synchronous with magnetic flux (slips) falling behind as Vsense speed increases into Pi block rotor crashes.

    Again switching Vsense-B, Vsense-C GPIO input positions (J7) is part of the problem with BoostXL Lab5 motor ID Rated Flux immediately tripping EPWM DAC faults. Obviously we can't change hardware but GPIO inputs need (A, C, B) order for BoostXL to produce proper PWM modulation. The above posted left side (VSI) scope captures reveal (right side) sinusoidal current is not the proper shape. The BoostXL-drv8320rs phase current is Not supposed to have Vsense signature crests. Many have posted similar current captures SDK 2.01 occurs in custom PCB's, top speed issues even abandoning the entire project.

    This point I have stressed a few times, cold NACK as to why Clarke inputs Vsense order was reversed SDK. Seemingly typedef alpha/beta format strings into FAST estimator are overlapping ADC data, the input string data positions (Isense / Vsense) are converging inside of Clarke_Run() transform.

    Can the Clarke transform typical math (below) be compared to FAST estimator angle generator for alpha beta? Were calculations simply left out by mistake? This reported issue of Clarke data converging is producing overshoot in the trajectory data as Vsense frequency increases the Isense starts to oscillate and crash rotor flux.

        /* Calculate pIalpha using the equation, pIalpha = Ia */
        *pIalpha = Ia;
    
        /* Calculate pIbeta using the equation,
         * 	pIbeta = (1/sqrt(3)) * Ia + (2/sqrt(3)) * Ib + (3/sqrt(3)) * Ic  */
        *pIbeta = (((((float32_t) 0.57735026919) * Ia) +
        		     ((float32_t) 1.15470053838) * Ib) +
    			     ((float32_t) 1.73205080757) * Ic);

  • Why is there No documented disclosures FAST-FOC inputs, Clarke transform requirements for (Ia/Ib, Va/Vb) inputs? The Clarke transform sense input order required for VSI to start and run up to 95Hz (below). Reversing Isense order does not change phase A triangle wave shape. Phase B and C via current clamp appears nicely sinusoidal.

    Anyone might assume Clarke alpha/beta inputs follow industry standards for older CSSVM rotation algorithm, versus DSPWM1/2,Min/Max and clamping one leg high or low dc.

    INA240 above captures (top right) CH2  shows 170ms discontinuous frames indeed occur. I don't believe 170ms voids to be scope aliasing on CH2 rather highlights discontinuous algorithm, CMPA duty cycle changes. Note too the difference PWM drive CH1 has fewer discontinuities in the same 2ms Horizontal sweep time, when Vsense order (A,C,B) on the VSI captures (left side). 

     

    // hal.c
    #ifdef INA240A1
        // ISENB - PGA4_OF ADCC8->RC0 INA240(J5-46)/RC-filter
        ADC_setupSOC(obj->adcHandle[1], ADC_SOC_NUMBER0, ADC_TRIGGER_EPWM1_SOCA,
                     ADC_CH_ADCIN8, HAL_ADC_PGAxABC_SAMPLE_WINDOW);
    
        // ISENC - PGA6_OF ADCA8->RA0  J3-24(B0)INA240(J5-45)/RC-filter
        ADC_setupSOC(obj->adcHandle[0], ADC_SOC_NUMBER0, ADC_TRIGGER_EPWM1_SOCA,
                     ADC_CH_ADCIN8, HAL_ADC_PGAxABC_SAMPLE_WINDOW);
    
        // ISENA - PGA2_OF ADCB8->RB0 INA240(J5-48)/RC-filter
        ADC_setupSOC(obj->adcHandle[2], ADC_SOC_NUMBER0, ADC_TRIGGER_EPWM1_SOCA,
                     ADC_CH_ADCIN8, HAL_ADC_PGAxABC_SAMPLE_WINDOW);
    #endif
        // VSENA - A6->RA1    J7-63
        ADC_setupSOC(obj->adcHandle[0], ADC_SOC_NUMBER1, ADC_TRIGGER_EPWM1_SOCA,
                     ADC_CH_ADCIN6, HAL_ADC_SAMPLE_WINDOW);
    
        // VSENC - B6/A2->RB1 J7-64
        ADC_setupSOC(obj->adcHandle[1], ADC_SOC_NUMBER1, ADC_TRIGGER_EPWM1_SOCA,
                     ADC_CH_ADCIN6, HAL_ADC_SAMPLE_WINDOW);
    
        // VSENB - C14->RC1   J7-65
        ADC_setupSOC(obj->adcHandle[2], ADC_SOC_NUMBER1, ADC_TRIGGER_EPWM1_SOCA,
                     ADC_CH_ADCIN14, HAL_ADC_SAMPLE_WINDOW);
                
                     
    // hal.h
    
    #if (BOOST_to_LPD == BOOSTX_to_J5_J6)
        // convert phase B current       PGA4_OF->ADCC8->RC0
        value = (float32_t)ADC_readResult(obj->adcResult[1], ADC_SOC_NUMBER0);
        pADCData->I_A.value[0] = value * current_sf;
    
        // convert phase C current       PGA6_OF->ADCA8->RA0
        value = (float32_t)ADC_readResult(obj->adcResult[0], ADC_SOC_NUMBER0);
        pADCData->I_A.value[1] = value * current_sf;
    
        // convert phase A current       PGA2_OF->ADCB8->RB0
        value = (float32_t)ADC_readResult(obj->adcResult[2], ADC_SOC_NUMBER0);
        pADCData->I_A.value[2] = value * current_sf;
    
        // convert phase A voltage        ->RA1/A6
        value = (float32_t)ADC_readResult(obj->adcResult[0], ADC_SOC_NUMBER1);
        pADCData->V_V.value[0] = value * voltage_sf;
    
        // convert phase C voltage        ->RB1/B6
        value = (float32_t)ADC_readResult(obj->adcResult[1], ADC_SOC_NUMBER1);
        pADCData->V_V.value[1] = value * voltage_sf;
    
        // convert phase B voltage        ->RC1/C14
        value = (float32_t)ADC_readResult(obj->adcResult[2], ADC_SOC_NUMBER1);
        pADCData->V_V.value[2] = value * voltage_sf;
    
        // convert dcBus voltage          ->RC2/C1
        value = (float32_t)ADC_readResult(obj->adcResult[2], ADC_SOC_NUMBER2);
        pADCData->dcBus_V = value * voltage_sf;
    #endif

  • What questions do you want to solve in this thread? The motor identification must be run without load.

    As replied to you in this thread or other threads you posted. We want to make sure that the hardware board you design is good for a motor drive first. I don't think these contents you mentioned above are related to the instaspin-foc, the instaspin-foc/FAST should be ok for most of the generic motors. 

    Could you please create some new threads for posting your questions? We are very difficult to follow and understand your questions in this thread.

  • . I don't think these contents you mentioned above are related to the instaspin-foc, the instaspin-foc/FAST should be ok for most of the generic motors. 

    Go on thinking that and mayhem will have it's way.

  • The motor identification must be run without load.

    That has been well established it was not loaded. Yet Vsense (B,C) ADC inputs remain crossed BoostXL-drv8320rs SDK code. Also explains how Lab5 ID burned up Nidec motor windings very small input current vibrates shakes motor violently. It becomes clear when an external VSI connected to launchXL refuses to even start larger motors. Change ADC input order Vsense (C,B) then Lab5 completes ID without shaking vibrating motor violently, that's alone is proof something was not correct in BoostXL ADC inputs to Clarke.

    Could you please create some new threads for posting your questions?

    So you simply refuse to answer questions relative to Carke transform? Supposedly open source yet omitting any all documentation or notes does not bode well for community wellness. Again the SDK code for Clarke calls and format does not follow the block layout as defined SPRUHJ1H–January 2013–Revised June 2019 and other Lab guides showing figures of two distinct input blocks to FAST estimator.

    Say for arguments sake instruction decode timing Flash memory wait states manifest into 1/2 wave pulses noted in above discontinuous currents. How is anyone going to trouble shoot the issue without clear documentation for FAST handling of Clarke inputs? The flux linkage becomes unstable when the current oscillates. The FAST angle estimation diverges as a function in the flux linkage as the speed PI control becomes unstable Lab7. Noting yet another post Phase A wave has angular shape, seemingly Clarke handing of Isense and Vsense one suspected cause.

    We are very difficult to follow and understand your questions in this thread.

    I take many times to lay issues out in well documented format and you still refuse to grasp the SDK has some design bugs needing attention. Perhaps ask your supervisor to allow more lab time to check over reported odd issues, not only by me but several other posters. Again the phase current (A,B,C) should not have trapezoidal modulation, BoostXL was also producing above captures. The current is supposed to be mostly sinusoidal with very small if any at all trapezoidal modulation pattern. Notice my VSI current captures are superior to BoostXL, surely the VSI meets DPWM Mi 0.7 index qualification standard. Seeing is believing in my book.

  • If you are using the TI EVM kit, the ADC configuration should be right for current and voltage sensing for the input of the Clark. You have to change the ADC configuration accordingly if you are using your own board, or connect other inverters to TI kits.

    I don't think there are any questions on the Clark transform function in the motorControlSDK, which is just the typical FOC function. The input is the three-phase current or voltage on a/b/c frame and the output is the current/voltage value on Alpha/Beta frame.

    I don't think there is a significant design bug in the motor controlSDK as you mentioned. Maybe, the instaspin-foc can't run well on some motors like an IPM motor at low speed, or a low inductance motor at very high speed, which needs a fine-tune on the example labs. You might take a look at some textbooks about the FOC technique that could show the difference between PMSM drive with sinusoidal FOC and BLDC drive with trapezoidal control. 

  • You have to change the ADC configuration accordingly if you are using your own board, or connect other inverters to TI kits.

    Again the point is the DRV8320rs configuration has reversed Vsense-B and Vsense-C messes up motor ID badly for several motors tested! 

    I don't think there are any questions on the Clark transform function in the motorControlSDK, which is just the typical FOC function

    That is a matter of opinion and SDK Clarke transform seems custom fitted for FAST estimator alpha beta inputs. Typical Clarke transform found well established ARM CMSIS code was presented above, why ignored? Note CMSIS differs wildly from Clarke transform provided in the SDK, why is that?

    Again TI documentation for Clarke transport method as to justify Ld/Lq spacing alpha/beta waves? TI reasoning or theory to combine both Clarke blocks to one last call and separates I/V functions as two calls? Other vendors do no use the same method as TI for Clarke transform, that is a reach. Other vendors of SVM motor control systems only have one Clarke block, not two.

    You might take a look at some textbooks about the FOC technique that could show the difference between PMSM drive with sinusoidal FOC and BLDC drive with trapezoidal control. 

    This point is well documented and SDK FOC fails to live up to many of the standards. Continuing to accept sloppy sinusoidal wave forms being produced by SDK is not going to win the Nobel prize either. Again there are DC pulses being injected into the AC current, in no way is that text book accepted anywhere. The C2000 is supposed to be superior yet hindered by several SDK code points. The EPWM configuration for one omits Master Slave synchronization timing as outlined in the TRM required to maintain proper Ld/Lq frames spacing of SW rotation vectors. Always try to improve PWM control of DSP, the heart of the beast!

  • The Clark transform is not related to the motor parameters, it's a mathematical method and uses different equations according to two or three inputs.  In theory, the current waveform of the a/b/c and alpha/beta is a sinusoidal shape, but in fact, it could be just similar/close to the sinusoidal with a distorted shape. the voltage waveform of the a/b/c depends on using the modulation method, but the alpha/beta voltage waveform is a sinusoidal shape after using the Clark transform.

  • Yet the SDK tries to use the same transform equation for the FAST angle calculation relative DPWM1/ DPWMMIn. The SDK lab approach should abort FWC perhaps leave MTPA, stick to basics and make clean sinusoidal wave form without PI oscillations. 

    For instance the intertia BW delta calculation of Lab07 example is kluged and caused large rotor (>1Kg2) to ever reach maximum velocity without crashing trajectory/current tick counts. Finally just test very high integral (Ki_spd) on a whim and what do you know PI lets the speed to 140Hz but at  >ld/lq inductance than BoostXL ID finds. Now motor achieves nearly same 6 step trapezoidal speed (190Hz), actual 135Hz 435 rpm by laser target Heart eyes. The PI integral is set extremely tight Lab7 and the intertia algorithm (labs.h) was simply someones best guess but very wrong. My posted labs.h change code seems good for >0.3 Kgm2, heavy rotor mass user input inertia. Perhaps Tesla, Ford or GM could use x49c MCU to drive those heavy rotor load too.  

    The Clarke and ADC input filter rotation algorithms could be improved to maximize rotor speed without FWC. Try adopting shadow CMPA loads on zero counts or period seems just as good, check the shadow full flag prior to CMPA loads. Point is the sinusoidal wave form on all phases should be uniform and without ADC Vsense detent showing above the 3rd harmonic in the drive current. The promise of GDPWM better efficiency and much less THD seemingly can be achieved by C2000.

    //
    // Added My motors inertia value user.h
    //
    #if(USER_MOTOR_INERTIA_EN)
        	/* Lab7 determined BW required for Kp_spd/Ki_spd */
            pUserParams->BWc_rps = MATH_TWO_PI * (float32_t)150.0; //Filter pole: rads/sec
            pUserParams->BWdelta = (float32_t)38.0; //55.98
    
    #endif
    
    // Arm CMSIS Clarke transform was current related:
    
    
      /**
       *
       * @brief  Floating-point Clarke transform
       * @param[in]  Ia       input three-phase coordinate <code>a</code>
       * @param[in]  Ib       input three-phase coordinate <code>b</code>
       * @param[in]  Ic       input three-phase coordinate <code>b</code>
       * @param[out] pIalpha  points to output two-phase orthogonal vector axis alpha
       * @param[out] pIbeta   points to output two-phase orthogonal vector axis beta
       * @return        none
       */
      __STATIC_FORCEINLINE void arm_clarke_f32(
      float32_t Ia,
      float32_t Ib,
      float32_t Ic,
      float32_t * pIalpha,
      float32_t * pIbeta)
      {
        /* Calculate pIalpha using the equation, pIalpha = Ia */
        *pIalpha = Ia;
    
        /* Calculate pIbeta using the equation,
         * 	pIbeta = (1/sqrt(3)) * Ia + (2/sqrt(3)) * Ib + (3/sqrt(3)) * Ic  */
        *pIbeta = (((((float32_t) 0.57735026919) * Ia) +
        		     ((float32_t) 1.15470053838) * Ib) +
    			     ((float32_t) 1.73205080757) * Ic);
      }

       

  • The gains of both speed and current PI/PID regulators are calculated per the motor parameters and are just for reference for a generic motor, it's better to tune these parameters according to the real system.

    The Clark you mentioned should be the same since the Ia+Ib+Ic=0 in a three-phase motor.

  • The Clark you mentioned should be the same since the Ia+Ib+Ic=0 in a three-phase motor.

    Have discovered Vsense scale factor is not being configured with any value via HAL_getVoltageScaleFactor() and negative voltage values are present input data too. Oddly the ADC has 3v3 peak 4096 count level and the Vsense analog inputs are <1.5v P2P via resistor divider. The scale factor math is corrupting the real time Vsense (EMF) values to Clarke() and FAST is by luck only approximating phase angle. The phase angle is off by nearly 15°maybe 30° best guess, thus motor will loose top speed at Max current angle.

    The Sense inputs to Clarke are not scaled to DC bus voltage levels as described SVPWM or DPWM literature. The VSI index factor (Mi) determines voltage Max of DPWM1/2 or SVPWM/DPWM1 (mixed) where U1 max = p/2v3 = 0.906p.u Mi. Seemingly the SDK has limited VSI index (Mi) to 0.5p.u Peak via fixed saturation levels HAL_writePWMData(). The math diverges and Mi can not be set >0.5pu without effecting the phase angle output from FAST estimator.

    The FAST estimator Clarke alpha beta inputs digest ADC values greater than 4096? What TI text discusses the theory or details input requirements for FAST estimator alpha beta inputs? 

  • The VBus_SF decimal point is shifted to the right 1 place making 2.06 SF to be 20.6xxxx. Oddly alpha beta are smaller values but the ADC Vsense inputs to Clarke are scaled very high input values. The V_V-SF decimal point is CCS debug issue? Oddly negative Vsense are actually positive values (real time) debug watch expressions. Are the ADCdata.V_V values to be as high into Clarke, what are Max input values to angle calculations?

      

    The gains of both speed and current PI/PID regulators are calculated per the motor parameters

    The point again Kgm^2 algorithm (labs.h) is not for most any user motor >1Kg rotor density as coded! The Lab07 formulas to find PI series_ki/kp values are not working well (if at all). Defaults keep PI proportion far to tight thus crash motor flux and stall motor during peak accelerations.

    The PI system kgm^2 as coded (labs.h) seemingly only works with fictitious or very small inertia values needs to be updated. The kgm^2 algorithm (user.c) must not be used with User motor inertial values added (user.h), the (default) BWdelta is to rigid tight crash magnetic flux. Best to make the user.c as two select defines for both BWc_rps/BWdelta default/user entry. Reviewing SDK v3.01 the same kgm^2 inertial issue described above exited SDK v2.01. We both had no idea what was cause of motor flux crashes Thinking

  • If you have a look at the codes in ISR carefully, you might find an offset is removed on both current and voltage, so the current and voltage will have positive and negative values.

        adcData.V_V.value[0] -= motorVars.offsets_V_V.value[0] * adcData.dcBus_V;
        adcData.V_V.value[1] -= motorVars.offsets_V_V.value[1] * adcData.dcBus_V;
        adcData.V_V.value[2] -= motorVars.offsets_V_V.value[2] * adcData.dcBus_V;

    Also, you can find the current and voltage sampling result is converted to floating by multiple a coefficient in HAL_readADCDataWithOffsets() in hal.h. The SI unit is used in motorControlSDK for all of the variables, so the input of the Clark is floating-point with Ampe or Volt for current and voltage.

     The Vbus_sf is not used in the latest motorControlSDK. It equals half of dc bus voltage. You might find the code below in the project that shows how to calculate the Vbus_sf for removing the voltage offset. 

            motorVars[ctrlNum].offset_invVbus_invV = 0.5;   // the scale factor of half of dc bus
            
                    // calculate Vbus scale factor to scale offsets with Vbus
            motorVars[isrNum].Vbus_sf = adcData[isrNum].dcBus_V *
                                           motorVars[isrNum].offset_invVbus_invV;
                                           

    As replied to you before, this is just for reference, you might change the calculation formula for the gains of speed PI controller though it has been verified on most of the generic motors in the TI lab. We'd like to close this topic here. Thanks!

  • so the current and voltage will have positive and negative values.

    A current (bipolar) offset is not necessary as output of PGA or INA240 respectively centers +1.65v, ZeroXing=2048 counts. Seemingly channel offset should be (<1v) subtracted results, not (IA_OFFSET_A/B/C). However the Vsence SF offset I was referring to being excessively high. It made no difference to change VSF to a static value (2.054) versus 20.54. Seemingly Clarke was not handling the Vdq signals as expected. 

     The Vbus_sf is not used in the latest motorControlSDK. It equals half of dc bus voltage. You might find the code below in the project that shows how to calculate the Vbus_sf for removing the voltage offset.

    Perhaps you should have shared that earlier when I first mention Clarke transform somehow reverses Vsense channels documented for BoostXL-drv8320rs.

    We'd like to close this topic here. Thanks!

    I'm sorry for the inconvenience but was expecting less hassle to get motor running similar to 6 step Trapezoidal PI controlled commutations. You still have not provided documentation on FAST estimator alpha/beta inputs expected values.

    Why so difficult to make public disclosures around the edges of ROM embedded FAST control block? The SDK FOC minimal documentation expects users to make assumptions. Yet SDK FOC method differs greatly from other vendors disclosed methods in the same market share. Spent weeks trying to tame this tiger perhaps a little wiser though only shot foot a few times along the way Joy.

    Thanks for some help and still PI_series control math (Labs guide) is odd at best. Compared to earlier PI controls (proportional, integral) produce less under/overshoot speed and never crash the duty cycle well into acceleration trajectory. Perhaps it is the Vsense SF to blame. 

  • The offset on the amplifier or PGA is used to convert the bidirectional phase current to 0~3.3V for ADC, so subtracting the offset in code to convert the phase current and voltage to bidirectional value, like -n.mA to +n.mA or -n.mV to +n.mV. 

    Yes, we changed the offset calibration in the latest version.

    The Clark function is open source in the lab, and FAS just needs the phase current or voltage values on alpha/beta for estimating the rotor angle and speed. Sorry, we can't provide more details about how to use these values in the FAST.

  • so subtracting the offset in code to convert the phase current and voltage to bidirectional value, like -n.mA to +n.mA or -n.mV to +n.mV. 

    I can reason the logic for the current offset or ADC 2048 or imaginary 0v being subtracted from read results. Though for Vsense inputs if the channel voltage offsets >0V (floats), top of float becomes new threshold (imaginary 0v), then add the offset to the read results. Subtracting the offset removes imaginary 0V from the read results producing a lesser value then actually sampled above channel float. The current angles is bit more stable too this way.

    Sorry, we can't provide more details about how to use these values in the FAST.

    FAST channel input specifications are not proprietary disclosures, rather mandates. No engineer embellishes a mystery where logic is involved.