On Sun, 09 Dec 2012 10:10:37 -0800, Fred Abse
<excretatauris@invalid.invalid> wrote:

>
>The PSU is the sacrificial item, not the load. We must assume that it =
has
>been designed or selected with all possible fault conditions of itself
>considered.

Your work may be of that caliber and some others around here, but to
project that competence on all other engineers and their management is
surely specious.

?-)

On Sunday, December 9, 2012 1:10:37 PM UTC-5, Fred Abse wrote:

> The purpose of the crowbar is to protect the load.=20

The purpose of the crowbar is to protect the load by 1) reducing output to =
voltage to zero AND 2) activating the overcurrent protection.

If you don't blow a fuse or trip a breaker, you don't have a crowbar. And f=
or each of those devices you need a crowbar current in excess of 10x pass c=
urrent rating unless you want to wait the better part of a second in the ca=
se of a fuse and minutes in the case of a breaker. If your source does not =
supply that kind of current then you need an energy storage device to do it=
.

On Sat, 01 Dec 2012 15:46:58 -0700, Jim Thompson wrote:

> Sounds like a couple of amateurs when it comes to computing I^2*t >:-}

Pas du tout.

The purpose of the crowbar is to protect the load. When the SCR fires, the
load voltage drops to the SCR's Vt in a few microseconds. The load is protected.

How long after, or whether at all, the fuse ruptures, depends on the PSU.
If it has foldback protection, the fuse (selected for full-load current)
will handle the reduced current. If there is no such protection,or it has
failed, the fuse will rupture after t>I^2t/I^2. What happens to the PSU
afterward depends on its design and how well its input is protected.

The PSU is the sacrificial item, not the load. We must assume that it has
been designed or selected with all possible fault conditions of itself
considered.

-- 
"For a successful technology, reality must take precedence 
over public relations, for nature cannot be fooled."
                                       (Richard Feynman)

On Sun, 02 Dec 2012 00:46:59 -0500, legg wrote:

> Applying the crowbar to the output is the most effective way of reducing
> potential damage to the load - which is it's intended function.

Yup.

Two-hundred-buck PSU toast - pick up the phone.

Ten thousand buck load toast - fifteen aspirin headache.

-- 
"For a successful technology, reality must take precedence 
over public relations, for nature cannot be fooled."
                                       (Richard Feynman)

On 12/3/2012 3:27 AM, legg wrote:

> ........
>
> Inheriting a design group and their work is not an easy job. It takes
> great skill, to avoid losing people, product and customers.
>
> RL
It does, thanks for noticing.

I've been thinking about how to respond to some of your other inputs.
I've decided that the polite thing to say is, "I'm speechless."

On Monday, December 3, 2012 6:04:29 AM UTC-5, legg wrote:
> On Sun, 02 Dec 2012 21:18:11 GMT, Ralph Barone
> 
> <address_is@invalid.invalid> wrote:
> 
> 
> 
> >mike <ham789@netzero.net> wrote:
> 
> >> On 12/2/2012 8:42 AM, legg wrote:
> 
> >> 
> 
> >>> 
> 
> >>> OVP thresholds of the crude cowbar circuit are set higher than the
> 
> >>> circuit function can normally achieve. This would be a voltage higher
> 
> >>> than any battery you might attempt to charge with this normal output.
> 
> >> 
> 
> >>> RL
> 
> >> 
> 
> >> You're exhibiting symptoms of the pervasive disease I seek to eradicate/prevent.
> 
> >> It's known by various names...
> 
> >> Tunnel vision.
> 
> >> Not invented here.
> 
> >> I'm too smart for my own good syndrome.
> 
> >> Pervasive incompetence.
> 
> >> 
> 
> >> Infected engineers get defensive and tell you why you're wrong
> 
> >> according to their limited view of the COMPONENT.
> 
> >> 
> 
> >> The guys you want doing your design reviews listen to what's being
> 
> >> said in SYSTEM context and figure out how broadening their
> 
> >> view might make their
> 
> >> designs better.  They look for learning opportunities, not arguments.
> 
> >> 
> 
> >> Power supplies are frequently subjected to conditions not
> 
> >> spelled out in the spec.
> 
> >> The spec may not say much about AC line transients.  Inexperienced
> 
> >> engineers may not pay attention to that at all.  Same for load transients.
> 
> >> 
> 
> >> Pick a power supply.  Grab the schematic and the designer.
> 
> >> Ask, "what happens at this node when I rip the line cord out of the wall?"
> 
> >> Most won't have even considered the possibility.
> 
> >> 
> 
> >> I'm not saying that it's hard to design a crowbar circuit that
> 
> >> doesn't have the problem.  I'm saying that, if you're not
> 
> >> paying attention, it's easy to let a bad design get through.
> 
> >> Crowbar misbehavior is not an isolated case as evidenced by other
> 
> >> inputs to this thread.
> 
> >> 
> 
> >> You'll recall that I asked a question about the application.
> 
> >> For a dedicated application, a less-than-optimal crowbar may not be
> 
> >> an issue.
> 
> >> 
> 
> >> Here's the backstory that gets me so excited about power supplies.
> 
> >> 
> 
> >> I inherited a hardware group designing a computer workstation.
> 
> >> One component was a custom power supply designed by a local
> 
> >> power supply house.
> 
> >> We'd seen prototypes.
> 
> >> Our engineer went down the spec sheet running tests and signed
> 
> >> off on the design.
> 
> >> But when they got put into computers, we had random failures.
> 
> >> The design firm denied responsibility because our engineer
> 
> >> couldn't reproduce the symptom.  This went on for months.
> 
> >> 
> 
> >> I finally gave up an took one home over the weekend.
> 
> >> I returned on Monday with a test fixture.
> 
> >> I invited the designer and his boss in for a demo.
> 
> >> They brought their latest revision.
> 
> >> I put a current probe on the transformer primary
> 
> >> and a transient load synchronized to the switcher.
> 
> >> By moving the load transient across the timing cycle, I could
> 
> >> change the duty factor off 50% and walk the drain current
> 
> >> right up the saturation curve.
> 
> >> I gave 'em safety glasses and asked them to put their fingers
> 
> >> in their ears as I embedded pieces of FET in the ceiling.
> 
> >> I then asked how many more they wanted me to destroy before they
> 
> >> got the message.
> 
> >> The problem wasn't on the spec sheet.
> 
> >> The problem wasn't on the schematic.
> 
> >> It was on the layout.
> 
> >> After all that, they still couldn't get it right.
> 
> >> 
> 
> >> I expect that if I'd suggested here that someone build
> 
> >> a current transient tester capable of 10 amps in 10ns, I'd have
> 
> >> been told I was an idiot.
> 
> >> All I can say is that it's often quicker, easier, cheaper to run
> 
> >> the test than to argue why it won't work.  But I digress...
> 
> >> Back to the story.
> 
> >> 
> 
> >> Purchasing fired 'em and contracted with a firm 500 miles away.
> 
> >> Long story short, the first look at the new schematic showed
> 
> >> it to be identical to the old schematic.
> 
> >> I asked a few questions and discovered that the new firm didn't
> 
> >> have the manpower for our design, so they hired someone.
> 
> >> And who did they hire but the guy who was laid off from the
> 
> >> first local firm.  Didn't see that coming.
> 
> >> 
> 
> >> I threw a hissy-fit, so they hired a consultant "fixer" to clean it up.
> 
> >> I met with the guy.  Took me 15 minutes to decide that he exuded
> 
> >> competence.
> 
> >> 
> 
> >> The new design came in on schedule, on budget, it worked and it flew
> 
> >> through EMC testing with margin to spare.
> 
> >> 
> 
> >> The design was almost identical to the first one.  But it was executed
> 
> >> by someone competent and paying attention to the system details.
> 
> >> 
> 
> >> I wanted to hire him, but he wouldn't work that cheap. ;-)
> 
> >> 
> 
> >> Good times...
> 
> >
> 
> >Great story Mike. As someone who has worked in both the forensics and
> 
> >design departments in a similar field, I can say that it's a lot easier to
> 
> >cultivate the right paranoid attitude when doing post-failure root cause
> 
> >analysis. Insulating the design department from the people handling product
> 
> >failures doesn't help either.
> 
> 
> 
> Transient load testing isn't exactly rocket science; the whole thing
> 
> sounds fishy to me.
> 
> 
> 
> 'Failing to act' early and the use of the term random doesn't suggest
> 
> that a lot of expertise went into field or return failure analysis.
> 
> 
> 
> Sounds more like tight money and toxic communications - not an unusual
> 
> combination.
> 
> 
> 
> RL

And since when has there been a flyback controller chip without current sense shut-down protection or provisions for slow-start? Sounds like junk to me too.

On Sun, 02 Dec 2012 21:55:28 -0500, legg <legg@nospam.magma.ca> wrote:

>On Sun, 02 Dec 2012 11:01:12 -0800, mike <ham789@netzero.net> wrote:
>
>>On 12/2/2012 8:42 AM, legg wrote:
>>
<snip>
>You're getting a bit off-topic for me. I avoid administrative bullshit
>where possible. If you can do it simply by inflating an estimate,
>there's skin off anyone's nose.
>
>Again, you probably got you paid for. Hiring someone for a project

( Not a great demonstration of proof-reading skill here.)

If you can avoid administrative bulshit by pricing yourself out of it,
then there's no skin off anyone's nose.

Again, you probably got what you paid for.
........

Inheriting a design group and their work is not an easy job. It takes
great skill, to avoid losing people, product and customers.

RL

On Sun, 02 Dec 2012 21:18:11 GMT, Ralph Barone
<address_is@invalid.invalid> wrote:

>mike <ham789@netzero.net> wrote:
>> On 12/2/2012 8:42 AM, legg wrote:
>> 
>>> 
>>> OVP thresholds of the crude cowbar circuit are set higher than the
>>> circuit function can normally achieve. This would be a voltage higher
>>> than any battery you might attempt to charge with this normal output.
>> 
>>> RL
>> 
>> You're exhibiting symptoms of the pervasive disease I seek to eradicate/prevent.
>> It's known by various names...
>> Tunnel vision.
>> Not invented here.
>> I'm too smart for my own good syndrome.
>> Pervasive incompetence.
>> 
>> Infected engineers get defensive and tell you why you're wrong
>> according to their limited view of the COMPONENT.
>> 
>> The guys you want doing your design reviews listen to what's being
>> said in SYSTEM context and figure out how broadening their
>> view might make their
>> designs better.  They look for learning opportunities, not arguments.
>> 
>> Power supplies are frequently subjected to conditions not
>> spelled out in the spec.
>> The spec may not say much about AC line transients.  Inexperienced
>> engineers may not pay attention to that at all.  Same for load transients.
>> 
>> Pick a power supply.  Grab the schematic and the designer.
>> Ask, "what happens at this node when I rip the line cord out of the wall?"
>> Most won't have even considered the possibility.
>> 
>> I'm not saying that it's hard to design a crowbar circuit that
>> doesn't have the problem.  I'm saying that, if you're not
>> paying attention, it's easy to let a bad design get through.
>> Crowbar misbehavior is not an isolated case as evidenced by other
>> inputs to this thread.
>> 
>> You'll recall that I asked a question about the application.
>> For a dedicated application, a less-than-optimal crowbar may not be
>> an issue.
>> 
>> Here's the backstory that gets me so excited about power supplies.
>> 
>> I inherited a hardware group designing a computer workstation.
>> One component was a custom power supply designed by a local
>> power supply house.
>> We'd seen prototypes.
>> Our engineer went down the spec sheet running tests and signed
>> off on the design.
>> But when they got put into computers, we had random failures.
>> The design firm denied responsibility because our engineer
>> couldn't reproduce the symptom.  This went on for months.
>> 
>> I finally gave up an took one home over the weekend.
>> I returned on Monday with a test fixture.
>> I invited the designer and his boss in for a demo.
>> They brought their latest revision.
>> I put a current probe on the transformer primary
>> and a transient load synchronized to the switcher.
>> By moving the load transient across the timing cycle, I could
>> change the duty factor off 50% and walk the drain current
>> right up the saturation curve.
>> I gave 'em safety glasses and asked them to put their fingers
>> in their ears as I embedded pieces of FET in the ceiling.
>> I then asked how many more they wanted me to destroy before they
>> got the message.
>> The problem wasn't on the spec sheet.
>> The problem wasn't on the schematic.
>> It was on the layout.
>> After all that, they still couldn't get it right.
>> 
>> I expect that if I'd suggested here that someone build
>> a current transient tester capable of 10 amps in 10ns, I'd have
>> been told I was an idiot.
>> All I can say is that it's often quicker, easier, cheaper to run
>> the test than to argue why it won't work.  But I digress...
>> Back to the story.
>> 
>> Purchasing fired 'em and contracted with a firm 500 miles away.
>> Long story short, the first look at the new schematic showed
>> it to be identical to the old schematic.
>> I asked a few questions and discovered that the new firm didn't
>> have the manpower for our design, so they hired someone.
>> And who did they hire but the guy who was laid off from the
>> first local firm.  Didn't see that coming.
>> 
>> I threw a hissy-fit, so they hired a consultant "fixer" to clean it up.
>> I met with the guy.  Took me 15 minutes to decide that he exuded
>> competence.
>> 
>> The new design came in on schedule, on budget, it worked and it flew
>> through EMC testing with margin to spare.
>> 
>> The design was almost identical to the first one.  But it was executed
>> by someone competent and paying attention to the system details.
>> 
>> I wanted to hire him, but he wouldn't work that cheap. ;-)
>> 
>> Good times...
>
>Great story Mike. As someone who has worked in both the forensics and
>design departments in a similar field, I can say that it's a lot easier to
>cultivate the right paranoid attitude when doing post-failure root cause
>analysis. Insulating the design department from the people handling product
>failures doesn't help either.

Transient load testing isn't exactly rocket science; the whole thing
sounds fishy to me.

'Failing to act' early and the use of the term random doesn't suggest
that a lot of expertise went into field or return failure analysis.

Sounds more like tight money and toxic communications - not an unusual
combination.

RL

On a sunny day (Sun, 2 Dec 2012 10:56:05 -0800 (PST)) it happened
bloggs.fredbloggs.fred@gmail.com wrote in
<840a164e-eb63-4804-8938-5d078db1d71f@googlegroups.com>:

>I deleted that post on Google- see follow-up with capacitor on other side of fuse - <smacks self in head >


There is likely no universal solution.
Question to be asked first is:
WHAT do you want to protect.
I remember a technician wiring the mains to a 24 volt bus of a big PLC system.
It killed many many expensive PLC cards.
If your crowbar only kills primary circuit,
then it does NOT protect the load against external voltage sources.
And in installation this is a much more likely error condition than in normal operation
a voltage going high.
Also it depends on the kind of supply, in case of a switcher with output transformer separation,
maybe you can simply switch the control chip off as protection against over voltage.

On Sun, 02 Dec 2012 11:01:12 -0800, mike <ham789@netzero.net> wrote:

>On 12/2/2012 8:42 AM, legg wrote:
>
>>
>> OVP thresholds of the crude cowbar circuit are set higher than the
>> circuit function can normally achieve. This would be a voltage higher
>> than any battery you might attempt to charge with this normal output.
>
>> RL
>
>You're exhibiting symptoms of the pervasive disease I seek to 
>eradicate/prevent.
>It's known by various names...
>Tunnel vision.
>Not invented here.
>I'm too smart for my own good syndrome.
>Pervasive incompetence.
>
>Infected engineers get defensive and tell you why you're wrong
>according to their limited view of the COMPONENT.
>
>The guys you want doing your design reviews listen to what's being
>said in SYSTEM context and figure out how broadening their
>view might make their
>designs better.  They look for learning opportunities, not arguments.
>
>Power supplies are frequently subjected to conditions not
>spelled out in the spec.
>The spec may not say much about AC line transients.  Inexperienced
>engineers may not pay attention to that at all.  Same for load transients.
>
>Pick a power supply.  Grab the schematic and the designer.
>Ask, "what happens at this node when I rip the line cord out of the wall?"
>Most won't have even considered the possibility.
>
>I'm not saying that it's hard to design a crowbar circuit that
>doesn't have the problem.  I'm saying that, if you're not
>paying attention, it's easy to let a bad design get through.
>Crowbar misbehavior is not an isolated case as evidenced by other
>inputs to this thread.
>
>You'll recall that I asked a question about the application.
>For a dedicated application, a less-than-optimal crowbar may not be
>an issue.
>
>Here's the backstory that gets me so excited about power supplies.
>
>I inherited a hardware group designing a computer workstation.
>One component was a custom power supply designed by a local
>power supply house.
>We'd seen prototypes.
>Our engineer went down the spec sheet running tests and signed
>off on the design.
>But when they got put into computers, we had random failures.
>The design firm denied responsibility because our engineer
>couldn't reproduce the symptom.  This went on for months.
>
>I finally gave up an took one home over the weekend.
>I returned on Monday with a test fixture.
>I invited the designer and his boss in for a demo.
>They brought their latest revision.
>I put a current probe on the transformer primary
>and a transient load synchronized to the switcher.
>By moving the load transient across the timing cycle, I could
>change the duty factor off 50% and walk the drain current
>right up the saturation curve.
>I gave 'em safety glasses and asked them to put their fingers
>in their ears as I embedded pieces of FET in the ceiling.
>I then asked how many more they wanted me to destroy before they
>got the message.
>The problem wasn't on the spec sheet.
>The problem wasn't on the schematic.
>It was on the layout.
>After all that, they still couldn't get it right.
>
>I expect that if I'd suggested here that someone build
>a current transient tester capable of 10 amps in 10ns, I'd have
>been told I was an idiot.
>All I can say is that it's often quicker, easier, cheaper to run
>the test than to argue why it won't work.  But I digress...
>Back to the story.
>
>Purchasing fired 'em and contracted with a firm 500 miles away.
>Long story short, the first look at the new schematic showed
>it to be identical to the old schematic.
>I asked a few questions and discovered that the new firm didn't
>have the manpower for our design, so they hired someone.
>And who did they hire but the guy who was laid off from the
>first local firm.  Didn't see that coming.
>
>I threw a hissy-fit, so they hired a consultant "fixer" to clean it up.
>I met with the guy.  Took me 15 minutes to decide that he exuded
>competence.
>
>The new design came in on schedule, on budget, it worked and it flew
>through EMC testing with margin to spare.
>
>The design was almost identical to the first one.  But it was executed
>by someone competent and paying attention to the system details.
>
>I wanted to hire him, but he wouldn't work that cheap. ;-)
>
>Good times...
>
You're getting a bit off-topic for me. I avoid administrative bullshit
where possible. If you can do it simply by inflating an estimate,
there's skin off anyone's nose.

Again, you probably got you paid for. Hiring someone for a project
after a few minutes, because he 'exuded competence', is a pretty good
example of administrative bullshit, if ever I've heard it. Competence
is demonstrated, not discharged through the skin, or smelled.

Next time, just widen your search, based on recommendation and realize
before-hand that one man does not a power design lab make and that
other inputs are required before you can switch from out-sourcing to
in-house development of some kinds of hardware.

RL