This is a question that cuts across most fields. I have a young tech that I
am training and attempting to accelerate his development as much as
possible. Recognizing that it takes years of doing repairs to master the
skills involved in troubleshooting and repairing electronics, I still want
to make him as useful as possible as quickly as possible. If anyone has
suggestions I welcome them.

I see most problems solving as a matter of both inductive and deductive
reasoning. The ability to use both, recognize when either is getting you to
the result needed, recognizing when your assumptions need to be checked,
your facts need to be checked, and your steps in reasoning need to be
checked is key to effectively fixing things.

My method is essentially to give him jobs that I know he can complete, but
also give him the ones that I know he will get stuck on and as he gets
stuck, talk him through the process that I would use to figure out the
problem. My basic routine is to gather the information (complaint and
related info, observe the symptoms and condition, look for the obvious,
etc), search my memory, notes, and databases for info relevant to the
problem and device, block diagram the system mentally, then break it down
into the likely areas of the problem.

Where I see him (us) getting stuck is often due to the assumptions made,
both about the system and about the facts found. The solution is often to
gather more facts (use the scope, dumbass), but often also to test the
conclusions that we come to that are based on preconceptions and
expectations. Of course, we get to be efficient in this business by
recognizing patterns and getting to the problem quickly, but there has to be
a balance between the two extremes of treating everything as symptom-repair
(inductive) and getting mired in making measurements and test set-ups
(deductive). Walking that line can make the difference between an efficient
and profitable shop and one that fails.

Any suggestions or discussion of your methods?

Leonard

One way to learn, is to get a job in a service centre that will allow him to
work on customer's equipment. He will have to simply struggle along to
learn. He will be servicing mainly older appliances, and electronic devices.

The very first thing he will have to know very well is the basic theories in
electronics. The more details he knows and understands, the easier it will
be to troubleshoot the equipment. Then there is the practice of applying
what one knows.

The unfortunate part is that much of the newer equipment is designed to not
be serviced, or only serviced at the board level if it is an expensive type
of device. During the proto-typing, these systems are troubleshooted by the
engineering groups that are doing the design. Once done, the runs are put
out for the distribution of the product.

For the field service during warranty, most of the products are serviced by
changing them completely, or changing a complete board or assembly. The only
thing the tech has to do is the calibration, with the proper tools, jigs,
and equipment. Many of the new types of products are complex, and the
authorized service reps get the proper training for the lines of products
that they will be contracted to service.

As far as the service information is concerned for the new products, there
is no outside support for many of the models. This is why parts, service
manuals, and schematics are not available for many of these. For many of the
units that are serviced at the board level only, there are no schematics of
the boards published for services. The authorized service reps would get the
calibration instructions only, with a basic wiring diagram.

This is part of the reason why appliances have become so low in cost today.
Having the infostructure for parts and service is a cost to the manufacture.
By cutting this cost, they can sell at a lower price. This means higher
volumes of sales, and greater profits over the long run.


--

Jerry G.
==========================


"Leonard Caillouet" wrote in message
news:yHC%c.16336$aW5.945@fed1read07...
This is a question that cuts across most fields. I have a young tech that I
am training and attempting to accelerate his development as much as
possible. Recognizing that it takes years of doing repairs to master the
skills involved in troubleshooting and repairing electronics, I still want
to make him as useful as possible as quickly as possible. If anyone has
suggestions I welcome them.

I see most problems solving as a matter of both inductive and deductive
reasoning. The ability to use both, recognize when either is getting you to
the result needed, recognizing when your assumptions need to be checked,
your facts need to be checked, and your steps in reasoning need to be
checked is key to effectively fixing things.

My method is essentially to give him jobs that I know he can complete, but
also give him the ones that I know he will get stuck on and as he gets
stuck, talk him through the process that I would use to figure out the
problem. My basic routine is to gather the information (complaint and
related info, observe the symptoms and condition, look for the obvious,
etc), search my memory, notes, and databases for info relevant to the
problem and device, block diagram the system mentally, then break it down
into the likely areas of the problem.

Where I see him (us) getting stuck is often due to the assumptions made,
both about the system and about the facts found. The solution is often to
gather more facts (use the scope, dumbass), but often also to test the
conclusions that we come to that are based on preconceptions and
expectations. Of course, we get to be efficient in this business by
recognizing patterns and getting to the problem quickly, but there has to be
a balance between the two extremes of treating everything as symptom-repair
(inductive) and getting mired in making measurements and test set-ups
(deductive). Walking that line can make the difference between an efficient
and profitable shop and one that fails.

Any suggestions or discussion of your methods?

Leonard

Those are good observations.

An absolutely key point is that the process requires multiple steps. We do
not go straight from symptom to repair.

Another is that we have to keep track of the level of certainty of each
step, and even the prior steps that it is based on. Don't mix up hypotheses
with certainties. Some logicians call this "labeled logic." The reason
it's necessary is that if you find out a guess was a mistake, you have to
roll back exactly the right part of your reasoning.

Yet another thing... Just as in medical diagnosis, it's important to have a
sense of probabilities. For example, a defective switch or electrolytic
capacitor is much more probable than a defective low-power resistor.

As physicians say, "When you hear hoofbeats, think horses, not zebras."

Of course there are moments when I say, "When you hear hoofbeats, think
duckbilled platypus"...

....which brings up another point with a medical analogy. Specialists see
disproportionately many rare problems, and they lose perspective on how rare
they are. The general practitioner actually sees the population, without
waiting for referral from another doctor, and is more aware of population
statistics -- but also, perhaps, prejudiced to miss rare diagnoses.

"Leonard Caillouet" bravely wrote to "All" (08 Sep 04 07:26:45)
--- on the heady topic of "Electronics problem solving skills, inductive and
deductive reasoning."

LC From: "Leonard Caillouet"

LC This is a question that cuts across most fields. I have a young tech
LC that I am training and attempting to accelerate his development as much
LC as possible. Recognizing that it takes years of doing repairs to
LC master the skills involved in troubleshooting and repairing
LC electronics, I still want to make him as useful as possible as quickly
LC as possible. If anyone has suggestions I welcome them.

[,,,]

LC Any suggestions or discussion of your methods?


Teach him to be pro-active in the approach to a problem repair.
Sitting back and getting stuck is a waste of time. One has to keep an
open mind and try new solutions in such situations. Repair is more
than simply fitting the clues into a troubleshooting flow chart.
If a problem is illusive then one must provoke it to appear.
Most of all sometimes an obvious fault is simply a symptom of another
hidden cause, for example a blown line fuse is a classic case and any
number of subsystems may be defective.

A*s*i*m*o*v

.... If all else fails, hurl it across the room a few times!

Well written, but I'd like to share a slightly different perspective. My
situation is different because I work for an independent shop. A few
manufacturers will pay us, but usually it's TCE and it's because the customer
requested that we do the work rather than the ASC down the street.We don't need
the work but we don't turn it down, we like the COD work, but then we sell our
own contracts, so there are those days........

You describe two thought processes in a different way than I. I prefer to see
it as geometry almost. There is forward thinking, what do I need to know next.
Don't think you're done, keep forward, i.e. if the fusible is open you
definitely need at aleast one more piece of info.

For example the fusible to the audio is open, of course you see if it's a
short. Your attention is there, hopefully at the end of the forward process. If
the IC is $15 or less I change it at the same time as the fusible. This I
consider lateral thinking. Knowing the IC went thermal, or was only an overload
at operating voltage is not too valuable as notable technical knowledge at this
price.

Now if you take the chain to the end and put the IC in, and it's the only thing
that fusible feeds, and it blows again, this is the time to pay the most
attention.

Now is the time for more lateral thinking. You don't back up to the fuse, but
just as technically the cost of the IC is tertiary, at this point something
tertiary to that chip is at fault. To find it you head in that direction. Of
course you have already checked that the supply isn't way high. Actually if
that were the case you would have to go "backwards" to the power supply. One
way to describe this would be omnidirectional thinking.

One other thing that is VERY important. These inductive and deductive terms are
one thing, but in reality you must be able to determine what does or not prove
your theory. You also must be able to tell what does or doesn't udis/uprove
your theory. Can you say for sure it IS this, or that it IS NOT this. These two
"directions" of logic are diametrically opposed, but both are necessary. (are
we saying almost the same things ?)

You should encourage your protoge to read all the replies. Different people
communicate differently, and "on any given Sunday" even someone younger might
get something more, or different from any given respondent.

I would highly suggest he also read my "RCA does it again" post. It's
importance comes from the fact that, as much as you do need to know what to do,
you need to know what not to do uFIRST/u.

The guy screwed up the 3 panel LCD assy, oh man. I wasn't even really asking
for help, I know we're beyond help on this one. Some comment would be nice but
I know we're screwed.In fact the light from screwed takes 10 minutes to reach
us. I'm sure your guy knows the simple, don't change the fuse first, the usual,
but in the future there will be alot of screwed up "don't dos" so he needs to
get ready for them as well as the rest of us.

JURB

"Jerry G." wrote in message
...

The unfortunate part is that much of the newer equipment is designed to
not
be serviced, ...
For the field service during warranty, most of the products are serviced
by
changing them completely, or changing a complete board or assembly.

We've been through several cycles of this already, of course. In the 1950s
people commonly replaced just the paper cone of a speaker, or just the voice
coil. Now a speaker is a component. Similarly, nowadays a circuit board is
a component, as far as manufactured equipoment is concerned. Circuit boards
are basically custom hybrid ICs.

"Michael A. Covington" wrote in message
...
Yet another thing... Just as in medical diagnosis, it's important to have
a
sense of probabilities. For example, a defective switch or electrolytic
capacitor is much more probable than a defective low-power resistor.



Though for a while it was shocking how many bad low power resistors I
encountered in stuff, I fixed 3 or 4 monitors in a row (and keep in mind I'm
a hobbiest not a shop) that were fixed by replacing only resistors.

I run a shop for a mid to high end A/V retailer that does mostly custom home
installations. He has an AA degree in electronics and good basic knowledge,
along with several years of service experience. The point is that I am
training him and am trying to figure out how to make the best of his time,
not just have him muddle through and learn by trial and error only.
Learning does not have to be only about struggling through problems. It can
be made more efficient in many ways if one understands clearly the
principles underlying an endeavor. I am trying to better understand the
process of problem solving as it applies to repair. By doing so I hope to
become more efficient myself and best utilize and enhance his skills.

Leonard

"Jerry G." wrote in message
...
One way to learn, is to get a job in a service centre that will allow him
to
work on customer's equipment. He will have to simply struggle along to
learn. He will be servicing mainly older appliances, and electronic
devices.

The very first thing he will have to know very well is the basic theories
in
electronics. The more details he knows and understands, the easier it will
be to troubleshoot the equipment. Then there is the practice of applying
what one knows.

The unfortunate part is that much of the newer equipment is designed to
not
be serviced, or only serviced at the board level if it is an expensive
type
of device. During the proto-typing, these systems are troubleshooted by
the
engineering groups that are doing the design. Once done, the runs are put
out for the distribution of the product.

For the field service during warranty, most of the products are serviced
by
changing them completely, or changing a complete board or assembly. The
only
thing the tech has to do is the calibration, with the proper tools, jigs,
and equipment. Many of the new types of products are complex, and the
authorized service reps get the proper training for the lines of products
that they will be contracted to service.

As far as the service information is concerned for the new products, there
is no outside support for many of the models. This is why parts, service
manuals, and schematics are not available for many of these. For many of
the
units that are serviced at the board level only, there are no schematics
of
the boards published for services. The authorized service reps would get
the
calibration instructions only, with a basic wiring diagram.

This is part of the reason why appliances have become so low in cost
today.
Having the infostructure for parts and service is a cost to the
manufacture.
By cutting this cost, they can sell at a lower price. This means higher
volumes of sales, and greater profits over the long run.


--

Jerry G.
==========================


"Leonard Caillouet" wrote in message
news:yHC%c.16336$aW5.945@fed1read07...
This is a question that cuts across most fields. I have a young tech that
I
am training and attempting to accelerate his development as much as
possible. Recognizing that it takes years of doing repairs to master the
skills involved in troubleshooting and repairing electronics, I still want
to make him as useful as possible as quickly as possible. If anyone has
suggestions I welcome them.

I see most problems solving as a matter of both inductive and deductive
reasoning. The ability to use both, recognize when either is getting you
to
the result needed, recognizing when your assumptions need to be checked,
your facts need to be checked, and your steps in reasoning need to be
checked is key to effectively fixing things.

My method is essentially to give him jobs that I know he can complete, but
also give him the ones that I know he will get stuck on and as he gets
stuck, talk him through the process that I would use to figure out the
problem. My basic routine is to gather the information (complaint and
related info, observe the symptoms and condition, look for the obvious,
etc), search my memory, notes, and databases for info relevant to the
problem and device, block diagram the system mentally, then break it down
into the likely areas of the problem.

Where I see him (us) getting stuck is often due to the assumptions made,
both about the system and about the facts found. The solution is often to
gather more facts (use the scope, dumbass), but often also to test the
conclusions that we come to that are based on preconceptions and
expectations. Of course, we get to be efficient in this business by
recognizing patterns and getting to the problem quickly, but there has to
be
a balance between the two extremes of treating everything as
symptom-repair
(inductive) and getting mired in making measurements and test set-ups
(deductive). Walking that line can make the difference between an
efficient
and profitable shop and one that fails.

Any suggestions or discussion of your methods?

Leonard