Cannot reach max RPM

Hello Chris,

Thank you for your quick reply!

1)  I took care of this issue by wiping out the if/else statement and just defining IQ_Freq to 1100

2)  Is there a way to decrease the USER_ADC_FULL_SCALE_VOLTAGE_V?  I would like to continue using this dev board because it has the MCU that I plan on going into production with.

3)  The Rs/Ls measurements seems to be dependent on the USER_MOTOR_RES_EST_CURRENT and USER_MOTOR_IND_EST_CURRENT values.  I know that it is recommended 10% full scale but that seems vague when it is determining values that are so critical.  Per the spec sheet the motor Rs/Ls is 0.027/0.0000055 = 4900 Hz..  But this is not what the system is measuring (Maybe the ADC resolution issue).

4)  I am going to change the voltage supply to 15V and make the adjustments you recommended to evaluate performance increase this evening.

5)  I reviewed the other eval board you recommended and the main difference I see is that is has a 60MHz clock vs 90MHz in the 69M.  I would prefer to get the benefits with the MCU of our eval kit and figure out a way to achieve better ADC resolution.

6)  Would it be possible for you to put me in contact with a local FAE?  We are looking into taking this design into production by the end of the year and need a rep to discuss our schematic with.  

7)  Your expertise and assistance is greatly appreciated and I cannot thank you enough!

Best,
Jonathan 

couple quick comments before I need to run

Jonathan Azevedo said:

2)  Is there a way to decrease the USER_ADC_FULL_SCALE_VOLTAGE_V?  I would like to continue using this dev board because it has the MCU that I plan on going into production with.

See SPRUHJ1 chapter 5.  You can change the scaling range just by dropping an approprite resistor onto the voltage sense circuits.  This will give you the biggest improvement. 

3)  if the R/L of the motor is > 2000 you MUST use proj_lab02c to ID the motor. period. 

as RoverL state is finished please look at the controller_obj variable RoverL and post the value.

with the DRV8301 EVM we still see some current sampling issues with motors like this...the BOOSTXL-DRV8301 gives significantly better results.

5) The main benefit is on the BOOSTXL-DRV8301 board. It's just superior and scaling and current sensing layout....good data in = good control.

6) possibly, but the local FAE won't have more knowledge than we do here to be honest with you.  If you use a distributor like Arrow or Avnet that will be your best bet for schematic review.

7) you're welcome

Hi Chris,

Great news, it seems to have been a resolution problem, as you thought!  I am now able to operate the system 21krpm+.

Are there any tricks to smooth out the start up to get rid of the little jerk and increase torque at low speed?

The identification of the motor is now R/L = 0.013927/4.6688E-6

I wouldn't imagine to find anyone more knowledgeable than you on this topic after reading hundreds of your postings.  Mainly just want some local TI support down here in which we are not getting...

With that being said, would you mind taking a look at the attached schematic to make sure there are no obvious mistakes or if we could do something to improve current sense for the system?

4087.ADEX_BLDC_Rev0_Schematic.pdf

Have a great weekend!

Best,
Jonathan

Hi Chris,

We updated the current sensing portion of the schematic to add an opamp on the third phase.

I looks like the both the DRV8301 and DRV 8303 are only sensing two phases.  The 69M kit does not add any discrete hardware to add sense to the third phase.  However, it appears that they do add this third phase sensing on the boostxl board.

Is this why you mention that the board is superior?

5342.ADEX_BLDC_Rev0_B_Schematic.PDF 

Thanks,
Jonathan

The DRV8301 IC only has 2 on-chip amplifiers.

On the DRV8301 EVM, for the MotorWare projects we actually use the currents that bypass the DRV8301 amplifiers entirely and only use the off-chip OPA.

On the DRV8301 BOOSTXL-DRV8301 we use the two on-chip amplifiers for phase A and B and use a single off-chip OPA for phase C.

Jonathan Azevedo said:

Is this why you mention that the board is superior?

No. The layout of the EVM current sampling is non-ideal.  The amplification is done near the shunt and then long traces are run to the ADC input pin.  This is causing issues with the phases picking up noise, even from each other.  It really limits the PWM frequency you can run (higher is worse on this board) and the maximum modulation (gets much worse as your sampling windows get smaller at high speed).

The BOOSTXL has a superior current sense layout with the amplification done as close as possible to the MCU (which is on the mother board).  When you make your own single PCB it is best to get the signals even close to the MCU ADC pins before the opamps if possible.  This is harder to do with 2 of those amplifier are in the DRV8301 IC which is going to be closer to the FETs.....

Chris,

Thank you for the explanation of the differences between the two boards.  I have been able to find the schematic and layout of the BoostXL-DRV8301 but cannot locate for the DRV8301-69M-KIT.  Could you please help me track down the schematic as I need to decrease the ADC voltage feedback from 66.3V to 10V and also trace GPIO to headers.

I have been probing around the board and have been able to find the 95.3k resistors for phase's A and B, but no luck for C.  Maybe this board does not sense across all three phases?  This is where the schematic would be extremely helpful.

Thanks,
Jonathan 

I have still not been able to find the schematic, but did find some of the questions to my answers embedded within the motorware documentation.

Just wanted to keep others informed if they are looking for the same information ;)

the schematics for the DRV8301 are kept in controlSUITE to keep MotorWare as small as possible (and not duplicate content)

C:\ti\controlSUITE\development_kits\DRV830x-HC-C2-KIT_v105\~DRV830x-HC-EVM-HWdevPkg\DRV830x_RevD_HWDevPKG

if you run MotorWare.exe it explains this and points to this location

Chris,

I was able to locate the 3 R_vu's and replace them with 15k resistors, as to provide a ADC FULL SCALE of 13.22V. The C_v caps were not changes, so the voltage filter is now different.

The following scaling was adjusted for in user.h:

#define USER_IQ_FULL_SCALE_VOLTAGE_V (9.8)
#define USER_ADC_FULL_SCALE_VOLTAGE_V (13.22)

 Issues:

The calculated bus voltage is now reporting just over 1V.  The controlCard is also getting extremely hot.  Not sure if this is a related problem or not, but it is concerning.  The MCU is too hot to even touch.

The one thing a am pretty sure of is that the hardware change was successful.  I suspect this because if I change the ADC full scale voltage back to the default the voltage bus shows the correct value of 9.8V.  We are also able to run the motor.  The interesting fact is that we are now capped at a speed of 16.5k, where we were well north of 20k prior to the resistor change and running at 24V.

Thanks,
Jonathan

it looks like you didn't make the same change to the reading of the Vbus voltage. It also needs to have the same scaling.

and then recalculate the filter pole and update that in user.h

you want to keep this filter pole reasonable small, under <500 Hz is preferred and ideally just greater than your max frequency / 4, but certainly keep it under 700 Hz.

Hi Chris,

Thanks for all of your support in the past. We have our custom motor controller board completed and are in the process of identifying and tuning the motor control. I'm following up on this thread because it is the same motor and schematic which you reviewed in the past.

We're having difficulty spinning at high rpm (>10krpm) and have a few follow up questions for you. There is a little more noise than I expected in the measured current signals. Do you have any example scope shots of the measured motor phase voltages and currents that I can use as a reference?

We're able to use the lab_02c to identify the motor parameters, but once identification is complete and we re-enable the motor and command a particular speed, it is unstable. How are the gains changed from the identification phase to the on-line phase?

We would very much like to tune the FAST current loop in real-time on a scope, as described in lab_05a. Where is the reference trajectory set in the project code? I'd like to be able to drive the reference current and tune for different step and sine waveforms. Will I be able to measure the reference signal as an output on my scope? Also which current signal should I measure for tuning purposes? i.e. phases A, B, or C?

Does the DRV-8301-69M dev kit use an internal or external oscillator? And do you see a performance difference at high speeds?

Thanks again for your support!

Best regards,

Chris

Also, one other question, what is the difference between the Iq and Id signals, and also the Kp_iq and Kp_id gains.

Thanks,

Chris

Hi Chris,

Another question that just came up is what's the difference between the CTRL_setKi and PID_setKi functions? I see that in some examples both of these constants are set, but in other examples, only the CTRL_setKi gains are set.

I'm trying to modify lab_04 to simply drive a reference current signal, and adjust the Kp and Ki gains to tune my controller. But it seems that the gains are being updated elsewhere in the software, perhaps during some automatic identification. What do you propose to disable all of this other functionality and create a simple program to tune the current gains?

Thanks,

Chris

Chris Lightcap said:

There is a little more noise than I expected in the measured current signals.

Remind me about your motor, attach the user.h.

Your HW is based on BOOSTXL-DRV8301?

Chris Lightcap said:

Do you have any example scope shots of the measured motor phase voltages and currents that I can use as a reference?

There are scope shots in SPRUHJ1, but not of high speed. I posted some high speed (4 KHz) scope shots using DRV8312 recently:

http://e2e.ti.com/support/microcontrollers/c2000/f/902/p/339361/1242590.aspx#1242590

Chris Lightcap said:

We're able to use the lab_02c to identify the motor parameters, but once identification is complete and we re-enable the motor and command a particular speed, it is unstable. How are the gains changed from the identification phase to the on-line phase?

1. proj_lab02# is only for motor ID, it shouldn't even run the motor after ID.

2. Once you start up a motor using the user.h values the speed controller gains are set to the default. Recall that these are NOT tuned.  You have to auto tune them.  During ID the speed controller is not tuned either, most of it is running under an open loop strategy and we slowly close the torque loops.

This is from a workshop I'm running.

Chris Lightcap said:

Where is the reference trajectory set in the project code?

The trajectory output is calculated from the starting speed, ending speed, acceleration, and trajectory frequency of operation.

from ctrl.c

void CTRL_setup(CTRL_Handle handle)
{
  CTRL_Obj *obj = (CTRL_Obj *)handle;

  uint_least16_t count_traj = CTRL_getCount_traj(handle);
  uint_least16_t numCtrlTicksPerTrajTick = CTRL_getNumCtrlTicksPerTrajTick(handle);

  // as needed, update the trajectory
  if(count_traj >= numCtrlTicksPerTrajTick)
    {
      _iq intValue_Id = TRAJ_getIntValue(obj->trajHandle_Id);

      // reset the trajectory count
      CTRL_resetCounter_traj(handle);

      // run the trajectories
      CTRL_runTraj(handle);
    } // end of if(gFlag_traj) block

  return;
} // end of CTRL_setup() function

Chris Lightcap said:

I'd like to be able to drive the reference current and tune for different step and sine waveforms. Will I be able to measure the reference signal as an output on my scope?

You'll have to add your own Traj module to do this. Currently in proj_lab05a you are directly commanding the IqRef_A to the input of the Iq PI controller.  So you are setting a step input only.  If you create your own front end Traj you can shape this input. It's very useful in a practical applciation of a torque control system anyways, like an e-Bike.

Chris Lightcap said:

Will I be able to measure the reference signal as an output on my scope? Also which current signal should I measure for tuning purposes? i.e. phases A, B, or C?

you could take any of your data and put it out on PWM DAC pins.  If you have a current probe that is always preferred. Very useful if you are doing power electronics, I highly recommend purchasing one.  This allows you to just loop around any phase wire and get a view of the current in real-time.

Chris Lightcap said:

Does the DRV-8301-69M dev kit use an internal or external oscillator? And do you see a performance difference at high speeds?

We are using the internal oscillator on the controlCARD. The OSC can drift with temp, so you need to run the OSC calibration/compensation for full robustness.  If the clock drifts you will see a drift in the speed estimates.  But that's pretty minor and not related to how fast your motor is going.. I would say what you are seeing is related to quality of the current sample.

Also, one other question, what is the difference between the Iq and Id signals, and also the Kp_iq and Kp_id gains.

Iq is the torque component and Id is the field component of the D-Q co-ordinate system (the DC co-ordinate system that we transform into from 3-ph to 2-ph (CLARKE)  and 2-ph to DC (PARK).

In a standard current control system the Kp and Ki values for these two PI controllers can generally be set the same for good performance.

what's the difference between the CTRL_setKi and PID_setKi functions?

the PID structures are members of the CTRL, so using CTRL_setXXX passes the values into the CTRL system where they are set. Using PID_setXXX can pass them directly.

I noticed we are only doing this in proj_lab02x in the recalcpKpKi function, and we actually pass the value through CTRL and then also PID.....hmmmmm.  I'm not really sure why we are doing that, let me check.

You'll notice in updateKpKiGains() function we just pass through the CTRL system, which is my recommendation.

I'm trying to modify lab_04 to simply drive a reference current signal, and adjust the Kp and Ki gains to tune my controller. But it seems that the gains are being updated elsewhere in the software, perhaps during some automatic identification. What do you propose to disable all of this other functionality and create a simple program to tune the current gains?

proj_lab04 does not interface to the CTRL_setKxxxx or PID_setKxxx functions.  Use proj_lab05a for Torque control with the functions that interface with the Iq and Id PI controllers.

Hi Chris,

Thanks for the feedback.

Hardware is based on the BOOSTXL-DRV8301.

I've attached our user.h file for you to review.

Our scope shots definitely look nothing like your clean sine signal. You can see the PWM switching in our signal. Should we add a cap on the output to smooth the current sense signals? Also I noticed in the other forum that you recommended adding an external inductor. Would you recommend the same for our case considering that we're using a 5.5uH inductance motor? It would be difficult to add this in-circuit at this point, but would it be possible to add them in series with the motor phases?

I'll try project lab05a to set the current/torque reference signals.

Best,

Chris

user.h

It looks like you set this based on your IQ_FREQUENCY of 1100 / 4

#define USER_VOLTAGE_FILTER_POLE_Hz  (275.00)

this pole needs to actually match the HW pole of the voltage filter as described in SPRUHJ1 Ch 5

your decimation wasn't correct. For 90 MHz F2806x and 60 MHz PWM try this

//! \brief DECIMATION
// **************************************************************************
//! \brief Defines the number of pwm clock ticks per isr clock tick
//!        Note: Valid values are 1, 2 or 3 only
#define USER_NUM_PWM_TICKS_PER_ISR_TICK        (3)

//! \brief Defines the number of isr ticks (hardware) per controller clock tick (software)
//! \brief Controller clock tick (CTRL) is the main clock used for all timing in the software
//! \brief Typically the PWM Frequency triggers (can be decimated by the ePWM hardware for less overhead) an ADC SOC
//! \brief ADC SOC triggers an ADC Conversion Done
//! \brief ADC Conversion Done triggers ISR
//! \brief This relates the hardware ISR rate to the software controller rate
//! \brief Typcially want to consider some form of decimation (ePWM hardware, CURRENT or EST) over 16KHz ISR to insure interrupt completes and leaves time for background tasks
#define USER_NUM_ISR_TICKS_PER_CTRL_TICK       (1)      // 2 Example, controller clock rate (CTRL) runs at PWM / 2; ex 30 KHz PWM, 15 KHz control

//! \brief Defines the number of controller clock ticks per current controller clock tick
//! \brief Relationship of controller clock rate to current controller (FOC) rate
#define USER_NUM_CTRL_TICKS_PER_CURRENT_TICK   (1)      // 1 Typical, Forward FOC current controller (Iq/Id/IPARK/SVPWM) runs at same rate as CTRL.

//! \brief Defines the number of controller clock ticks per estimator clock tick
//! \brief Relationship of controller clock rate to estimator (FAST) rate
//! \brief Depends on needed dynamic performance, FAST provides very good results as low as 1 KHz while more dynamic or high speed applications may require up to 15 KHz
#define USER_NUM_CTRL_TICKS_PER_EST_TICK       (1)      // 1 Typical, FAST estimator runs at same rate as CTRL;

//! \brief Defines the number of controller clock ticks per speed controller clock tick
//! \brief Relationship of controller clock rate to speed loop rate
#define USER_NUM_CTRL_TICKS_PER_SPEED_TICK  (20)   // 15 Typical to match PWM, ex: 15KHz PWM, controller, and current loop, 1KHz speed loop

//! \brief Defines the number of controller clock ticks per trajectory clock tick
//! \brief Relationship of controller clock rate to trajectory loop rate
//! \brief Typically the same as the speed rate
#define USER_NUM_CTRL_TICKS_PER_TRAJ_TICK   (20)   // 15 Typical to match PWM, ex: 10KHz controller & current loop, 1KHz speed loop, 1 KHz Trajectory

This is too high, especially since your motor at 1100 Hz will only produce 6.6V of Bemf

set this to your bus voltage...looks liik you are using 12.x for ADC, so use (12.0) here

#define USER_IQ_FULL_SCALE_VOLTAGE_V      (26.5)

Ok, we made the changes and can correctly identify the motor. But we're not able to use project 5a as you suggested to drive a constant current signal. The current is quite noisy in our setup, did you get a chance to see my other question in the last post?

"Our scope shots definitely look nothing like your clean sine signal. You can see the PWM switching in our signal. Should we add a cap on the output to smooth the current sense signals? Also I noticed in the other forum that you recommended adding an external inductor. Would you recommend the same for our case considering that we're using a 5.5uH inductance motor? It would be difficult to add this in-circuit at this point, but would it be possible to add them in series with the motor phases?"

Thanks,

Chris

what did you change this to?

#define USER_VOLTAGE_FILTER_POLE_Hz  (275.00)

at what RPMs to you start to see issues?  You think this motor will go 22 KRPM, correct?

Also I noticed in the other forum that you recommended adding an external inductor. Would you recommend the same for our case considering that we're using a 5.5uH inductance motor?"

Your user.h says you have a 20A motor, but you have a short circuit current of 159A. That's "over designed" by about 4x.

So you could increase your Ls by 4x and still get the same torque capability with InstaSPIN-FOC.  However, going from 6uH to 24uH won't buy you that much...it would be better if you could get to 50uH+, but then you will reduce some torque performance.

With motors that have THIS little flux and THIS little inductance I would say that a flux based observer and lower shunt sampled current control approach probably isn't the most worthwhile.

It would be difficult to add this in-circuit at this point, but would it be possible to add them in series with the motor phases?

No, that causes probablems with the estimation since the Vph samples are no longer real.

I changed the actual filter pole to

#define USER_VOLTAGE_FILTER_POLE_Hz  (286.830)

We've actually driven this motor to 22krpm with the DRV8301-69M-KIT and a little tuning, so I'm confident that we can achieve this again with our current design.

I'm wondering if we may see a performance improvement running at a much higher PWM frequency, perhaps as high as 80kHz, since this is an extremely low inductance motor. I wasn't able to find the software lab example using a software que to enable faster ISR frequencies. Where can I find an example of this technique?

Thanks again for all of your support!

Chris

Hi Chris,

We're able to get the motor running at roughly 17 kRPM, and are working on improving the low speed performance while loaded. I read through chapter 15 in the instaSPIN motion user's guide, and have tried adjusting my force angle frequency as you suggested in another post:

#define USER_ZEROSPEEDLIMIT (0.01 / USER_IQ_FULL_SCALE_FREQ_Hz)

#define USER_FORCE_ANGLE_FREQ_Hz (2.0*USER_ZEROSPEEDLIMIT*USER_IQ_FULL_SCALE_FREQ_Hz)

The user zero speed limit seems low but it actually works better at lower frequencies (otherwise the motor may jerk several times before starting to spin). I'd like to be able to tune my current and bandwidth gains while looking at a real-time plot. I've tried loading the graph file described in lab_05f, but the graph doesn't scroll when updated so I'm never looking at the most recently acquired data.

1. How do you adjust the graph settings so that it automatically scrolls with new data (I've already set it to auto refresh)?

2. I can view the commanded or reference current IqRef_A, but how can I output my actual current, both in the list of expressions and in a graph? I tried adding Iq_A but this isn't being updated in the code.

3. Do you have any other suggestions for good torque performance at low speeds using the spinTAC controller? How does the FOC controller compare at low speeds?

4. Do you have any examples of achieving RPM higher than allowed from back-EMF using field weakening?

Thank you again for all of your help.

Best regards,

Chris

One more thing to add, I was able to output both IqRef_A and Iq_A as expression in project lab_05f, but at least looking at the expressions list, my current tracking performance looks very poor. I'm assuming that these two numbers should be right on top of each other. I'm very interested in seeing a graphical display in real-time of these values.

Best regards,

Chris

Chris Lightcap said:

I'm wondering if we may see a performance improvement running at a much higher PWM frequency, perhaps as high as 80kHz, since this is an extremely low inductance motor.

I don't think it will help much. The main cause is in getting a valid average current sense sample.

IF you had good values then running PWM at faster frequency CAN help, but I doubt over 60 KHz will make that much of a difference on your HW.

Chris Lightcap said:

I wasn't able to find the software lab example using a software que to enable faster ISR frequencies. Where can I find an example of this technique?

we haven't published this...sometime in 2015 we will publish a que example.

Right now you can only use the user.h decimation settings and keep the effective current/estimator to 15 KHz max for F2802x and maybe 30 KHz for F2806x.

Chris Lightcap said:

The user zero speed limit seems low but it actually works better at lower frequencies (otherwise the motor may jerk several times before starting to spin).

The jerk you see is normal - or at least can happen depending on application - as it's part of the ForceAngle method. The point of force angle logic is to keep a moving angle in the feedback loop to keep trying to get the rotor moving so that FAST can take over and then provide a proper "real" angle. 

Many applications will work better (less jerky) if you disable ForceAngle entirely.

Chris Lightcap said:

I'd like to be able to tune my current and bandwidth gains while looking at a real-time plot. I've tried loading the graph file described in lab_05f, but the graph doesn't scroll when updated so I'm never looking at the most recently acquired data.

do you have the refresh enabled?

Chris Lightcap said:

I tried adding Iq_A but this isn't being updated in the code.

we start pulling this in labs 9 and 10. You can add it to your own project:

// read Id and Iq vectors in amps
gMotorVars.Id_A = _IQmpy(CTRL_getId_in_pu(ctrlHandle), _IQ(USER_IQ_FULL_SCALE_CURRENT_A));
gMotorVars.Iq_A = _IQmpy(CTRL_getIq_in_pu(ctrlHandle), _IQ(USER_IQ_FULL_SCALE_CURRENT_A));

// calculate vector Is in amps
gMotorVars.Is_A = _IQsqrt(_IQmpy(gMotorVars.Id_A, gMotorVars.Id_A) + _IQmpy(gMotorVars.Iq_A, gMotorVars.Iq_A));

Chris Lightcap said:

3. Do you have any other suggestions for good torque performance at low speeds using the spinTAC controller? How does the FOC controller compare at low speeds?

with your really low flux motor you aren't going to get good low speed performance. It takes larger flux (EMF voltage produced @ a Hz) relative to the voltage scale of your hardware.

ex: 0.5 V/Hz @ 2 Hz = 1.0 V Bemf, on a 12V HW this is 8.3 % and will work well.

ex: 0.01 V/Hz @ 2 Hz = 0.02V Bemf, on a 66V HW this is 0.03% and will NOT work well

But yes, a component of good speed control - once you have good rotor feedback - is the tuning of the speed loop. And SpinTAC is superior in this respect vs. PI controls.  It gives better performance, easier to tune, and the tuning works across the entire operating range (no gain staging).

Chris Lightcap said:

4. Do you have any examples of achieving RPM higher than allowed from back-EMF using field weakening?

proj_lab09 is Field Weakening. You can use the "automatic" example, or just provide your own negative IdRef.  Sorry, we haven't finished the lab write-up, but the lab itself works.

Chris Lightcap said:

One more thing to add, I was able to output both IqRef_A and Iq_A as expression in project lab_05f, but at least looking at the expressions list, my current tracking performance looks very poor. I'm assuming that these two numbers should be right on top of each other. I'm very interested in seeing a graphical display in real-time of these values.

are you pulling values inside an interrupt? in our labs we are pulling the values in the background task, so there isn't anything that guarantees they are synchronized. 

your expression list also isn't "keeping up" with real-time data, at least not at the control frequency rate.

to really check this you would need to actually "get" inside the interrupt and datalog all the data and then compare it off-line.

ChrisClearman said:

what's the difference between the CTRL_setKi and PID_setKi functions?