Welcome
Username or Email:

Password:


Missing Code




[ ]
[ ]
Online
  • Guests: 21
  • Members: 0
  • Newest Member: omjtest
  • Most ever online: 396
    Guests: 396, Members: 0 on 12 Jan : 12:51
Members Birthdays:
All today's birthdays', congrats!
Sonic (58)
kamelryttarn (46)


Next birthdays
11/29 Sonic (58)
11/29 kamelryttarn (46)
11/30 arnsfelt (45)
Contact
If you need assistance, please send an email to forum at 4hv dot org. To ensure your email is not marked as spam, please include the phrase "4hv help" in the subject line. You can also find assistance via IRC, at irc.shadowworld.net, room #hvcomm.
Support 4hv.org!
Donate:
4hv.org is hosted on a dedicated server. Unfortunately, this server costs and we rely on the help of site members to keep 4hv.org running. Please consider donating. We will place your name on the thanks list and you'll be helping to keep 4hv.org alive and free for everyone. Members whose names appear in red bold have donated recently. Green bold denotes those who have recently donated to keep the server carbon neutral.


Special Thanks To:
  • Aaron Holmes
  • Aaron Wheeler
  • Adam Horden
  • Alan Scrimgeour
  • Andre
  • Andrew Haynes
  • Anonymous000
  • asabase
  • Austin Weil
  • barney
  • Barry
  • Bert Hickman
  • Bill Kukowski
  • Blitzorn
  • Brandon Paradelas
  • Bruce Bowling
  • BubeeMike
  • Byong Park
  • Cesiumsponge
  • Chris F.
  • Chris Hooper
  • Corey Worthington
  • Derek Woodroffe
  • Dalus
  • Dan Strother
  • Daniel Davis
  • Daniel Uhrenholt
  • datasheetarchive
  • Dave Billington
  • Dave Marshall
  • David F.
  • Dennis Rogers
  • drelectrix
  • Dr. John Gudenas
  • Dr. Spark
  • E.TexasTesla
  • eastvoltresearch
  • Eirik Taylor
  • Erik Dyakov
  • Erlend^SE
  • Finn Hammer
  • Firebug24k
  • GalliumMan
  • Gary Peterson
  • George Slade
  • GhostNull
  • Gordon Mcknight
  • Graham Armitage
  • Grant
  • GreySoul
  • Henry H
  • IamSmooth
  • In memory of Leo Powning
  • Jacob Cash
  • James Howells
  • James Pawson
  • Jeff Greenfield
  • Jeff Thomas
  • Jesse Frost
  • Jim Mitchell
  • jlr134
  • Joe Mastroianni
  • John Forcina
  • John Oberg
  • John Willcutt
  • Jon Newcomb
  • klugesmith
  • Leslie Wright
  • Lutz Hoffman
  • Mads Barnkob
  • Martin King
  • Mats Karlsson
  • Matt Gibson
  • Matthew Guidry
  • mbd
  • Michael D'Angelo
  • Mikkel
  • mileswaldron
  • mister_rf
  • Neil Foster
  • Nick de Smith
  • Nick Soroka
  • nicklenorp
  • Nik
  • Norman Stanley
  • Patrick Coleman
  • Paul Brodie
  • Paul Jordan
  • Paul Montgomery
  • Ped
  • Peter Krogen
  • Peter Terren
  • PhilGood
  • Richard Feldman
  • Robert Bush
  • Royce Bailey
  • Scott Fusare
  • Scott Newman
  • smiffy
  • Stella
  • Steven Busic
  • Steve Conner
  • Steve Jones
  • Steve Ward
  • Sulaiman
  • Thomas Coyle
  • Thomas A. Wallace
  • Thomas W
  • Timo
  • Torch
  • Ulf Jonsson
  • vasil
  • Vaxian
  • vladi mazzilli
  • wastehl
  • Weston
  • William Kim
  • William N.
  • William Stehl
  • Wesley Venis
The aforementioned have contributed financially to the continuing triumph of 4hv.org. They are deserving of my most heartfelt thanks.
Forums
4hv.org :: Forums :: Projects
« Previous topic | Next topic »   

Adventures in induction heating

first  3 4 5 6 
Move Thread LAN_403
Wolfram
Tue Sept 22 2015, 10:19PM
Wolfram Registered Member #33 Joined: Sat Feb 04 2006, 01:31PM
Location: Norway
Posts: 971
Progress is slow but steady.

I received the third revision prototype boards earlier this summer, and populated one for testing. I've finally gotten around to testing it and everything seems to work as it should. I'm still not sure if I'm happy with the way the transistors are mounted, but it works for now. For an eventual final version, I'd like to be able to easily mount a water cooling block to the transistors and mechanically support everything with a minimal amount of mounting hardware.


17 S

43 S


I've redrawn the schematic for readability, though I haven't had a chance to clean up all the parts references and values Link2 . The main changes from the earlier versions are:

Range limit for the PLL: The 74HC4046 and especially the 74HC4046A has some strange behavior near the ends of the VCO input voltage range, unlike the classic 4046. This is mentioned in the datasheet, and it can lead to the PLL sticking to the ends of the range. Three resistors easily fixes these problems by limiting the VCO input voltage range to within acceptable limits.

Grounding MOSFET for the loop filter: If the VCO goes below around half of Fres, the third harmonic of the bridge voltage tends to excite the tank more than the fundamental does. This gives some strange waveforms across the cap (and in the tank current as well) with multiple zero crossings per period. This can lead to the PLL sticking to the end of the range. The obvious solution is to limit the lock range of the PLL so that it can never go low enough in frequency to be a problem, but I want a wide range of operating frequencies without changing component values, so I tried this approach instead. The idea is that the MOSFET puts the loop filter in a known state during shutdown, so that the heater always starts up above Fres when turning it on.

Isolated capacitor voltage sensing: I initially wanted to use tank current sensing for PLL phase feedback, but this turned out to be difficult to get working well in practice. The reason I wanted this is that the current sensing is isolated by default, so that I could use the heater with non-isolated tank circuits without having to float the control electronics at mains potential. I found some widely available and cheap digital audio isolation transformers (Murata DA103C) that allow for isolated capacitor voltage sensing. This allows the tank circuit to be isolated or mains-referenced, while having the low voltage control part galvanically isolated from mains in all cases. The voltage sensing circuit has been designed to provide minimal phaseshift for small and large signals and a wide range of frequencies, while not saturating the DA103C.
Back to top
Wolfram
Tue Oct 06 2015, 09:40AM
Wolfram Registered Member #33 Joined: Sat Feb 04 2006, 01:31PM
Location: Norway
Posts: 971
I've discovered a new problem with using PLLs for resonant tank control, and this could well explain problems that other members have had with PLLs for the control of induction heaters and *SSTCs. Specifically, the problem relates to the use of XOR phase comparators with resonant tank circuits.

If you look at the phase between the voltage and current for an LC tank circuit, it starts out at - 90 degrees, passes through 0 degrees at resonance, and ends up at + 90 degrees. This covers a 180 degree range, and if the Q is high, most of this phase change happens over a narrow frequency range.

The XOR phase detector also covers a range of 180 degrees, from 0 to 180 degrees. Going beyond this range, the output voltage (duty cycle) of the phase comparator wraps around; the output is the same for 181 degrees as for 179 degrees, and likewise for 1 and -1 degrees.


1444124439 33 FT168388 Xor Pd Tf


Ideally, using this phase comparator should work if its phase range is centered around the phase range of the tank circuit. In my circuit I do it by sensing the tank capacitor voltage relative to the bridge output voltage (actually the bridge drive signal. The additional 90 degree phase shift between the tank cap voltage and current nicely puts the tank phase range right on top of the phase detector range.

The problem appears if there is any additional phase shift anywhere in the circuit, for example in the capacitor voltage sensing divider or in the gate drivers. Now, the sensed phase can go outside of the range for the phase detector. This gives the transfer function an inflection point, which leads to the PLL sticking at one end of its frequency range.


1444124439 33 FT168388 Xor Pd Shift


I've done some simulations of this, here's a graph showing the result with 20 degrees of additional phase shift in the feedback network. If the frequency for any reason ends up above the inflection point, the negative feedback will turn into positive feedback, and the frequency will stick to the top of the range. I chose 20 degrees in my simulation to make the problem clear, but this happens with much smaller phase shifts as well. Even with 5 degrees there's a very visible inflection point that will inevitably lead to sticking. And the inherent delay of the gate drivers and IGBTs gives about this much phase shift at 300kHz.

I looked into making a phase detector with a wider input range, but it seems like this is fundamentally impossible without using edge-triggered circuits. So where do we go from here? The pulse density modulation works wonderfully, so I only need to find a new way to control the switching. Here are my ideas so far, sorted in order of preference:

1: Use an edge-triggered phase detector. I could use the built-in phase detector 2 of the 74HC4046A. Edge triggered detectors are not really a good idea around noisy power electronics, but some filtering might be enough to make it work well. I will try to test this within the next few days.

Dr. Dark Current discovered a problem with the 4046 PC2, nicely documented in this thread: Link2 . The problem is that this phase comparator has 12 internal states, and it can get very confused when a pulse goes missing when both inputs are driven from the output (one directly, the other through the bridge and the tank). The 74HC4046A has the simpler PC2 with only 3 internal states, so this should not be a problem. Note that the 74HC4046 (non-A version) also has the problematic 12-state PD2. It's importat to be aware that 4046, 74HC4046 and 74HC4046A are three very different chips with major differences in functionality and behavior.

2: Put a microcontroller in the phase loop and program it to avoid the inflection point. I originally wanted to avoid using programmed components in the controller to make it easier to understand and replicate, but if this is what it takes to make it work, then I'll do it. An added bonus is that I can also add overtemperature sensing into the microcontroller and a few other useful features, I just have to be careful so that feature creep does not get out of hand.

3: Use a self-oscillating driver with phase lead. I will try this if all else fails.
Back to top
Victor.Mello
Sun Nov 01 2015, 11:33PM
Victor.Mello Registered Member #11033 Joined: Tue Mar 12 2013, 09:30PM
Location:
Posts: 1
Wolfram thank you for sharing!

I already spent 5 years dating my induction heater lol, it's coming alive (In it's first good looking build) until the end of the year!

I tried the 4046 chip gave up on it along time ago, I'm now perfecting the code for the AT90PWM316 chip, what do you think of this chip?

I aiming to do a 110 - 220V with a switch to change the number of winding on the core (series resonant).

The power control, I thought to PWM the resonant frequency with the AT90.

Here are some photos of what I'm building:

1446420519 11033 FT168388 0

1446420519 11033 FT168388 1

1446420519 11033 FT168388 3

1446420519 11033 FT168388 4

1446420519 11033 FT168388 5

1446420519 11033 FT168388 6

1446420519 11033 FT168388 7


Old coil and new coil comparison

1446420519 11033 FT168388 8

1446420519 11033 FT168388 2


And here's my previous one running (this one is just a frequency generator controlling a h-bridge):



Do you have any suggestions??

Thanks again!
Back to top
parasole
Sat Nov 14 2015, 07:53PM
parasole Registered Member #54647 Joined: Wed Mar 18 2015, 02:52PM
Location:
Posts: 13
Victor.Mello wrote ...

perfecting the code for the AT90PWM316

Would be interested to see the code, of course if you will consider to share it...
I am planning similar setup, my intention is to use phase shifting for power control...
Back to top
Wolfram
Thu Nov 19 2015, 04:55PM
Wolfram Registered Member #33 Joined: Sat Feb 04 2006, 01:31PM
Location: Norway
Posts: 971
PLL discussion has been moved to a separate thread Link2 and a good solution has been found.

Victor.Mello wrote ...

Wolfram thank you for sharing!

I already spent 5 years dating my induction heater lol, it's coming alive (In it's first good looking build) until the end of the year!

I tried the 4046 chip gave up on it along time ago, I'm now perfecting the code for the AT90PWM316 chip, what do you think of this chip?

I aiming to do a 110 - 220V with a switch to change the number of winding on the core (series resonant).

The power control, I thought to PWM the resonant frequency with the AT90.


Hey Victor.

Very nice project, looks like a solid build. You should make a separate thread about your project, then I (and others) can can discuss it without going off-topic here. If you start a new thread in the projects forum, I can move my reply to that thread.

One of the main challenges in driving an induction heater is the fact that a well designed tank circuit usually has a very high Q factor, often exceeding 100. This means that even a small frequency change around the resonant frequency leads to a large change in the switching phase angle. The AT90PWM316 PWM module can be clocked at up to 64 MHz. This gives an acceptable frequency resolution with tanks resonating at 50 kHz for example, but above 100 kHz or so, the frequency resolution tends to become a bit rough for accurate switching phase angle control, leading to increased switching losses. The AT90PWM supports a mode with finer frequency resolution, but this mode adds phase jitter so it's not really usable in this application. In conclusion, whether or not it is a usable solution depends on the frequency you want to operate at. For my heater I want to be able to work at higher frequencies (up to several MHz) so I didn't go with this option. As I'm using IGBTs up to half a megahertz (and hopefully beyond), accurate switching angle control is essential to keep losses low.

It also depends on what power control scheme you're going for. If you chose frequency control (detuning above resonance), it doesn't make much sense to minimize switching losses as it will only run at resonance when heavily loaded (and the Q is low), and switching losses will be high in any case. PWM will also increase the switching losses, but if you're operating at low frequency and moderate power you might get away with it.

I'm considering using a microcontroller myself, but to get accurate enough frequency control at high frequencies I have to clock the microcontroller from an analog PLL and phase-lock it to a multiple of the tank resonant frequency.

What IGBT series are you using by the way? Your setup looks very similar to a medium frequency (50 kHz) setup I'm working on.

Back to top
Steve Ward
Mon Nov 23 2015, 08:34AM
Steve Ward Registered Member #146 Joined: Sun Feb 12 2006, 04:21AM
Location: Austin Tx
Posts: 1055
With regards to microcontroller drive, you should consider the idea that the PWM frequency need not be "constant", but can dither between 2 frequencies to produce, on average, whatever frequency you want. There is nothing, in a practical sense, bad about there being some jitter in the switch timing. For example, my digital tesla coil drivers operate from a 64MHZ clocked MCU, but they can track resonant circuits up to 500khz with very nice timing in terms of power switching. It just amounts to some switching happening a little early or a little late (give or take 15nS, one clock period) from the "perfect" timing. No need to mess with the clock source of the MCU, just constantly tweak the PWM period to track the desired period.

Its somewhat trivial to feedback the inverter current to the MCU and trigger its PWM timing from the current zero crossings so that the MCU PWM will track the resonant frequency of the system. You can basically make a "digital PLL" this way, and adjust the phasing of the gate drive signal with the MCU to control power if you want. Just sayin, its been done and works wink.
Back to top
Wolfram
Mon Nov 23 2015, 03:40PM
Wolfram Registered Member #33 Joined: Sat Feb 04 2006, 01:31PM
Location: Norway
Posts: 971
I did some simulations which showed pretty discouraging results. With an oscillator frequency of 64 MHz, the frequency step size around 500 kHz is 4 kHz, and this corresponds with a phase angle difference of 70 degrees when the tank Q is 100 (which seems to be pretty typical for an unloaded IH tank from my measurements). As you've reported that it works well in practice, it can't be as bad as my simulation suggests.

Is the actual switching phase angle averaged by the L/R time constant of the tank circuit? It does seem to make sense, and if it is true then the microcontroller as a VCO is a much more viable alternative than I first suspected.
Back to top
Steve Ward
Mon Nov 23 2015, 04:37PM
Steve Ward Registered Member #146 Joined: Sun Feb 12 2006, 04:21AM
Location: Austin Tx
Posts: 1055
I think you missed my point [edit: upon reading your response, it seems like you did get it, but i already wrote this anyway], I will try to clarify.

It's true that if you kept a constant PWM output frequency from your 64MHz source that you would *very likely* end up with a large phase error because you cannot hit the exact frequency with any integer divider from that 64MHz source. The idea I'm trying to convey is to continually change the PWM output frequency, say, between the 2 nearest frequency values, one above Fres, the other below Fres, so that the frequency on average is exactly Fres (or whatever you want). With a 64MHZ clock you get 15.625nS per clock tick, so its possible to keep your power switch transitions within just 15.625nS of the ideal switching time, which for most power conversion system is a negligible amount of error when the half period is >1uS.

Another way to see it is that because of the discrete steps in output frequency, the PWM signal will accumulate phase lead or lag depending on if its above or below the resonant frequency of the heater circuit. The task for the MCU is to constantly update the PWM frequency so that the phase lead or lag never accumulates too far. Theoretically its possible to keep the phase error to be within 1 clock period, or just ~15nS of perfection.

My next point was that you can feedback the current signal (via comparator, so its a 1-bit digital timing signal) to the MCU. In my experience, simply measuring the oscillation period of the tank current and outputting that frequency does not quite work... it tends to settle with some significant phase error. The more useful technique, i find, is to use the current feedback signal to reset what is essentially a 1-shot timer, which is programmed with a period just less than the period of 1/2 cycle of Fres. The output transition from this 1-shot timer would cause the PWM signal to the h-bridge to transition. You can gain phase by shortening the period of this 1-shot timer. Note that this scheme does not necessarily fit into the typical operating conditions of most MCU's timer peripherals, so you'd have to be creative and likely use some external logic to convert your 1-shot pulse generator into a PWM signal that changes state when triggered by this 1-shot. Essentially, you create a phase-leading signal by delaying the feedback signal by 1/2 cycle (really, some amount less than 1/2 cycle). The reason this can work so well is because the MCU can measure the timing of the feedback signals period, and calculate the desired period of the 1-shot for optimal control. The last bit of this "solution" is that initially the MCU must start driving the LC tank "open loop" style at some frequency close enough to Fres to get this current feedback signal to lock on to.

From here you can hopefully see how you could implement power control via variable phase lead, or do more complex things like blank out PWM pulses for "pulse skip modulation". However, most generic MCU timer peripherals will not support these more exotic schemes on their own, so you'd be better off adding some CPLD with a cheap MCU, or using an FPGA or other "SoC" (system on chip) solutions that offer programmable logic devices on board to implement the PWM logic.

An arguably simpler idea is to have the MCU search for the best frequency to drive based on phase information. You could make a simple phase comparator by XORing the 1-bit current feedback signal with your PWM output signal, RC filtering this and feeding it into an ADC. The MCU would then have a phase-error signal it could work to try and keep at some specified value. This solution should be much more appropriate for induction heating over Tesla coils, since the resonant frequency is not expected to change quickly, and some hard-switching is tolerated if it did suddenly change quickly (say you short out a turn on your work coil...).
Back to top
Uspring
Mon Nov 23 2015, 07:00PM
Uspring Registered Member #3988 Joined: Thu Jul 07 2011, 03:25PM
Location:
Posts: 711
Frequency dithering doesn't look too bad to me. Consider as the simplest case: A full sine period of length T1 followed by a full sine period of length T2 and then repeat from the beginning. This signal is strictly periodical with the period T1+T2, so in the frequency domain it consists of multiples of the frequency 1/(T1+T2). If T1 and T2 are close to each other, the major component will be 2/(T1+T2). To a much lesser extent, energy will be in the frequencies 1/(T1+T2), 3/(T1+T2), 4/(T1+T2) etc. I haven't done the math, but I think, the closer T1 and T2 are, the smaller are the non major components.

You won't always be at your favourite phase, but the phase error due to dithering will always be less than say 16ns/2us * 360 degrees (i.e. resolution/period * 360 degrees).

For other dithering modes (i.e. longer periods than T1+T2), the weaker frequency components might not be so far away from the major one, but they become weaker as they approach the major component.
Back to top
GeordieBoy
Tue Nov 24 2015, 09:43PM
GeordieBoy Registered Member #1232 Joined: Wed Jan 16 2008, 10:53PM
Location: Doon tha Toon!
Posts: 881
Have you guys thought about using Direct Digital Synthesis (DDS) ?

DDS chips are available that generate a *SINEWAVE* at a programmable frequency. These often generate a discrete (sampled) sinewave up to several tens of MHz, with a frequency resolution in the milli-Hertz step range, when running from a clock frequency of 100MHz or so. (You can even get down to micro-Hertz accuracy if necessary, as we do at work for driving high-Q MEMS resonators.)

DDS chips from Analog Devices cost a few Euros each and you program the frequency and phase from a microcontroller via SPI. They are very common with the amateur radio crowd to replace VCOs in their VFOs and they're also used in high-end stuff like phase-array radars, dopler ultrasound, etc. They often have lower noise and spurs than a VCO wrapped inside a PLL. This is what I have used in induction heating applications where I wanted fine frequency control under microprocessor command.

The important thing to do here, is to synthesise a sinewave with the DDS. This is initially a discrete "stepped" (sampled) sinewave at some high sample rate like 50MHz. But you pass this through an anti-imaging (reconstruction) low-pass filter that removes all the high-frequency energy from the sampling process and leaves you with a beautifully clean sinewave. Then you put this through a comparator to give you a square wave if that is the waveform you ultimately want to drive your power electronics. This process i've described is important to remove the jitter, as just attempting to generate a digital square wave "clock" signal directly using DDS results in bad period jitter equal to the reciprocal of the sample-rate.

An additional benefit of first synthesising the sinewave is that you can pass this into two comparators with slightly different decision thresholds in order to implement deadtime control for driving opposing devices in power electronics switching applicaitons.

Just another tool to keep in the box for when it might come in handy that I have found very effective. Analog Devices have some good App Notes on DDS for those interested.

-Richie Burnett,
Back to top
first  3 4 5 6 

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob

Go to:

Powered by e107 Forum System
 
Legal Information
This site is powered by e107, which is released under the GNU GPL License. All work on this site, except where otherwise noted, is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. By submitting any information to this site, you agree that anything submitted will be so licensed. Please read our Disclaimer and Policies page for information on your rights and responsibilities regarding this site.