Regenerative Braking with DRV8312-69M-KIT & Scaling Down Curves

Hi Philip

I try to understand you question clearly. Some comments below.

1. The term regenerative braking you mentioned means turn on the three high sides or three low sides to do the braking, right? In this case, the thread you attached said you should do this in the MotorWare project yourself and also keeping the FAST observer working. The MOSFETs in the kit should be able to handle the braking current of most 24V motor.

2. Normally high power system and low power system will have it own special characteristics in motors, hardwares and algrithm. I think a simple scale down will not be enough for understanding and controling. 

Could you show your application or goals?

Best regards,

Hi Wilson

I am relatively new to this field, so I'm not familiar with the terms "three high sides/low sides". What I mean by regenerative is that the motor acts as a generator and returns power back into the line. Is this possible hardware-wise for DRV8312-69M-KIT? Do I need to modify the 24V DC power supply input to the kit to allow power to flow in the reverse direction?

My goals as mentioned in my original post would be to do a small scale experiment of an EV following a drive cycle. I am trying to implement a new power management strategy with a battery and ultracap. I have posted further details (actually another question) about the new strategy in another thread here

http://e2e.ti.com/support/power_management/non-isolated_dcdc/f/196/t/366354.aspx

So the goal would be to prove the new strategy is better than existing strategies. The motor would help realize this goal.

Philip,

Answer to first question is straightforward; the 3-phase H-bridge topology which has 6-MOSFETs/IGBTs with anti-parallel diode is inherently capable of regenerative braking and allows power flow in reverse direction. It means while braking, kinetic energy of motor can be used to charge the DC side capacitor or battery.

Answer to second question is quite complex. One must have system expertise to know and understand the mathematical relation to derive speed-torque-time characteristics based on various factors such as mass, slope etc. you mentioned in post. You may try to post this query in C2000 Insta-spin forum to check if some expert from there is able to answer this question.

My suggestion is to start assuming linear reduction as you have already thought and while doing experiments, you may learn and get better understanding of system to fine tune it further.

Best Regards

Milan-Motor Applicaiton Team

So the DRV8312-69M-KIT can be run in regenerative mode right out of the box, hardware-wise?

All I need to do is replace the 24V wall socket power supply with a battery/ultracap, and then write the software in Motorware, and it should be fine?

Phillip,

Yes that's right, DRV8312-69M-Kit can be used in regenerative mode from hardware perspective.

Use caution initially, as you might hit over-voltage at DC side battery/Cap input if deccelration rate is too fast i.e. when motor is brake from higher speeds to zero speed suddenly. Note that DRV8312 does not have over-voltage protection  so voltage above absolute max may damge the device.

All the best for your experiment.

Best Regards

Milan-Motor Applicaiton Team

 

Ok, thanks for your answer.

Just to check, what is the absolute maximum that the DRV8312-69M-Kit can withstand? 24V?

Hello,

I am trying the DRV8301 kit with the F28069M board. In current mode when I switch direction the dc Bus voltage rises, indicating that the motor's kinetic energy is returned to the power supply. However I want to limit the maximum dc bus voltage.

Is there any hint about how the overvoltage protection can be applied, initially just in software? Is there an easy way to inform the controller (CTRL) about it so that it keeps the dcbus voltage under the limit?

When the limit is reached I could either completely disable the PWM, i.e. no mosfet is conducting, so that the motor coasts, or I could connect all motor windings together, i.e.  have all low-side OR high-side switches on.
 The second case would definitely be faster, but I suspect the motor and/o mosfets could overheat.

Any info is appreciated.

Giannis

there is not an easy / automatic way to do this. you would have to add a control loop which monitors the Vbus and makes a correction to the IqRef_A command to limit voltage change in the output.

Hi Chris,

I tried reducing or even zeroing the Iqref command when Vbus rises above a threshold, but still the voltage rises. I am suspecting that because of the flyback diodes inside each mosfet the power stage acts as a rectifier from the 3-phase BEMF to the Vbus, regardless of whether the mosfets are driven or not. When the mosfets are not driven (PWM disabled, all Vgs=0), they can still conduct through their body diodes current in the direction that charges Vbus, they merely drop the voltage by the voltage drop of the diodes. Thus I conclude that the only way to limit Vbus rise (apart from a braking resistor between Vbus and GND) is to short-circuit the coils by driving all phases high or low simultaneously. If all are driven low then the current can be measured (Rsense on the low-side) and maybe controlled by limiting the duty cycle of the low-side mosfets, but still, the way I see it I will have to choose between two evils, one is VBus rising to dangerous levels, the other is the coils and power stage overheating from too much current.

I really wish there is something I am missing here. Any hints appreciated.

Giannis

Giannis,

I would like to calrify that when motor is driven at given Vbus, its back-emf magnitude is alwyas lesser than Vbus becuase of stator impedance drop. So if you coast the motor by turning-off all the Fets, motor will coast and there is no way freewheeling doide can charge the Vbus via back-emf, becuase it is lesser. You may see an spike across Vbus at moment of coasting due to motor inductive engery kick-back, but this spike should die down fast and it will not keep chanrging the Vbus continously.

On the other hand, if you try to brake the motor , by reducing the Iqref from some postive value to zero or negative, you will see VBus pumping contisouly becuase FET swtiching and free-wheeling doide provides boosting action for back-emf, in this mode 3-phase bridge rectifier works as boost converter and even though back-emf is lesser, it charges the Vbus.

To aviod Vbus charging, I would suggest to coast the motor or reduce Iqref ramp very slowly from high to low, both will result in increasing motor braking time.

or as you have found out correclty, dissipate the back-emf energy by turning on all  bottom or top fets.

Best Regards

Milan-Motor Application Team

 

Hi Milan and thank you for the detailed explanation.
I understand that keeping all mosfets from conducting and coasting the motor is a solution to Vbus overvoltage.
However, it is not clear to me why zero current is not the same, since this would tell the controller to not allow any current between the motor and Vbus. Doesn't zero current correspond to zero torque, i.e. coasting?

Thank you in advance,
Giannis

I realised that the encoder in my setup was not working correctly and that caused the motor to actively brake even when the current command was zero.

After fixing the encoder problem a zero current command does not cause an increase in Vbus,

I have implemented a simple linear scaling of IqRef as Vbus gets above an overvoltage threshold, which reaches zero at a maximum allowable Vbus level and it seems to work well, not letting Vbus rise much above the maximum limit. Actual deceleration is dependent on the capacitance available on the Vbus, i.e. its ability to absorb energy from the motor with as little voltage increase as possible.

I am wondering if there is an easy way to shortcircuit the motor windings by turning all High or low-side switches on simultaneously, but in a controlled manner, i.e. keeping the current within a limit to protect the motor and swtiches.

 Giannis Roussos:

Thanks for letting me know the actual issue, yes you are right, reducing Iq_ref from positive command to zero should not create the dc-over voltage issue. Over-voltage will starrt, if Iq-ref goes negative and speed is still in same direction.

DRV8301 provides Cycle By Cycle Mode current limit mode. This can be used for high-side or low-side all  swtich contrlloed turn on braking impelementaiton.

Best Regards

Milan-Motor Application Team

Hi Milan,

thank you for the hint, I had this in mind, however the cycle-by-cycle overcurrent detection of DRV8301 is described as a protection feature only, not suitable for current regulation. Plus, changing the current limit requires communication through SPI. If, on the other hand a constant current limit is used then the motor may be braking harder than what the current Iq_Ref commands it to.

Would it be possible to achieve a similar result via applying a non-zero direct current component to the controller via IdRef_A ? I know Id is used for online Rs estimation in FAST, would adjusting IdRef_A interfere with this?

Giannis,

Cycle-by-Cycle current limit will be able to provide the peak current regulations during braking operation, so in a way it is still current control. Of-course it does not exactly provides average current regulation, as achieved by Iq and Id PI controllers.

I do not detail understanding of FAST algorithm so I will not be able to comment on zero-Idref query. It would be good I you raise this query on C2000 Insta-spin Forum, to get right answer to this query.

http://e2e.ti.com/support/microcontrollers/c2000/f/902

Best Regards

Milan-Motor Application Team

Hi Milan,

I meant that cycle-by-cyle seems to be better suited for safety limiting rather than active regulation.

I will ask the question about FAST in the suggested Forum.

In any case, can you comment on whether a non-zero Id will provide the required energy dissipation from Vbus to keep the voltage from rising, without affecting the torque produced by the motor?

Giannis Roussos,

Hmmm, this is complex question  and frankly I don’t know the answer if injecting positive Id will prevent DC-voltage overvoltage. But definitely positive Id won’t affect the torque because torque will only be produce by current component 90deg to rotor flux.

Best Regards

Milan-Motor Applicaiton Team

Hi,

I have the same problem of rising voltage using launchxl with boostxl, As giannis write, a method could be a barking resistor. I am new to this subject and I can't find concrete examples on the web. So I have some questions about it.  The following Image explain how I will implement the solution.

Vin goes to the power supply Vout to the Boostxl, CTRLin is for voltage measurement and CTRout is the signal which drive the Mosfet (the MOSFET driver is not drawn).

Will this idea work or it will affect the correct working of the motor driver/control?

If this idea will work I want to tries two different way to control the switching:
- control with Schmitt trigger
- control with MCU, PWM switching

Which is the better way to implement the switching control?
where can find some hint to implement the second method?
Which driver from Texas would you suggest to drive the low side MOSFET?

Any comments are welcome

Enzo

Enzo,

Yes the concept proposed by you is standard industrial practice to prevent over-voltage during motor braking, so its going to work.

Impelementation: I would suggest to go with MCU based apporoach to detect the over-voltage and turn on the M1. Instead of PWMing M1, you can also try simple on-off hysteresis control. Turn on M1 when VDC exceed thersold and turn off when Vdc falls another lower thesold. You will have to choose proper power rating for braking resistor.

For low side drivers, look for UCC27x series gate drivers from TI portfolio. http://www.ti.com/lsds/ti/power-management/gate-driver-products.page

Best Regards

Milan-Motor Application Team

Hi Milan,

Thank you for the hint. A control with the hysterisis seems to be very simple, I will begin with that.
I didn't understand which is the 'best' method to do the control. Has PWMing M1 advantages? which PWM frequency? wich control frequency?

Regards

Enzo

Enzo,

PWM method will provide contant switching freqency vs hyteresis control, but it would need analysis to come out with exact solution. Frankly, I never worked on this before and also  could not find any application note so I will not be able to guide you further on this.

Best Regards

Milan 

In searching for braking capabilities of the DRV8312 I stumbled across this thread, and I have actually just gone through what you're asking about, Giannis.

You're right that holding all low-side FETs on (or all high-side FETs on, I believe) will not increase Vbus voltage. All the energy from the motor is dissipated by the the resistance in the motor leads and FETs (and any current sense resistor in the way). I bet the issue you're running in to with the DRV8312 is that it's cycle-by-cycle current limiting effectively PWMs the FETs, which allows current to flow through the high-side body diodes.

When you then turn on the low-side FETs, you are effectively applying reverse torque to the motor. When you turn off the low-side FETs (limiting the duty cycle, as you suggest), because the motor is an inductor, the "reverse torque" current you were just applying still has to flow somewhere. It will choose the body diode of the high-side FETs - dumping energy into Vbus for a relatively short pulse before it decays to zero again.

But if your chosen duty cycle and frequency is accidentally "wrong enough" - like mine was at first! - you can easily get into a situation where this reverse torque current doesn't have a chance to decay all the way before the low-side FETs are turned back on for the next PWM cycle. In this case, current is constantly pushed into Vbus - exactly like a boost converter - and the Vbus voltage rises.

It's going to take some experimentation to figure out the right PWM frequency and duty cycle so that you allow the reverse torque current to decay to zero long enough so Vbus doesn't rise, and the low-side FETs are on long enough to brake reasonably quickly but not long enough to burn up themsevles or the motor!

Hope this makes sense!
-Bill