From: Alex Simpson on 13 Jun 2010 18:52 > 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 13 Jun 2010 20:45 "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 14 Jun 2010 14:06
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) |