The "Fat Coil" QCW Tesla Coil / Projects / Forums

Forums

4hv.org :: Forums :: Projects

« Previous topic | Next topic »

The "Fat Coil" QCW Tesla Coil

first previous 2 3 4 5 next

Move Thread

LAN_403

Steve Ward

Sun Nov 30 2014, 08:36PM

Registered Member #146 Joined: Sun Feb 12 2006, 04:21AM
Location: Austin Tx
Posts: 1055

Can you explain it better?
When over current is tripped the coil driver start to skip cycles and the buck goes in a "constant current mode" to help the cycle skiping thing to work better?

There's a lot going on, i'll try to re-explain with more detail. The buck converter has a current limiter that momentarily disables the drive signal to the IGBTs. Its supposed to act as a "cycle by cycle" peak current limit, however, due to bandwidth limitations on my sensor there is significant delay in the current signal. This delay causes the over-current event to be detected after the PWM cycle has completed (in the undesirable case), which causes the buck to skip PWM cycles (unintentionally). This causes the high-frequency sounds that you hear, as the buck is switching at just 10khz, somewhat chaotically.

At the same time, the tesla coil driver has an over-current protection that will cause the H-bridge to skip a driving cycle. This is a good method for most systems, but when supplied by a buck converter it causes un-wanted effects (the voltage at the buck output will suddenly rise as the tesla bridge stops drawing current for a moment). If this happens, the Buck often shuts down from an over-voltage fault condition.

I do plan on improving the current limit behavior of the Buck, and once that is proven reliable, the tesla coil current limit will be set very high so that it should never engage unless some other fault condition exists.

Does the micro controller form part of the feedback path? If so, does it sense the tank current with a comparator on the zero crossings or an ADC?

If clocked logic or a micro controller is used in the feedback path it seems like you would get a lot of jitter in the gate drive waveforms and fall into hard switching some of the time. Does this not end up being an issue?

I use a Cypress PSoC 5LP, which handles the IGBT switching, and it does the phase-lead stuff too. For the most part this circuitry is built into hardware, which is controlled by the MCU to provide proper tracking. Its clocked at 64MHz, and the actual gate timing can be off by 1-2 clocks typically (~15-30nS) from the ideal switch time.

do you have problems with EMI in your electronics running that much power

I dont think its any worse than a small coil running at similar supply voltage. Most of the noise comes from dV/dt, so going bigger doesn't necessarily make things worse, sometimes its better because its slower. I do have a lot of filtering on all of the control-board I/O, it is a tesla coil afterall...

Intra, almost got it, but you didnt get the extra IGBT/diode boost circuit correct. It follows a standard boost converter scheme, i think you can fix your schematic

Gregory

Mon Dec 01 2014, 04:58AM

Registered Member #2922 Joined: Sun Jun 13 2010, 12:08AM
Location:
Posts: 226

Thanks.

I use a Cypress PSoC 5LP, which handles the IGBT switching, and it does the phase-lead stuff too.

Can you explain what method did you use to make the phase-lead. I was thinking to use a FPGA in my QCW controller but I didn't get a good and reliable idea for phase leading.

Shrad

Mon Dec 01 2014, 10:45AM

Registered Member #3215 Joined: Sun Sept 19 2010, 08:42PM
Location:
Posts: 780

couldn't phase lead be deduced from T-1 times a correction factor? thus no fancy computation needed...

Gregory

Tue Dec 02 2014, 12:52AM

Registered Member #2922 Joined: Sun Jun 13 2010, 12:08AM
Location:
Posts: 226

The simple idea I can see is to put the feedback signal trought a FIFO to delay the signal by 180Âº - phase lead but this method will be frequency dependent

Shrad

Tue Dec 02 2014, 08:10AM

Registered Member #3215 Joined: Sun Sept 19 2010, 08:42PM
Location:
Posts: 780

is T-1 really that frequency dependent? you'll never be that precise due to field constraints anyway, and it would be the simplest approximation

the situation will not change completely over a period, and even if it does over five or ten periods, isn't this enough?

I'd be curious about how a PID would behave in this field, as you could play with overshoot

Steve Conner

Tue Dec 02 2014, 10:41AM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

There are two fundamental ways of doing phase lead.

You can estimate when to make the next switching transition based on how far out you were in trying to hit the previous ones, in which case you have a PLL. The PLL loop filter determines the weighting given to different times in the error history. "T-1", if I understand correctly, is a digital PLL with a 1st order FIR loop filter, that works on the single previous switching transition and forgets the others. If you use a PID controller on the T-1 error signal, it becomes a classical PLL, as the I term remembers previous values of T-1, therefore T-2, T-3 etc.

Or, you can extrapolate the current waveform by assuming it is sinusoidal, and guess what it will do next based on its first derivative. This is the phase lead driver aka "Predikter".

The PLL is slower to respond to changes in streamer loading, because it is using information at least one half cycle old. But the phase lead driver is more susceptible to noise because the extrapolation process involves differentiation, which amplifies high frequencies. In control engineering classes we were taught never to differentiate anything, let alone the output of a Tesla coil. Nevertheless, both methods seem to work well.

Common sense would recommend phase lead for DRSSTCs with short bursts, where you want to hit each and every switching transition even though they may be unevenly spaced. And PLL for CW and QCW SSTCs where you want to be able to select a particular pole frequency. But there are examples of both methods being used with both types of coil.

Goodchild

Tue Dec 02 2014, 04:37PM

Registered Member #2292 Joined: Fri Aug 14 2009, 05:33PM
Location: The Wild West AKA Arizona
Posts: 795

In my opinion the FIR is the way to go, particularly if you can get 3 or 4 taps built into hardware. It's noise immunity is superior to anything I've used in the past.

The downside however, is the vast amount of hardware you need to implement it. I've done it in Xillinx FPGAs, but something like a mico probably could't handle the vast amount math required in a timely manner.

Gregory

Tue Dec 02 2014, 08:08PM

Registered Member #2922 Joined: Sun Jun 13 2010, 12:08AM
Location:
Posts: 226

You can estimate when to make the next switching transition based on how far out you were in trying to hit the previous ones

How can I calculate the error ? I will need a precise and real time reference of the bridge output to calculate the T-1 error by measuring edges time diference.

In my opinion the FIR is the way to go, particularly if you can get 3 or 4 taps built into hardware. It's noise immunity is superior to anything I've used in the past.

Do you mean a FIR with a know phase response at the particulary ressonant frequency?

What about use a digital PLL with the NCO singnal that goes to the phase comparator pass throught a delay line to generate a constant group delay.
This way we get a frequency independent time-lead, that appear to be better than a phase-lead for long burst coils that change a lot the frequency.

EDIT: I made a simulation of the PLL loop with the FIFO delay line at NCO output and it appears to work very well. I think it can be implemented in simple way with FPGA.

Steve Conner

Wed Dec 03 2014, 01:02PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

Gregory wrote ...

How can I calculate the error ? I will need a precise and real time reference of the bridge output to calculate the T-1 error by measuring edges time diference.

Most PLL users (myself included) just use the gate drive signal as the reference. The assumption is that the delay from gate drive to bridge output is constant. The effect of making this assumption is that the PLL generates a constant phase lead referred to the feedback signal, that you have to set manually to compensate the delay in the power devices. This is really just the same thing as twiddling the variable inductor in Steve Ward's phase lead driver.

If you used the actual bridge output as your reference, your PLL would be measuring the actual switching delay of the bridge and compensating for it automatically. This could get messy when deadtime is involved, as the IGBTs do not always have control of the switching delay, it sometimes passes to the diodes.

Steve Ward

Sun Dec 07 2014, 08:49AM

Registered Member #146 Joined: Sun Feb 12 2006, 04:21AM
Location: Austin Tx
Posts: 1055

I made a digital PLL.

There are a few key points about it:

1) the user has to define a starting frequency "Fstart". The driver switches to feedback/pll operation after "N" cycles (set in 0.5 cycle increments), typically i use 0.5-1 cycles for a "transient" type DR, and 4-8 cycles for SSTC/QCW where you need to have a well defined starting frequency/mode). However, it works acceptably with pretty big errors... so its not overly burdening.

2) The user must define the desired phase-lead time "Tlead", which is referenced to the output signals from the PSoC (Conner already explained this perfectly). This lead time is defined as the whole delay time of the system (that includes the feedback CT delay, the processors delay, and IGBT delay).

So how's it work?

First, start driving at "Fstart", during this time, measure the period between zero crossings in the current feedback signal. After "N" cycles at "Fstart", PLL operation can begin. The PLL works as follows:

A one-shot timer is started upon each zero-current-detection of the feedback signal (that is, 2 events per full cycle). The one-shot is set to time out "just before" the next expected zero crossing. When the one-shot times out, the output to the gate driver flips state (as if the feedback signal told it to). If you measured the previous half-cycle's period "Thp", you can predict the next one as Tnext_switch = Thp - Tlead.

If that makes sense, then you understand enough to build your own digital PLL as i did. However... there was a problem with stability if the half-cycle periods were inconsistent, so i added a digital filter that averages the previous 4 half-cycle periods and uses that result for the predictive one-shot timer (knocking it down to 2 half-cycles ought to work too, just havent tried it yet). Conner would probably point out here that there is some dynamic performance loss from this, but thanks to the fact that the one-shot is reset with the feedback input, you can never get too far out of phase with the desired switching command even if the system frequency is changing rather quickly. Oh yeah, and just in case the prediction is too late, the zero-cross detect will command a gate drive transition, making the driver no worse than my old universal driver without phase lead.

Ive used this same driver on a wide variety of tesla coils and its performance is on par with the inductor prediktor and about 1000 times better than the 4046 PLL crap i used to play with. However, getting the whole scheme to work reliably was a considerable challenge and took months of debugging/tweaking to get it to a robust state. Having an FPGA with essentially limitless hardware would have made the task easier, most of my time was spent coaxing the design to fit within my hardware budget on the PSoC. Also, 64MHz clock leaves a bit to be desired at higher TC frequencies.

first previous 2 3 4 5 next

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