I don't know why R2 is there

It's there to protect the IR2104 from possible destruction when the source of M1 gets driven below the negative rail by the M1 drain-source capacitance when M1 switches off.

 

A setback:​

​

I'll be back later with a full report of what happened... but right now I'm going outside to curl into a ball and suck my thumb... call my mamma...

​

And btw, shortbus, I'm going to give very serious consideration to what you're suggesting. Many thanks.

 

Ok, here are the facts:

• After installing the four fets and the right-side driver, I started doing some testing. And everything was going fine, until I noticed that the motor's speed was becoming slightly unstable. Mind me, the MCU was not resetting or anything, but it was the motor itself that was behaving a little strange.
• So I stopped the motor, and tested the fets to see how warm they were. And, sure enough, they were blistering hot!
• I have a temp gun with me, and decided to do another test aiming it at the transistors to see how hot they really were.
• While I was doing that, and after about half a minute of continuous operation at 20% duty cycle, the thing suddenly went WHAM! ... and the high-left fet blew up and even caught a little fire...

So I took the fets and the drivers off the board and did some testing. Here's what I found:

• Neither one of the drivers was damaged. I scoped them without the fets installed (and the 90V power unplugged, of course) and they're doing exactly what they're supposed to be doing. That is, they're delivering a perfect square wave at both outputs.
• The fets on the right side were undamaged too.
• As I've already said, the high-left fet burned, but the low-left didn't. But I tested the low-left fet, and it's "locked" and does not work anymore. That is, both source and drain are now internally fused together, and the fet can no longer do any switching.

After some meditation, here's what I think happened:

• The high-left fet's temperature was so high that it caused a catastrophic malfunction, internally fusing source and drain together and causing a short circuit.
• This short circuit went through the low-left fet too (while the driver thought that it had turned the high fet off, but it had already become short-circuited) and also damaged it.
• But the above effects did not happen due to an internal malfunction on the driver's part, as it did before. Rather, I think that what happened is that once I connected the low-left fet, the driver then had two mouths to feed instead of just one. So less current was reaching each fet's gate, and therefore charging those gates was taking more time, especially since the current had to go through the 715Ω resistors. That made them stay in the linear region far longer than needed. And the unavoidable consequence of that was their overheating.

I arrived at those conclusions because the ir2104 works by switching both high and low fets alternately. So while the left driver was doing its work, the right driver was having a walk in the park. Because the only thing it was doing was keeping the low side fet permanently on, and the high side one permanently off. That's why the right side of the bridge was intact.

This probably wouldn't have happened if I had used a driver that would let me switch each side independently, instead of relying on a single input to do its job. In that case, there probably wouldn't have been any difference if that sort of driver had only one fet connected to it's high side, or if it had both fets connected. Because I could've just left the low side fet turned off permanently while switching the high side one. That's why I'm beginning to lean towards doing what shortbus has suggested.

The ir2104 has two things going in its favor, though. First, it only needs one input instead of two to do its job. And second, it automatically commutates between high and low sides, making the "dynamic breaking" thing automatically for you.

My next step is now going to be to lower the resistor value I used for the gates, but this time with both fets connected to the driver, and test it some more.

It's good that I still have quite a few more of those innocent, virginally pure fets and drivers in store... the poor things don't have a clue of what's coming for them ...

 

Ok, here are the facts:

• After installing the four fets and the right-side driver, I started doing some testing. And everything was going fine, until I noticed that the motor's speed was becoming slightly unstable. Mind me, the MCU was not resetting or anything, but it was the motor itself that was behaving a little strange.
• So I stopped the motor, and tested the fets to see how warm they were. And, sure enough, they were blistering hot!
• I have a temp gun with me, and decided to do another test aiming it at the transistors to see how hot they really were.
• While I was doing that, and after about half a minute of continuous operation at 20% duty cycle, the thing suddenly went WHAM! ... and the high-left fet blew up and even caught a little fire...

So I took the fets and the drivers off the board and did some testing. Here's what I found:

• Neither one of the drivers was damaged. I scoped them without the fets installed (and the 90V power unplugged, of course) and they're doing exactly what they're supposed to be doing. That is, they're delivering a perfect square wave at both outputs.
• The fets on the right side were undamaged too.
• As I've already said, the high-left fet burned, but the low-left didn't. But I tested the low-left fet, and it's "locked" and does not work anymore. That is, both source and drain are now internally fused together, and the fet can no longer do any switching.

After some meditation, here's what I think happened:

• The high-left fet's temperature was so high that it caused a catastrophic malfunction, internally fusing source and drain together and causing a short circuit.
• This short circuit went through the low-left fet too (while the driver thought that it had turned the high fet off, but it had already become short-circuited) and also damaged it.
• But the above effects did not happen due to an internal malfunction on the driver's part, as it did before. Rather, I think that what happened is that once I connected the low-left fet, the driver then had two mouths to feed instead of just one. So less current was reaching each fet's gate, and therefore charging those gates was taking more time, especially since the current had to go through the 715Ω resistors. That made them stay in the linear region far longer than needed. And the unavoidable consequence of that was their overheating.

I arrived at those conclusions because the ir2104 works by switching both high and low fets alternately. So while the left driver was doing its work, the right driver was having a walk in the park. Because the only thing it was doing was keeping the low side fet permanently on, and the high side one permanently off. That's why the right side of the bridge was intact.

This probably wouldn't have happened if I had used a driver that would let me switch each side independently, instead of relying on a single input to do its job. In that case, there probably wouldn't have been any difference if that sort of driver had only one fet connected to it's high side, or if it had both fets connected. Because I could've just left the low side fet turned off permanently while switching the high side one. That's why I'm beginning to lean towards doing what shortbus has suggested.

The ir2104 has two things going in its favor, though. First, it only needs one input instead of two to do its job. And second, it automatically commutates between high and low sides, making the "dynamic breaking" thing automatically for you.

My next step is now going to be to lower the resistor value I used for the gates, but this time with both fets connected to the driver, and test it some more.

It's good that I still have quite a few more of those innocent, virginally pure fets and drivers in store... the poor things don't have a clue of what's coming for them ...

I'll just talk out loud a second. Let's say you are going forward and the top left and bottom left are PWM'ed while the bottom right is just on.
Doesn't that make the sequence drive, dynamic brake, drive?
Edited

 

I'll just talk out loud a second. Let's say you are going forward and the top left and bottom left are PWM'ed while the bottom right is just on.
Doesn't that make the sequence drive, dynamic brake, drive?
Edited

Yes, that's exactly what it does. The sequence looks just like this:

​

In the previous image, Q1 is being PWM, while Q4 is permanentely on. Q2 and Q3 is off. But every time Q1 is switched off, Q2 is switched on, alternatively. So the current being generated by the motor when it's not being fed by the fets goes around it, through Q2 and Q4:

​

In my case, it was Q1 and Q2 that went kaput! ... and the only explanation I have is that they stayed too long in the linear region because the driver couldn't put up with the current being demanded by the gates while they were being switched.

 

Yes, that's exactly what it does. The sequence looks just like this:

View attachment 121763​

In the previous image, Q1 is being PWM, while Q4 is permanentely on. Q2 and Q3 is off. But every time Q1 is switched off, Q2 is switched on, alternatively. So the current being generated by the motor when it's not being fed by the fets goes around it, through Q2 and Q4:

View attachment 121762​

In my case, it was Q1 and Q2 that went kaput! ... and the only explanation I have is that they stayed too long in the linear region because the driver couldn't put up with the current being demanded by the gates while they were being switched.

I'm not sure it is your problem, but I think you want to PWM Q1 while Q4 is on, but when Q1 turns off I don't think you want to turn on Q2. The way it is now if your duty cycle is less than 50% I don't think the motor moves does it? In other words. During the first 1/2 cycle it drives the motor, on the second half it shorts it out. Now you can make the duty cycle 60% and it would move, but...

 

I think you want to PWM Q1 while Q4 is on, but when Q1 turns off I don't think you want to turn on Q2.

I agree. Alternate driving/braking of the motor means that it never gets up to the speed it should, so its current draw is greater than need be. I think that's what is cooking Q2.
Edit:
However, if the BEMF current doesn't go through Q2 drain-source then it would have to go through D2, or the Q2 body diode, instead. So that might just shift the problem elsewhere.

 

I agree. Alternate driving/braking of the motor means that it never gets up to the speed it should, so its current draw is greater than need be. I think that's what is cooking Q2.
Edit:
However, if the BEMF current doesn't go through Q2 drain-source then it would have to go through D2, or the Q2 body diode, instead. So that might just shift the problem elsewhere.

Yeah, I think so.
We need to be careful with the terms I think. The inductive kick would go thru the diode, but the BEMF will still be positive so no current flow. This is if we don't turn on Q2 opposite Q1.

 

I have a board with a fullbridge and ir2004s, that runs a 24V 200W motor at 25kHz, and never had such issues. What transistors are you using?

 

I'm not sure it is your problem, but I think you want to PWM Q1 while Q4 is on, but when Q1 turns off I don't think you want to turn on Q2.

I agree. Alternate driving/braking

This is what I was trying to explain. The driver in use can't control the high side and low side independently. Every time the high is shut down the low turns on(after the internal delay, which can't be regulated, time wise). These drivers were made for convertor use, not motor use. Why would probably work if not using PWM, but the PWM if it exceeds the built in switching delay will allow both mosfets on one side to be turned on.

Since a micro is being used in the circuit, I don't see why the resistance to use an two logic input driver chip? Doing so should be just as easy with a change in code. (says the guy that doesn't understand micros) Ether that or just drop the PWM from the code. Doing that would be a quick way to verify that what I'm suggesting is whats happening.

 

What transistors are you using?

I'm using FDP33N25 n-fets, which are more than capable of handling this task, I think.

​

The way it is now if your duty cycle is less than 50% I don't think the motor moves does it?

The duty cycle at which I tested it was set at 20%, and the motor was moving just fine. Thing is, at that 3.7 kHz, I cannot make the duty cycle any smaller, because the stupid optos that I'm using are way too slow. But that's really not the issue here (I already found the problem, keep reading)

Alternate driving/braking of the motor means that it never gets up to the speed it should, so its current draw is greater than need be. I think that's what is cooking Q2.

However, if the BEMF current doesn't go through Q2 drain-source then it would have to go through D2, or the Q2 body diode, instead. So that might just shift the problem elsewhere.

Exactly, one could leave the motor freewheeling on the off part of the duty cycle, but I've found that rpm's are far more stable if one does uses dynamic braking during operation, as previously described. Besides, the current during this part of the cycle goes through the motor, Q2 and Q4. But the fets are not the ones dissipating that power, but rather the motor's windings instead. So it's the motor that heats up a little. But this issue is now almost actually moot, because of what I'm going to do now.

I've reconnected everything now and done some testing, but without applying high power.

This is what my scope shows at the low-side fet's gate when the driver's pulsing it:

​

As you can see, the duty cycle is around 20% (remember it's low-side, so the shown duty cycle is actually the complement of the real one). As I was saying, I can't make the duty cycle any smaller due to the sucky optos that I'm using. But that's gonna change, because I've already ordered a few HCPL-9030-000E digital isolators, which are far faster than optos.

Now, let's take a closer look at the rise and fall times of that signal:

​

During rise (right side of the trace), it's taking about 5 µs for the gate to reach at least 2/3 of its full charge, and about 8 µs for its full potential. And during fall it takes a very similar amount of time. And the culprit for this has to be the 715Ω resistor that I put at the gate. And that resistor is the one that fixed the horrible EMI responsible for the MCU's spurious resets. So that resistor has to stay, and I can't make it any smaller.

Now, what does the ir2104 datasheet tell us about the "leisure time" (I prefer using that term instead of "deadtime" ) when switching between high and low side?

It says that it uses only about 1/2 a microsecond for that! So there was a period of about 7.5 µs during switching in which the ramp-up and ramp-down of the high and low side gates were overlapping... that explains why the fets were heating up, and also the freaking SHORT CIRCUIT!, the WHAM!, the BANG!, the BUZZZZZ, the SPARKS, the MELTED PINS AND ALL!!!!

​

So yes, @shortbus, this is definitely not the appropriate chip for this application.... boy, am I glad I thought of that... . Seriously man, thanks for your input and for sticking to this thread. I have a few ir2101's laying around that allow for independent side switching. I'll now be using those instead.

So now I'm going to draw, and print, and etch, and drill, and assemble, and solder yet another PCB. And then I'll do some more programming. Then I'll do more (hopefully successful) testing, and come back here with my results.

Thanks everyone, you've all been great help.

 

I think it would be better to get the gate resistors way down so that the deadtime is appropriate to teh switching time of the fets, and get better filtering. Especially of the high voltage rail, you should have some beefy low esr caps as well as some film caps to get the noise down. Higher operating frequency will help you as well.

 

I used the circuit from Tahmids blog and used the ECCP module example for the motor commutation.
Tahmid's blog: Using the high-low side driver IR2110 - explanation and plenty of example circuits
At 5Khz.
I just used MOC8106 for logic signal isolation.
Max.

 

Would optos even be needed? The gate drivers are isolated to around 500V to 600V depending on the model. Maybe a couple of ferrite rings on the ribbon cable, like they use on computer cables?

Glad my pea brain finally helped you cm.

 

I used opto's because the motor power was line derived and I wanted to isolate from a PC based RS232 Modbus type command origin.
Max.

 

Glad my pea brain finally helped you cm.

Well... if you put it that way... your pea brain's been working better than my bean brain...

I'm in the middle of a party right now, so I'll be back 'till Monday with more news.

Regards, and thanks again !

 

I'm using FDP33N25 n-fets, which are more than capable of handling this task, I think.

View attachment 121800​

The duty cycle at which I tested it was set at 20%, and the motor was moving just fine. Thing is, at that 3.7 kHz, I cannot make the duty cycle any smaller, because the stupid optos that I'm using are way too slow. But that's really not the issue here (I already found the problem, keep reading)



Exactly, one could leave the motor freewheeling on the off part of the duty cycle, but I've found that rpm's are far more stable if one does uses dynamic braking during operation, as previously described. Besides, the current during this part of the cycle goes through the motor, Q2 and Q4. But the fets are not the ones dissipating that power, but rather the motor's windings instead. So it's the motor that heats up a little. But this issue is now almost actually moot, because of what I'm going to do now.

I've reconnected everything now and done some testing, but without applying high power.

This is what my scope shows at the low-side fet's gate when the driver's pulsing it:

View attachment 121799​

As you can see, the duty cycle is around 20% (remember it's low-side, so the shown duty cycle is actually the complement of the real one). As I was saying, I can't make the duty cycle any smaller due to the sucky optos that I'm using. But that's gonna change, because I've already ordered a few HCPL-9030-000E digital isolators, which are far faster than optos.

Now, let's take a closer look at the rise and fall times of that signal:

View attachment 121798​

During rise (right side of the trace), it's taking about 5 µs for the gate to reach at least 2/3 of its full charge, and about 8 µs for its full potential. And during fall it takes a very similar amount of time. And the culprit for this has to be the 715Ω resistor that I put at the gate. And that resistor is the one that fixed the horrible EMI responsible for the MCU's spurious resets. So that resistor has to stay, and I can't make it any smaller.

Now, what does the ir2104 datasheet tells us about the "leisure time" (I prefer using that term instead of "deadtime" ) when switching between high and low side?

It says that it uses only about 1/2 a microsecond for that! So there was a period of about 7.5 µs during switching in which the ramp-up and ramp-down of the high and low side gates were overlapping... that explains why the fets were heating up, and also the freaking SHORT CIRCUIT!, the WHAM!, the BANG!, the BUZZZZZ, the SPARKS, the MELTED PINS AND ALL!!!!

View attachment 121803​

So yes, @shortbus, this is definitely not the appropriate chip for this application.... boy, am I glad I thought of that... . Seriously man, thanks for your input and sticking to this thread. I have a few ir2101's laying around that allow for independent side switching. I'll now be using those instead.

So now I'm going to draw, and print, and etch, and drill, and assemble, and solder yet another PCB. And then I'll do some more programming. Then I'll do more (hopefully successful) testing, and come back here with my results.

Thanks everyone, you've all been great help.

Sorry C, my bad, it does work okay, but the problem is it regenerates (regenerative braking). So when you slow down the motor (lower the duty cycle) it will pump up the supply.
This one switches the low side, but the principal is the same.
http://www.4qdtec.com/pwm-01.html#soph
If your going to redo the board, can you move the 5 volt regulator to this board?

 

can you move the 5 volt regulator to this board?

I'm afraid I can't. This board is part of a controller of a CNC machine that I designed almost 10 years ago. And I'd rather not mess with it now. But I see what you mean. The closer the regulator is to the MCU, the less possibility of being affected by EMI, right?

 

I'm afraid I can't. This board is part of a controller of a CNC machine that I designed almost 10 years ago. And I'd rather not mess with it now. But I see what you mean. The closer the regulator is to the MCU, the less possibility of being affected by EMI, right?

Yep. Maybe you could add another little one on this board? It's the ribbon cable that kind of bothers me.

 

Yep. Maybe you could add another little one on this board? It's the ribbon cable that kind of bothers me.

Yeah, I know what you mean. But this board will be connected to another board through a much shorter (1-1/2" long) ribbon cable.
If I can make this work with minimum interference, then I'll be perfectly safe when I finally put everything together.