Problem with back-EMF on H-Bridge that blows up MOSFETS - Page 1
Forum section: electronics / projects

author: Yaroooo
author_rank: Regular Contributor
timestamp: September 28, 2020, 09:23:21 am
content: Recently I've encountered a board that create me some problems. It's logic plus motor driver IC and two H-Bridge. Logic have it's own power supply while motor has a +70v DC power supply. Motor is a big stepper motor NEMA 34.The problem is: When I'm running the motor for some time on a test machine, with variable load, after a couple of hours ( or 30min or more ) two or more MOSFET burns out. I don't see smoke or smell burned, but when I probe MOSFET some of them are short between Drain and Source.Replacing them the board works again.After a double check on code and parameters of driver, death-time and current are correctly set. I've tried to check with oscilloscope voltage on VMOT and I found a higher voltage than 70V (power supply regulated) that rise over 160V at certain points. Trying to solve the problem via firmware, like a voltage check, is not reliable for different reasons.A try, that didn't helped, was adding protection diodes on MOSFETs. While D15 is used to protect power supply from all motor drivers Back-EMF connected to the same power supply.Searching on google I didn't find nothing about this. Do you have suggestions on how to eliminate or significantly reduce Back-EMF on this board? Something like a voltage clamp that is usable on an H-Bridge.

author: Yaroooo
author_rank: Regular Contributor
timestamp: September 28, 2020, 09:24:56 am
content: Here're schematics with component models:

author: exe
author_rank: Unknown
timestamp: September 28, 2020, 09:42:40 am
content: I'd like to see oscilloscope pictures. If it's related to back-emf, I'd try to adjust the snubber network a little bit. May be a bit more gate resistance, if possible, to slow down the edges.Disclaimer: I've never dealt with back-emf.

author: ace1903
author_rank: Regular Contributor
timestamp: September 28, 2020, 11:57:30 am
content: Lot of details are missing. When I worked on stepper driver development in situation like this I used pure resistive load for test instead of real stepper.Sometimes someting trivial like masking interrupts in specific part of the code or simply wrong setting for interrupts priorities can cause sudden death when supply voltage is 70v.Another thing is how long stepper is in generating mode and how are you dealing that situation.When you have inertial load that has certain rotational speed and needs to be stopped that energy needs to be dissipated somewhere.Worst case is if needs to be dissipated in switching power supply. Maybe you need to add breaking resistor.But without more details about scope waveforms and wider picture of the sistem we can only make guesses.

author: langwadt
author_rank: Super Contributor
timestamp: September 28, 2020, 12:08:44 pm
content: with D15 and the and back emf getting dumped in C78/C14 if they are not large enough the voltage will rise

author: ultrarunner2018
author_rank: Contributor
timestamp: September 28, 2020, 12:25:58 pm
content: I was also going to suggest changing the values of the R/C snubbers, but also thinking about your protection diodes. What diodes did you use on the mosfets? If you're trying to snub spikes, I don't think a general-purpose diode like the 1N4007 would work. You need something faster, perhaps a Schottky.Another thing I would look at is what MOSFETs you are using. Perhaps the circuit is under-designed. I will take a look at the specs when I get a chance.Finally, about the 'dead-time': Did you actually look at the waveform on the MOSFETs to see whether this is long enough?But please be careful if probing. Be sure you're using 10x or 100x scope probe, never 1x.

author: ace1903
author_rank: Regular Contributor
timestamp: September 28, 2020, 12:35:34 pm
content: C78/C14 are charged from PSU to 70v . When stepper needs to decrease the speed it dumps energy into them increasing voltage up to 160.The energy needed to increase capacitors voltage from 70 up to 160v is E=1/2C*U^2~0,5J.Half a jule is not much, depending of mechanical part of the system.D15 make things worse I think. You are not using capacitors in PSU as storage element.Nema 34 motor ussualy have high L/R ratio and in general when driven from high voltage as 70V very carefull control strategy is needed.ST has good appnotes for strategies to drive steppers. Sometimes it is better to dump induced EMF into transistors and coil resistance instead of using regenerative braking.CNC amateurs ussualy use linear power supplies with huge capacitors and no regulation if regenerative braking is used.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 28, 2020, 01:05:20 pm
content: Show layout.Tim

author: Yaroooo
author_rank: Regular Contributor
timestamp: September 28, 2020, 01:30:32 pm
content: Quote from: ace1903 on September 28, 2020, 12:35:34 pmSo do you suggest to move the diode after capacitors or remove it? I worry about PSU safety in last option ( model of this supply is also variable ).After some tests I've found that MOSFETs burns in deceleration phase or when heavy load is applied.I've read also that SiC need an accurately calculated snubber circuit due fast switching.Maybe a combination of all this things determinate this problem.About RC calculation, since I'm missing some design factors, how I can determinate an "good enough" start point? I suppose that 10nF and 10ohm were placed without any calculation.What about RCD?I've a picture of oscilloscope, but not the one with overvoltage. I'd like to make a list of "Things to Try" before build up again test connection ( unfortunately this week I don't have much time ).

author: ace1903
author_rank: Regular Contributor
timestamp: September 28, 2020, 01:59:34 pm
content: I mostly work as a system architect and embedded software developer. So no SiC experience.Optimizing RC snubber makes sense if you are seeing constant 70 volts and spikes up to 160v.If you are seeing 70 volts gradually go up to 160 when decelerating then I would suggest adding a simple circuit with a brake resistor, zener diode, transistor, and few resistors.The braking circuit lowers system efficiency but happily that only maters in electric cars and huge factories.I first would try this braking circuit to see if that is the problem and later will think more efficient solutions with removing diode or something else maybe.Some switching PSU doesn't like if load is pumping energy into them. So to be on safe side do not remove diode.

author: Yansi
author_rank: Super Contributor
timestamp: September 28, 2020, 02:04:06 pm
content: Where is the decoupling for the two halfbridges my friend?RC snubbers are great, but they are the least important here.//Not probably least, but the fact that C14 C78 are drawn in a different image is a good red flag the layout is more than likely a mess.

author: jmelson
author_rank: Super Contributor
timestamp: September 28, 2020, 02:21:09 pm
content: One big omission in your circuit is diodes to protect the common node (Vs) from going negative. When the half-bridge is sourcing current to the motor's inductance and then shuts off the high-side transistor, that inductance wants current to continue to flow. The body diodes in the FETs are very slow to turn on, so the first thing to conduct is the gate driver chip. You need ULTRA-FAST diodes there, I use the ES3D.Jon

author: Siwastaja
author_rank: Super Contributor
timestamp: September 28, 2020, 02:38:17 pm
content: If there is a possibility that an external force (inertia does not count!) can rotate the motor to higher RPM than the bridge, given its DC bus voltage, is ever able to, onlythenis back-EMF able to generate voltages too high. For this, adding large TVS diodes to the DC bus, that can burn that actual mechanical energy helps, but is expensive. Forbidding (by documentation) such external fast rotation is usual.Additionally, a broken-by-design control side can cause high DC bus voltage even with lower RPM, i.e., the motor is regenerating (in this case, inertiadoescount); then the bridge is able to boost up the fairly low back-EMF voltage at that RPM, so that it exceeds the bridge transistor ratings. The cure is to fix the control so that once the bus overvolts, all FETs are instantly turned off; hence boosting stops, and the DC bus only sees the rectified back-EMF voltage but no more.But, my guess is, this has nothing to do with back-EMF, but everything to do with excessive ringing because of insufficient DC link bypassing and layout. Need to see the layout. RC snubbers may be needed, but bypassing and layout needs to be the first thing to be perfected. Then it's highly likely no RC snubbers are needed after all.What comes to jmelson's suggestion, I've never used diodes in parallel with MOSFETs in motor controllers. I think the claim about the MOSFET body diodes being "very slow to turn on" in unsubstantiated. MOSFET body diodes do have larger Qrr and higher Vf so paralleling with a schottky can bring losses down very slightly (most of the gain can be had by just finetuning dead times), though, but I'm almost 100% sure not using an extra diode isn't the root cause for the problems seen here. It doesn't hurt to add them, but it shouldn't be #1 in the list.

author: Yansi
author_rank: Super Contributor
timestamp: September 28, 2020, 05:26:01 pm
content: Quote from: Siwastaja on September 28, 2020, 02:38:17 pmThat is unfortunatelly not correct. You can make a nasty voltage overshoot even from inertia. The Hbridge works as a 4-quadrant converter, so you can boost the rail voltage even when the motor RPM (BEMF voltage respectively) is lower than the rail nominal.

author: langwadt
author_rank: Super Contributor
timestamp: September 28, 2020, 06:50:46 pm
content: Quote from: Yansi on September 28, 2020, 05:26:01 pmwhihc is what he said in the paragraph you snipped"Additionally, a broken-by-design control side can cause high DC bus voltage even with lower RPM, i.e., the motor is regenerating (in this case, inertia does count); then the bridge is able to boost up the fairly low back-EMF voltage at that RPM,"