TMS320F280049C: Noisy current when using 2 current sensors instead of 3.

Update 1: Motor ID works - it's just the initial offset calibration that is screwing up which is then in-turn stuffing up the ID process. If I disable offset cal, the ID process works.

Even after IDing, the noise issue is still there. It's most noticeable at low speed where it creates a huge amount of vibration that is not there when running with 3 sensors. In this case, even with conservative Idq controller gain values.

Update 2: I found the issue to do with the offset calibration error: In main.c (e.g. any lab .c file) there is a mistake in how the voltage filter handle is declared:

//!< the handles for the voltage offset calculation
FILTER_FO_Handle  filterHandle_V[USER_NUM_CURRENT_SENSORS];
//!< the voltage offset calculation
FILTER_FO_Obj     filter_V[USER_NUM_VOLTAGE_SENSORS];

Obviously, this should be:

FILTER_FO_Handle  filterHandle_V[USER_NUM_VOLTAGE_SENSORS];

I still have the noise issue though. Please help.

Hi Hani,

Hani Chahine said:

It's a high current application so I will be using LEM current sensors that are to be placed inline with the phase (rather than low-side leg) and sensing two phases instead of 3.

Are you aware SVPWM (7 phase) can not achieve 100% duty with only 2 current sensors?

You can change the hal.c in SDK to only configure 2 for [i] loops in each specific peripheral areas of code but advised not too! The vibration Acoustic noise you mention perhaps state machine fail to set proper motor ID flags. We see state machine often jumps from RS -> RoverL direct to LS skipping RampUp speed and rated flux OL as state often passes over continuous speed. We check this area SDK since LS seems to require high speed rotor via RampUp (155Hz)  just prior to RatedFlux OL Fig. 6-22. SPRUHJ1H–January 2013–Revised June 2019 page 264 figure 6-20, 6-22

We try setting RampUp wait time differently (user.c) so ID current Fig 6-23 during before state RampDown is stable for state LS. It seems state LS often occurs inside state RampDown until after tweaking other wait times (user.c).   

    pUserParams->estWaitTime[EST_STATE_RAMPUP] =
    		 (int32_t)(20.0 * USER_EST_FREQ_Hz);
        //(int32_t)((USER_MOTOR_FLUX_EXC_FREQ_Hz / USER_MAX_ACCEL_Hzps +
        // (float32_t)1.0) * USER_EST_FREQ_Hz);

6.5.6.2 Total Measurement Time Fig.6-21
The time shown in this plot is based on the default setting of 3 seconds for the current ramp-down (EST_Flux_State_CL1, CL1 stands for Closed Loop 1) and 4 seconds for the fine tuning of the rated flux (EST_Flux_State_Fine), for a total of 7 seconds. Both of these values are set in by function calls in file user.c, as shown below:
pUserParams->FluxWaitTime[EST_Flux_State_CL1] =(uint_least32_t)(3.0*USER_EST_FREQ_Hz);
pUserParams->FluxWaitTime[EST_Flux_State_Fine]=(uint_least32_t)(4.0*USER_EST_FREQ_Hz);
These default values are known to work for all the motors tested during the validation of the algorithm. Note there is no state OL (open loop) time wait occurring via state machine as per defines (user.c). So RampUp speed should occur prior to state OL and not LS per Fig.22. That too seems some of the issue with motor vibration, seemingly TI engineers need to first check the state machine against documentation. Otherwise trial error but no rotor vibration should be occurring after state RS.  

    pUserParams->LsWaitTime[EST_LS_STATE_RAMPUP] =
        (int32_t)(10.0 * USER_EST_FREQ_Hz);
    pUserParams->LsWaitTime[EST_LS_STATE_COARSE] =
        (int32_t)(3.0 * USER_EST_FREQ_Hz); //was 30
    pUserParams->LsWaitTime[EST_LS_STATE_FINE] =
        (int32_t)(30.0 * USER_EST_FREQ_Hz);

Hani Chahine said:

In main.c (e.g. any lab .c file) there is a mistake in how the voltage filter handle is declared:

Yet the SDK (hal.c) seems to resolve that problem filter. It seems your using the older motorware control suite? I see the same low speed vibration directly after LS state UserMotorHz 20-40Hz just after CL2 ramps motor 1.3krpm then suddenly speed reduces clunk sound into LS state. Vibration starts up to 300Hz and seems less near 500Hz and still has odd noise disturbing PWM commutation. Also modified (is05_motor_id.c) to allow user Hz speed since low speed vibration 20-40Hz is excessive after LS state. Never can run motor without vibration >150Hz after ID completes unless patch is added and I bump user motor ID speed upto 300-500Hz, Max speed 650Hz +25% 775Hz.

void HAL_setParams(HAL_Handle handle)
{
    HAL_setNumCurrentSensors(handle, USER_NUM_CURRENT_SENSORS);
    HAL_setNumVoltageSensors(handle, USER_NUM_VOLTAGE_SENSORS);

   //
    // Set some global variables
    //
    motorVars.pwmISRCount = 0;          // clear the counter
    motorVars.speedRef_Hz = 20;       // set reference frequency 
    motorVars.accelerationMax_Hzps = 10.0

Thanks for taking the time to respond.

1 .Motorware is not configured for sue with 280049c so of course I'm using latest SDK for my development and testing.

2. Reduced modulation index is not a concern- I am already aware of this.

3. The filter bug which I've described is real! And it's to do with offset calibration, not run time. Try it and you'll see what I mean.

The ID and offset calibration problems have been resolved. All the things you've mentioned aren't really an issue for me. My issue is with say a lab 6 or 7 AFTER I've already entered in the correct motor parameters in user.h, there is clearly a difference in the current when using 2 or 3 sensors. It's like there is some random noise injected into the sensed current and I'm not sure where it's coming from since the hardware when testing 2 or 3 current sensors is exactly the same, so I suspect it's a software issue but can't quite put my finger on it.

To replicate the issue simply try running your motor with 3 and then 2 current sensor setting. Increase the Id/Iq current controller Kp gain to exacerbate the noise and you should be able to hear it with the 2 current sensor setting.

Hani Chahine said:

of course I'm using latest SDK for my

Ok, confused as you wrote (main.c) and I can't locate (any labs.c). Only (labs.h) exist, the error object you show in yellow is not found. That is why I posted the HAL_SetupParams() above as CTRL+click does not find the yellow object. It must be CCS hidden inline object in an labs.h file?  

Hani Chahine said:

. It's like there is some random noise injected into the sensed current

Motor has PWM sputter noise lab 5 via EST_STATE_Online and during EST_STATE_LC (vibration/noise) starts <350Hz. Seems to be worse vibration via EST_TRAJ_STATE_Online (<350Hz) speed, vibration smooths out 5.1Krps. The noise seems to be PGA's related motor transients allows noise into Online system. We have Booster on site2 at some point to test RC filters. Schematic shows 330pf caps (DNP) and user guide states RC do exist site 2. I have not confirmed this since BoostXL-DRV8320RS now sits over J5-J8 headers where RC are said to exist.      

Hani Chahine said:

2. Reduced modulation index is not a concern- I am already aware of this

If you call 100% modulation SDK index algorithm even from 3 current sensors good. We are still waiting for ROM transforms to produce near sinusoidal PWM drive. The point of SVPWM is to produce duty cycles with sinusoidal artifacts from Clarke/Park. ROM transforms 6 inputs (Iq/Vd) seemingly need to be modified via open source loaded into flash. However open source ROM calls was not included in SDK as stated FOC InstaSpin SPRUHJ1H–January 2013–Revised June 2019. Perhaps ROM will allow 2 (Id/Vd) inputs configured for a NULL value.  

This bug you mention above post is found in the labs (is0x_mylab.c) used for the voltage filter. Nice find Hani!

//!< the handles for the current offset calculation
FILTER_FO_Handle  filterHandle_I[USER_NUM_CURRENT_SENSORS];
//!< the current offset calculation
FILTER_FO_Obj     filter_I[USER_NUM_CURRENT_SENSORS];

//!< the handles for the voltage offset calculation
FILTER_FO_Handle  filterHandle_V[USER_NUM_CURRENT_SENSORS];
//!< the voltage offset calculation
FILTER_FO_Obj     filter_V[USER_NUM_VOLTAGE_SENSORS];

Yet the offset voltage filter patch did not help the Est_State_Online random PWM inverter sputtering. This 12 pole motor speed has to keep >550Hz to reduce PWM sputtering. Speed <500Hz reminds me sound of a 2 cycle motor idle. Oddly commutation angle plays some part of undesired random sputtering.

Hi Hani,

Thanks for finding the bug, I will fix it in the latest motorControl SDK. Could you post some captured current waveform with the oscilloscope to show the noise that may help us to analyze the problem? Is the noise on the DRV8320RS board or on your own board? And what identification state has this noise?

For motor identification, you have to tune the identification variables (current and frequency) based on your motor as mentioned in instaSPIN lab guide.

Hi,

Yanming Luo said:

Could you post some captured current waveform with the oscilloscope to show the noise that may help us to analyze the problem?

I don't have any scope captures available right now but you can see additional noise on Id/Iq signals.

Yanming Luo said:

Is the noise on the DRV8320RS board or on your own board?

This is on the DRV8320RS board + 49C launchpad.

Yanming Luo said:

And what identification state has this noise?

You're confusing the ID issue with the 2 current sensor noise issue. My ID issue was related to the offset bug as described above. I have no issue with ID after sorting out offset bugs.

Regarding the noise problem, it should be very easy to replicate this issue as the hardware is the standard EVB.

1. ID your motor.

2. Increase current controller bandwidth (maybe 10x higher or more).

3. Run the motor with 3 current sensors and observe noise.

4. Change to 2 current sensors and run again with everything else exactly the same.

You should see a difference in acoustic noise and behavior.

That's right. The current controller bandwidth can't bet set to very higher, which should be related to the motor and ISR frequency. Any noise if you don't change the default parameters?

Yanming Luo said:

That's right. The current controller bandwidth can't bet set to very higher, which should be related to the motor and ISR frequency. Any noise if you don't change the default parameters?

My unique application requires higher current controller bandwidth to be set - I understand this would have the effect of amplifying any noise.What I I don't understand is why the increased noise is much much worse when selecting 2 current sensors versus when we are using 3. There is still some perceived loss in performance (stability) and even some noise difference when testing 2 current sensors verses 3 even at normal current gains. Something is inherently different and I can't understand why. Please test for yourself.