Re: igbt speed
Dr. Dark Current, Mon Aug 06 2012, 12:03PM

your switching cycle is 5us, not 5ms, and switching speed is 1.7ms... this will work very bad, maybe not even at all (IGBT death), especially with no delay compensation.

Re: igbt speed
zzz_julian_zzz, Mon Aug 06 2012, 12:28PM

how did you come up of that conclusion?? is there a computation for this? I mean what is the relation formula or rule of thumb here? It will be a great help if you can show it, thanks.

Also, i don't know how you came up with 1.7ms

Re: igbt speed
Mads Barnkob, Mon Aug 06 2012, 02:50PM

Switching time at 200kHz is 5uS
The IGBT can turn on and off in 1.68uS

Rule of thumb... Best practise... I got no idea, but would assume that a 200% rule ain't too bad to go by. Like if you want to look at a 25MHz signal, use a 50MHz scope. If you want to run a coil at 200kHz, use a IGBT suitable for atleast 400kHz.
This is just guess work, careful study of each devices datasheet will tell you much more about losses vs. frequency etc.

Re: igbt speed
zzz_julian_zzz, Mon Aug 06 2012, 03:16PM

5us will mean 2.5us per half cycle, if there is 1.68 needed for 1 square cycle, it is still in the required speed, although not in the region of 50% margin,. hmmm.. not to mention the delay introduced by the driver itself could add more delay. The losses you are telling is the heat made by the switch isn't it? how do we look for that loss? Thanks..

BTW, any updates on your DRSSTC 3?

Re: igbt speed
Ben Solon, Mon Aug 06 2012, 03:41PM

look at it this way- if the igbt spends 1.7us turning on, then another 1.7us turning off, then its spending 60% of its time in the linear region where losses are huge. the rule of thumb i go by is: Fmax=1/((Ton+Toff+switching delays)*10)

Re: igbt speed
Dr. Dark Current, Mon Aug 06 2012, 05:26PM

Sorry I meant to write 1.7us not ms.

Re: igbt speed
zzz_julian_zzz, Mon Aug 06 2012, 10:37PM

with the turning ON delay, it only requires 0.73us and not the whole 1.7us. okay.. so i think I'll try to find another IGBT =) .. thanks for the info guys!

btw, what brick can you recommend for my coil as such? 200khz

Re: igbt speed
Dr. Dark Current, Mon Aug 06 2012, 11:36PM

The IGBT needs to turn ON and OFF in 1 cycle so you must add all times together.

Re: igbt speed
Dr. ISOTOP, Tue Aug 07 2012, 01:17AM

The delays are literally propagation delays; time from when the gate voltage hits zero to the time when the collector voltage starts rising. In hard-switched applications, they don't contribute towards losses. In a soft-switched circuit such as a DRSSTC, they contribute towards losses by causing the switching to deviate from ZCS, but the IGBT is not operating linearly during these delays.

Re: igbt speed
Ben Solon, Tue Aug 07 2012, 01:32AM

a brick simply cant get up to those speeds with its delays alone. then you have to deal with gate capacitance:

-- 2uC @ 24

-- 2uC/24V = 8.333e-8F = 83.33nF

-- P = C*V^2*f = .00000008333*24^2*200000 = 9.59962W/gate

-- 9.59962*2 ~= 20W per half bridge

you need a pretty chunky transformer to supply your "logic" now. almost an amp per half bridge at 24v.

another thing is why use a brick for a 500W coil? to247's can handle this power no problem. i wouldn't use bricks until you get into the kw range.

Re: igbt speed
Mads Barnkob, Tue Aug 07 2012, 08:59AM

As Terry once said:

I only had time to skim through this, but it looks interesting and might help you calculate:

Also, about the DRSSTC3, progress is slow, but changes to the design have been made as I got home some CM600s instead, so have been redesigning the bridge and will likely be putting it together this coming weekend, rest of the coil is still some miles from completion :)

Re: igbt speed
Dr. Dark Current, Tue Aug 07 2012, 09:33AM

Dr. ISOTOP: Nope. The delay times are for the current waveform. During the "turn off delay time", the drain (collector) voltage actually starts rising and reaches supply voltage, but the current still stays at its maximum. During the "fall time" the voltage has already reached full supply voltage, but the current falls to zero. For the turning on this is similar.

Re: igbt speed
Mads Barnkob, Tue Aug 07 2012, 04:55PM


Wards universal driver will have no problem delivering this drive current, with a standard GDT it can still deliver double rms current than what you require.

When calculating maximum swithcing speeds, there is two max frequencies to find, one looking at switching times, using the overall switching times multiplied by 10-20 and the junction temperature rise limit. Where the last always overrides the first.

One thing that really should jump at your eyes in a datasheet is the Zrjc vs. pulsewidth graph. For a 60N60 TO247 IGBT, you can read out that the normal 0,5K/W thermal resistance can be derated as low as 0,01K/W at the low pulse widths we use in a DRSSTC.

I can not find the thread, I think it is about a year back that someone experimented with resonant switching times, where he proved that bricks could be run way out of specs when in a resonant circuit.

I hope some of this makes sense and it all relates to the linked article above.


With a full bridge IXGN60N60 (isotop) I have pushed 2500W through, so Ben is absolutely right about a CM300 being overkill for a 500W coil.

Re: igbt speed
Dr. ISOTOP, Tue Aug 07 2012, 08:01PM


Aren't the times you're talking about listed under "rise time/fall time" on datasheets? I'm referring to the turn-on delays and turn-off delays.

Re: igbt speed
Dr. Dark Current, Tue Aug 07 2012, 11:04PM

I'm talking about the switching times manufacturers usually state in the datasheet. They are the turn on delay time (Tdon), rise time (Tr), turn off delay time (Tdoff) and fall time (Tf). These are (should be) related to the current, not voltage waveform. Sometimes there is an example of current and voltage waveforms with the switching times marked in them in the datasheet.

Re: igbt speed
zzz_julian_zzz, Wed Aug 08 2012, 12:45AM

I was able to run this coil & the output were more than 3x the length of its secondary with just irg4pc50ud (fullbridge) ,. I am just wondering if brick can still drive it because in my country, re-con bricks are far more cheaper than the brand new parts such as irg4 hehe.

Thanks for your inputs, ow. my country is in great disaster right now(if you heard on the news) no power since yesterday (i only used my laptop) =/

What if my coil were submerged in water? specially the secondary, what would happened if turned on?

Re: igbt speed
Dr. ISOTOP, Wed Aug 08 2012, 01:25AM


The secondary would probably flash over from being in water.

Re: igbt speed
Goodchild, Wed Aug 08 2012, 01:30AM



I'm not so sure about that, if it was distilled water for instance it may be one hell of a good insulator at ~18.5MΩ per cm.

Re: igbt speed
brandon3055, Wed Aug 08 2012, 02:52AM

The warter would probably detune the coil (unless your driver can compensate)

Re: igbt speed
Ben Solon, Wed Aug 08 2012, 03:24AM

You can't compensate for a detuned secondary period. Primary current feedback ensures that your primary's ~fres and your switching speed always match. Not whether your secondary is in tune. Not that it would it matters unless you're running fin or dan's coils: if the secondary became untuned then to keep the system in tune then you would have to physically alter the ~fres of the primary to match it.

Re: igbt speed
brandon3055, Wed Aug 08 2012, 04:57AM

Oops I was thinking of an sstc

Re: igbt speed
Mads Barnkob, Wed Aug 08 2012, 01:46PM

I made a couple of spreadsheets for switching speeds and gate drive.

60N60 thermal resistance is so low as corrected coresponding to datasheets Zrjc vs ontime.

Eon/Eoff for the CM300 are copies of the CM600 as I did not find these values.

Any comments on these calculations?

Re: igbt speed
Kizmo, Wed Aug 08 2012, 02:52PM

Looking good but Eon/Eoff values are for hard switching.

In perfect DRSSTC world you are not swithing any current so you only have to worry about conduction losses. Also switching delays are for hard swithing. (current rise/fall times)





I have tested these IGBTS up to 2kApk @ 60kHz in my test setup.. no problems at all with phase lead driver.

Re: igbt speed
Mads Barnkob, Wed Aug 08 2012, 03:45PM


Yeah I know its all data for hard switching, but its the numbers we have at hand :)

Conduction losses are as Terry Fritz also put it, highly neglect able with the very low duty cycles, by using the hard switching math, most IGBTs would run into MHz if only looking at the frequency limitation by temperature rise.

Are soft switching data normally available from the manufacturers?

Re: igbt speed
Kizmo, Wed Aug 08 2012, 03:56PM

There is still simple thermal limit. Even with "just" conduction losses.

Have a look at IGBT die temp rise during single burst.. push hard enough and poor die just does not have time to dissapate all heat through its substrate.

EDIT:

Of course this does not limit switching speed. In (properly timed, phase lead) soft switghing applications even big IGBTs can operate at surprisingly high frequencies.

In brick world there is of course one limit that is like a brick wall (pun not intended..). Larger igbts have several dies in parallel and their busbars can have 50-100nH worth of inductance which is usually NOT equally spread along all paralled dies. Same thing with gate leads. Both of those combined will have large effect on how fast you can actually switch and still maintain current sharing and keep ringing down.

With properly set phase lead driver (Wards UD2.0 or Prediktor) there is no reason why dirty old CM300 could not operate past 100kHz without any issues at all.

Re: igbt speed
zzz_julian_zzz, Thu Aug 09 2012, 01:11AM

What's with the UDv2.0 PLC/Predictor? can someone post a schematic of this?
or if any like way circuits? Thanks

Re: igbt speed
Ben Solon, Thu Aug 09 2012, 02:59AM


Steve gave me this link a while ago. its one of the non-released schematics, so don't go asking him to troubleshoot it for you if you have any problems.

those switching tables look fine. if i remember correctly i got some of the same times when i did the math a long time ago. just repeating that soft switching speeds are a bit faster.

people seem to be able to push cm300's to just under 100khz, so maybe the resonant switching formula should be:
Fresmax= (1/((Ton+Toff)*10))*1.6
that would correspond to some real data. look at how fast people switch these in their projects, and it looks reasonably accurate.

it also matches your thermal data. so we've got a new rule:Fresmax= (1/((Ton+Toff)*10))*1.6 unless the thermal data shows otherwise

Re: igbt speed
Kizmo, Thu Aug 09 2012, 09:58AM



Good example :)

Re: igbt speed
Steve Conner, Thu Aug 09 2012, 10:10AM

There are a few different kinds of "CM300", for instance the CM300DY-12F (?) uses Powerex's 600V F-series dice. These are much faster than the usual 1200V H-series, and I've seen it used in tabletop coils in the 200kHz region.

I'm a little wary of the practice of using the transient thermal impedance. It's OK to use it to calculate junction temperature rise during the burst, but that is just a ripple on top of a slower rise.

When the coil is run repetitively for a long time, the die temperature will be determined by the average power dissipation (switching plus conduction) and the steady-state thermal resistance.

You should maybe add the temperature ripple to this to find the actual peak die temperature, but it's probably only a few degrees because the transient thermal impedance is so low, unless you are really pushing the device to destruction.

Steve Ward and Jimmy Hynes used PSpice to do full transient thermal simulations, with an electrical analogue of the thermal circuit.

As Kizmo points out above, package inductance in bricks is a serious problem because it causes the switching losses to be shared unevenly between dice, and no amount of spreadsheets will help you quantify that. Zero current switching of course is a great help.

Re: igbt speed
Kizmo, Thu Aug 09 2012, 12:30PM

This thread is getting interesting :)

One thing that is related to this temperature issue is different failure modes. So far i have seen two different failure modes in drsstc applications (both measure dead short over C-E)

1. Only one or rarely two parallel dies are shorted, very little visible damage and usually rest of the brick is still fine (cut bonding wires and put it back together -> works)

2. Everything is obliterated, usually IGBT case is also ruptured.

Violent failures are usually result of large scale overvoltage or overcurrent but how about these silent failures? Maybe thermal cycling stress -> igbt chip delamination and localized overheating -> pop?

Re: igbt speed
Dr. Dark Current, Thu Aug 09 2012, 12:36PM

I think if the bonding wires survive, the failure is "silent". If they fuse, a power arc forms which fries the insides and the expanding gasses can rupture the case.

Re: igbt speed
Ben Solon, Thu Aug 09 2012, 03:43PM

I think that the silent deaths are exactly what's been just pointed out. Uneven incuctance causes one die to recieve a higher transient than the rest. No over current or blown bonding wires, just an over voltage failure.

Re: igbt speed
Steve Conner, Thu Aug 09 2012, 07:32PM

Yes, but the point is that semiconductors always fail short circuit, and we like to use them with big energy storage cap banks connected across them. No matter how the module is stressed, one die will always fail before the others, and then the DC bus will discharge through it and its bond wires. A H-bridge has two devices in series across the DC bus, but if one fails, the other will find itself driving a short circuit and will fail very soon after.

I've seen big IGBT brick and SCR datasheets that quote a "case rupture I2t". Presumably the idea is to use a fuse with a smaller I2t than this, so the part won't explode violently, blow the equipment to pieces and maybe injure some personnel.

But presumably there's some lower value of I2t where the die that fails won't explode violently enough to nuke all of the others.

Re: igbt speed
Ben Solon, Thu Aug 09 2012, 08:36PM


now if only that fuse was a breaker that would solve the over-current problem in coiling.

and while we're at it maybe a tvs that when a transient appears an internal sensor cuts power to the dies, and diverts it... but then the igbt would cease being a brick, and become a computerized switching device XD

Re: igbt speed
Ben Solon, Thu Aug 09 2012, 08:56PM

if its possible, can someone merge this attachment to my last post?

Re: igbt speed
Steve Conner, Thu Aug 09 2012, 09:00PM

I have some solid-state coils that are getting on for 10 years old. They still have the original IGBTs. I've never blown a single one.

I think the only overcurrent problem in coiling is people who turn the current limiter up too far or run without one. If you have a current limiter, a driver that does zero current switching, and a nice low inductance bus layout, there's your computerised switching device right there.

When you get to brick sized IGBTs, it's hard to find TVS-type devices big enough to catch the massive spikes that you can generate. In my OLTC work I tried and gave up, I used an active clamping scheme that fired the IGBT permanently on and shut down the power supply.

That was needed because the OLTC used a single switch supplied with constant current through a DC bus inductor. A DRSSTC uses a voltage source inverter. If your bus inductance is low enough, the diodes built into the IGBTs will catch voltage spikes and dump them back into the DC bus capacitors, so no TVS are needed.