From: Alex Simpson on



> Again, no shorts here.  Everything *worked"

Pardon me but if everything "worked" fuse would Not be blowing.

My first thought to a 2-3 day fuse is an "intermittent" problem.

Some ways I handle the intermittent is by close up observation of the
boards, heating and or tapping components out.


> After tracking down the problem, it occurred to me just
how hard it is to do such things.

We all know if it is not a loose connection Intermittent are not easy.


> So, how *should* this problem have been approached (without
risk to the set),

As much as I hate saying/doing this - Sometimes risk is the only way
to the solution....



But since it is already fixed I think the best answer to your question
would be if we knew how you fix it.


Gabe



From: Phil Allison on

"Alex Simpson"

But since it is already fixed I think the best answer to your question
would be if we knew how you fix it.


** Of course, once the nature of the INTERMITTENT fault scenario is known
one can usually determine a faster way of discovering it.

But the OP is playing a childish game with us and LYING about what really
went on.



..... Phil








From: D Yuniskis on
Alex Simpson wrote:
>> Again, no shorts here. Everything *worked"
>
> Pardon me but if everything "worked" fuse would Not be blowing.

Sure they can! All the fuse blowing means is the load
was drawing *nominally* more power than the fuse was
rated. E.g., a typical 3AG fuse will carry 110% of
its rated load for several hours. Given that this
fuse lasted *days*, means it was operating near its
rated capacity.

I.e., nothing *severe*.

Since there is no way of knowing (from the service
documents) what the *intended* load was, it could be
the system was just drawing 10-20% more than expected
(though I doubt that since proper derating for ambient
would typically have the fuse operating at ~60-70% of
it's rated current).

> My first thought to a 2-3 day fuse is an "intermittent" problem.

No. An intermittent wouldn't take (roughly) the same amount
of time to show up each time the fuse blew.

> Some ways I handle the intermittent is by close up observation of the
> boards, heating and or tapping components out.
>
>> After tracking down the problem, it occurred to me just
> how hard it is to do such things.
>
> We all know if it is not a loose connection Intermittent are not easy.



>> So, how *should* this problem have been approached (without
> risk to the set),
>
> As much as I hate saying/doing this - Sometimes risk is the only way
> to the solution....
>
> But since it is already fixed I think the best answer to your question
> would be if we knew how you fix it.

You're missing the point of my question.

You are suggesting that, in fact, the way to "solve" such problems
is to ask someone who solved a similar problem previously! So,
when you come up with a problem that someone else *hasn't*
solved, you're SOL.

My comments regarding the lack of information necessary to
track down this sort of problem suggests that service
documents should carry additional information. And,
possibly, minor changes to circuit topologies to make
this sort of troubleshooting easier.

E.g., if you have a (removable) fuse, you have an *easy*
way to monitor current through that branch of a circuit.
Adding a note on the drawing set indicating what this
current should be, nominally, goes a long way to sorting
out what problems may exist "in the field".

Likewise, *adding* disposable components to circuit
paths to facilitate opening that path to monitor current
can be a big win (e.g., FB's or 0 ohm shunts in the
secondaries of the switching transformer in my example...
easy to replace)

Of course, the conditions for all measurements have to be
codified else low line, high line, component variations,
etc. can make them meaningless (if the primary increases
by 10%, current decreases inverse proportionately, etc.).

Likewise, scope traces with real times/duty cycles
noted gives you an idea if things are operating at (or
near) their correct operating point.

Hoping to see repeat failures of the same sort is
a losing strategy (as it relies on design flaws instead
of component failures)