H-bridge driver for a 90VDC motor

Thread Starter

cmartinez

Joined Jan 17, 2007
8,788
Ouch!:(
The problems usually not a current failure (at first) but a voltage one. When you do the reversal the voltage goes high. Once the voltage breaks one it just takes a second......
@cmartinez sounds like a code problem to me. :D
Edit: Might be worth a try to put a BIG TVS across your power supply. It might save you once.
I put one TVS in parallel with each protection diode of each mosfet. Didn't make a difference. Also, the MCU's code is extremely simple and I've already tested it well. I still think that the thing goes nuts when a surge of some sort reaches it.

What's the best way to protect the MCU from transients?
 
Last edited:

Thread Starter

cmartinez

Joined Jan 17, 2007
8,788
Now that I think of it, the MCU is being powered by a wall-wart that outputs regulated 12VDC, which is then converted into 5V by a LM7805 regulator. The wall wart is connected to the same isolation transformer to which the motors are connected.
That is, the wall wart is connected to 120VAC, and the motors are connected to the same supply, via a diode full wave rectifier. That is, the motor is being fed DC from an unregulated 120VAC source.

Is there some possibility that transients are being transmitted to the MCU via the wall-wart through the 7805?
 

ronv

Joined Nov 12, 2008
3,770
I put one TVS in parallel with each protection diode of each mosfet. Didn't make a difference. Also, the MCU's code is extremely simple and I've already tested it well. I still think that the thing goes nuts when a surge of some sort reaches it.

What's the best way to protect the MCU from transients?
Do you have a long delay so the motor stops before it goes the other direction?
 

ronv

Joined Nov 12, 2008
3,770
Now that I think of it, the MCU is being powered by a wall-wart that outputs regulated 12VDC, which is then converted into 5V by a LM7805 regulator. The wall wart is connected to the same isolation transformer to which the motors are connected.
That is, the wall wart is connected to 120VAC, and the motors are connected to the same supply, via a diode full wave rectifier. That is, the motor is being fed DC from an unregulated 120VAC source.

Is there some possibility that transients are being transmitted to the MCU via the wall-wart through the 7805?
Hmm. Are those opto isolators I see? They can be slow.
 

ronv

Joined Nov 12, 2008
3,770
Yes, they are slow... they take about 4us to fully turn on, according to the datasheet... you think that had something to do with it?
It might. Assuming you have the long delay on reversals. Where does the code leave the transistors? For example if it leaves the bottoms on the turn on time may be faster then the turn off time so the first time the top one turns on the bottom may still be on.
 

Thread Starter

cmartinez

Joined Jan 17, 2007
8,788
It might. Assuming you have the long delay on reversals. Where does the code leave the transistors? For example if it leaves the bottoms on the turn on time may be faster then the turn off time so the first time the top one turns on the bottom may still be on.
I see that now... but even if that were to happen, the ir2104 is supposed to protect against cross-conduction.
What would you advice to protect the MCU from transients?
 

Thread Starter

cmartinez

Joined Jan 17, 2007
8,788
It might. Assuming you have the long delay on reversals. Where does the code leave the transistors? For example if it leaves the bottoms on the turn on time may be faster then the turn off time so the first time the top one turns on the bottom may still be on.
And another question, what do you think about my eliminating the RC snubber that I initially placed across the motor?
 

Thread Starter

cmartinez

Joined Jan 17, 2007
8,788
And yet another one. What are C6 and C7 supposed to be doing in this circuit? Can I just do away with them? I don't even know why I put them there in the first place.

Capture.PNG
 

ronv

Joined Nov 12, 2008
3,770
The thing that leads me to the reversal problem is this statement:
Several times during testing, I accidentally let go of the direction button while still pressing the run button, causing it to abruptly change directions... it was on one of those slip ups that suddenly the thing cracked loudly... then more sparks were produced than fireworks in a 4th of July Manhattan night sky ... and caught fire...

Here's what bothers most: that circuit is designed to run two motors, and I had only connected one... But BOTH circuits blew up on me, even though the second one had nothing connected to it.
To me this says one of two things. One of the FETs shorted so when the opposite one turned on it also bit the dust.
Or the top and bottom one were on at the same time. This could happen if the turn on/off time of the optos are mismatched more than the leisure time of the driver.
Maybe two different problems???
It seems the optos should be good at separating the high and low power grounds. Looking at your layout it doesn't look like the micro ground is disturbed by the high power ground.
I have one guess that maybe it's brush noise since it is directional. The snubber might help with that, but it would be better right at the motor.
I had trouble with this on the same project I blew up with reversals. But it was radio controlled so it was sensitive there, but not the micro.
I used this, but they were only 24 volt motors.
https://www.pololu.com/docs/0J15/9
 

Thread Starter

cmartinez

Joined Jan 17, 2007
8,788
And now that I think of it. Those caps would only be useful if the power supply was regulated DC. But in this case it isn't... so away with them I say.
 

Thread Starter

cmartinez

Joined Jan 17, 2007
8,788
This is the waveform being sent to the motor:

Capture.PNG

If I were to place a cap between the brushes, it would be no different from the RC filter that I used at first, and that went up in smoke after a couple of seconds. But what I hadn't thought about, was placing a cap between each brush and the motor's case, as shown in the document that you linked me to:

0J678.300.png

The case itself is connected to physical ground. Do you think that would work?
 

Alec_t

Joined Sep 17, 2013
15,121
Several times during testing, I accidentally let go of the direction button while still pressing the run button, causing it to abruptly change directions.
At that point the motor would act as a generator aiding, rather than opposing, the applied voltage. Hence excessive voltage and current.
 

ronv

Joined Nov 12, 2008
3,770
This is the waveform being sent to the motor:


If I were to place a cap between the brushes, it would be no different from the RC filter that I used at first, and that went up in smoke after a couple of seconds. But what I hadn't thought about, was placing a cap between each brush and the motor's case, as shown in the document that you linked me to:


The case itself is connected to physical ground. Do you think that would work?
I figured it was the resistor that smoked. It wasn't the cap was it?
I think you can see in the sim the power is high in the resistor, but low in the cap.
I'm not sure we ever did resolve if you have the delay in to stop the motor with dynamic brake before it is reversed.
 

Thread Starter

cmartinez

Joined Jan 17, 2007
8,788
I figured it was the resistor that smoked. It wasn't the cap was it?
I think you can see in the sim the power is high in the resistor, but low in the cap.
I'm not sure we ever did resolve if you have the delay in to stop the motor with dynamic brake before it is reversed.
The cap smoked too... but yes, the resistor got way hotter.

I'm thinking about placing a TVS diode across the motor's terminals. Also, the motor was extremely close to the PCB, so maybe that had a lot to do with it. The MCU only went strange on motor startup, so I very much doubt it has something to do with brush commutation, but rather with startup inrush current and its corresponding EMP. The TVS, the grounding of the case, and an increased distance from the PCB (gonna place it 2m away from the board) oughta make a difference. What do you think?
 

ronv

Joined Nov 12, 2008
3,770
The cap smoked too... but yes, the resistor got way hotter.

I'm thinking about placing a TVS diode across the motor's terminals. Also, the motor was extremely close to the PCB, so maybe that had a lot to do with it. The MCU only went strange on motor startup, so I very much doubt it has something to do with brush commutation, but rather with startup inrush current and its corresponding EMP. The TVS, the grounding of the case, and an increased distance from the PCB (gonna place it 2m away from the board) oughta make a difference. What do you think?
You can put one there, but I would put one across the power supply as well so if you get a reversal before the motor stops maybe the TVS will keep the voltage below 250 volts.
 

Thread Starter

cmartinez

Joined Jan 17, 2007
8,788
You can put one there, but I would put one across the power supply as well so if you get a reversal before the motor stops maybe the TVS will keep the voltage below 250 volts.
Yup... that's the first thing I did after you suggested it in your previous post. Now I'm back to re-making the PCB. And this time I've added a 0.1 sec delay in the MCU's program when motion is reversed. Also, I added quick connectors for the fets in case something goes bad again.
 

ronv

Joined Nov 12, 2008
3,770
Yup... that's the first thing I did after you suggested it in your previous post. Now I'm back to re-making the PCB. And this time I've added a 0.1 sec delay in the MCU's program when motion is reversed. Also, I added quick connectors for the fets in case something goes bad again.
Seems like the only thing left might be the timing on the optos. You could probably simulate that to see how it looks.
Is .1 seconds enough for the motor to stop?
 

Thread Starter

cmartinez

Joined Jan 17, 2007
8,788
Seems like the only thing left might be the timing on the optos. You could probably simulate that to see how it looks.
Is .1 seconds enough for the motor to stop?
Yes, the motor stops real quick. And as for the timing of the optos, they're working according to specs. The problem is the MCU's going zombie on motor startup, which is something I'm hoping gets fixed with this changes.
 
Top