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.
Registered Member #33
Joined: Sat Feb 04 2006, 01:31PM
Location: Norway
Posts: 971
I've heard that connecting caps between strings is not recommended, as it can interfere with the self-healing function of the caps. I don't remember where I read it, so I don't know if it's trustworthy information.
Registered Member #72
Joined: Thu Feb 09 2006, 08:29AM
Location: UK St. Albans
Posts: 1659
I've heard that connecting caps between strings is not recommended, as it can interfere with the self-healing function of the caps.
This is a fairly fundamental question in MMC design, I've not found any authoratative guidance with a quick google, or a visit to the usual suspects. I only suggested paralleling as a means to reduce the number of resistors, which is not a smart economy if it causes the cap bank to fail earlier. My MMC is paralleled units BTW.
Given that the healing mechanism consists of the cap vapourising the bit of electrode feeding the failed section, I would have thought that the extra energy available in the parallel caps would have assisted that process.
The value of the healed cap drops slightly. This causes that cap to take slightly more than its share of the applied voltage due to potential divider action of the other caps in the string, making it more likely to fail in the future and causing a runaway if the cap was being run right at the limits. It seems to me that caps directly in parallel will reduce this effect. That's a second vote for direct paralleling.
However, there may be a "killer" reason why paralleling is bad, which outvotes the two consideration above? I suppose that if the parallel connected caps "assist" the electrode vapourisation too well that could splatter the cap being healed.
There's less dismantling to do to identify a single failed cap with only series strings. With parallel strings, an o/c failed cap will probably take its parallel connected brothers with it due to overvoltage. BTW, what is the dominant failure mechanism for polyprop cap failure?
How about updating our Wiki MMC entry if we come to any good conclusion?
<edit> A lot of the manufacturers' literature on self-healing majors on the metalised types, whereas we prefer to use film/foil for the higher current handling in TC use. Metalised need much less energy to zap the electrodes than a foil type. Many make their electrodes segmented to introduce "fuses" deliberately between the sections to control the self healing action better. Just some further complicating considerations. </edit>
Registered Member #1253
Joined: Tue Jan 22 2008, 02:06PM
Location:
Posts: 39
Ok, so 8 .068uF caps in series will give me .0085uF, this is 1.5 times over resonance. So if I put a 22M Ohm resistor in parallel with each cap I should be ok?
Sorry to the mods for being new here and not knowing the the "rules", but their is no need to be a douche.
Registered Member #30
Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
Film/foil caps don't self heal. If they do, it's because they have a metallized film conductor internally, which all higher voltage film/foil caps do. (They are two sections in series, and the metallized film connects them together.)
This has all been discussed in agonizing detail on the Pupman list more times than I can remember, so a browse of the Pupman archives may bring up more information. I also remember someone recommending not to connect self-healing capacitors in parallel, but don't know if it was authoritative.
BTW, sorry about the 400 pixel thing, but it's in the rules you agreed to when you joined up, and calling me a douchebag doesn't help. (Neither does using their instead of there.)
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.
MMC Design
