Troubleshooting Tips for Electrical /Electronic Maintenance

Troubleshooting Tips
for Electrical /Electronic Maintenance
This
section concentrates on the problems plaguing brand-new systems. In this case,
failure modes are generally not of the aging kind, but are related to mistakes
in design and assembly caused by human beings.
Wiring problems
In
this case, bad connections are usually due to assembly error, such as
connection to the wrong point or poor connector fabrication. Shorted failures
are also seen, but usually involve misconnections (conductors inadvertently
attached to grounding points) or wires pinched under box covers.
Another
wiring-related problem seen in new systems is that of electrostatic or
electromagnetic interference between different circuits by way of close wiring
proximity. This kind of problem is easily created by routing sets of wires too
close to each other (especially routing signal cables close to power
conductors), and tends to be very difficult to identify and locate with test
equipment.
Power supply problems
Blown
fuses and tripped circuit breakers are likely sources of trouble, especially if
the project in question is an addition to an already-functioning system. Loads
may be larger than expected, resulting in overloading and subsequent failure of
power supplies.
Defective components
In
the case of a newly-assembled system, component fault probabilities are not as
predictable as in the case of an operating system that fails with age. Any type
of component – active or passive – may be found defective or of imprecise value
”out of the box” with roughly equal probability, barring any specific
sensitivities in shipping (i.e fragile vacuum tubes or electro statically sensitive
semiconductor components). Moreover, these types of failures are not always as easy
to identify by sight or smell as an age- or transient-induced failure.
Improper system
configuration
Increasingly
seen in large systems using microprocessor-based components,  programming” issues can still plague
non-microprocessor systems in the form of incorrect time-delay relay settings,
limit switch calibrations, and drum switch sequences. Complex components having
configuration”jumpers” or switches to control behavior may not be ”programmed”
properly.
Components
may be used in a new system outside of their tolerable ranges. Resistors, for example,
with too low of power ratings, of too great of tolerance, may have been
installed. Sensors, instruments, and controlling mechanisms may be
uncalibrated, or calibrated to the wrong ranges.
Design error
Perhaps
the most difficult to pinpoint and the slowest to be recognized (especially by
the chief designer) is the problem of design error, where the system fails to
function simply because it cannot function as designed. This may be as
trivial as the designer specifying the wrong components in a system, or as
fundamental as a system not working due to the designer’s improper knowledge of
physics. I once saw a turbine control system installed that used a low-pressure
switch on the lubrication oil tubing to shut down the turbine if oil pressure
dropped to an insufficient level. The oil pressure for lubrication was supplied
by an oil pump turned by the turbine. When installed, the turbine refused to
start. Why? Because when it was stopped, the oil pump was not turning, thus
there was no oil pressure to lubricate the turbine. The low-oil-pressure switch
detected this condition and the control system maintained the turbine in
shutdown mode, preventing it from starting. This is a classic example of a
design flaw, and it could only be corrected by a change in the system logic. While
most design flaws manifest themselves early in the operational life of the
system, some remain hidden until just the right conditions exist to trigger the
fault. These types of flaws are the most difficult to uncover, as the troubleshooter
usually overlooks the possibility of design error due to the fact that the
system is assumed to be”proven.” The example of the turbine lubrication system
was a design flaw impossible to ignore on start-up. An example of a ”hidden”
design flaw might be a faulty emergency coolant system for a machine, designed
to remain inactive until certain abnormal conditions are reached – conditions
which might never be experienced in the life of the system.
Potential pitfalls
Fallacious
reasoning and poor interpersonal relations account for more failed or elabored
troubleshooting efforts than any other impediments. With this in mind, the
aspiring troubleshooter needs to be familiar with a few common troubleshooting
mistakes.
Trusting
that a brand-new component will always be good.
While
it is generally true that a new component will be in good condition, it is not always
true. It is also possible that a component has been mis-labeled and may
have the wrong value (usually this mis-labeling is a mistake made at the point
of distribution or warehousing and not at the manufacturer, but again, not
always
!).
Not
periodically checking your test equipment.
This
is especially true with battery powered meters, as weak batteries may give spurious
readings. When using meters to safety check for dangerous voltage, remember to
test the meter on a known source of voltage both before and after checking
the circuit to be serviced, to make sure the meter is in proper operating condition.
Assuming
there is only one failure to account for the problem.
Single-failure
system problems are ideal for troubleshooting, but sometimes failures come in
multiple numbers. In some instances, the failure of one component may lead to a
system condition that damages other components. Sometimes a component in
marginal condition goes undetected for a long time, and then when another
component fails the system suffers from problems with both components.
Mistaking
coincidence for causality.
Just
because two events occurred at nearly the same time does not necessarily
mean one event caused the other! They may be both consequences of a
common cause, or they may be totally unrelated! If possible, try to duplicate
the same condition suspected to be the cause and see if the event suspected to
be the coincidence happens again. If not, then there is either no causal
relationship as assumed. This may mean there is no causal relationship between
the two events whatsoever, or that there is a causal relationship, but just not
the one you expected.
Self-induced
blindness.
After
a long effort at troubleshooting a difficult problem, you may become tired and
begin to overlook crucial clues to the problem. Take a break and let someone
else look at it for a while. You will be amazed at what a difference this can
make. On the other hand, it is generally a bad idea to solicit help at the
start of the troubleshooting process. Effective troubleshooting involves
complex, multi-level thinking, which is not easily communicated with others.
More often than not, ”team troubleshooting” takes more time and causes more
frustration than doing it yourself. An exception to this rule is when the
knowledge of the troubleshooters is complementary: for example, a technician
who knows electronics but not machine operation, teamed with an operator who
knows machine function but not electronics.
Failing
to question the troubleshooting work of others on the same job.
This
may sound rather cynical and misanthropic, but it is sound scientific practice.
Because it is easy to overlook important details, troubleshooting data received
from another troubleshooter should be personally verified before proceeding.
This is a common situation when troubleshooters”change shifts” and a technician
take over for another technician who is leaving before the job is done. It is
important to exchange information, but do not assume the prior technician checked
everything they said they did, or checked it perfectly. I’ve been hindered in
my troubleshooting efforts on many occasions by failing to verify what someone
else told me they checked.
Being
pressured to”hurry up.”
When
an important system fails, there will be pressure from other people to fix the
problem as quickly as possible. As they say in business, ”time is money.”
Having been on the receiving end of this pressure many times, I can understand the
need for expedience. However, in many cases there is a higher priority:
caution. If the system in question harbors great danger to life and limb, the pressure
to ”hurry up” may result in injury or death. At the very least, hasty repairs
may result in further damage when the system is restarted. Most failures can be
recovered or at least temporarily repaired in short time if approached
intelligently. Improper”fixes” resulting in haste often lead to damage that cannot
be recovered in short time, if ever. If the potential for greater harm is
present, the troubleshooter needs to politely address the pressure received
from others, and maintain their perspective in the midst of chaos.
Interpersonal skills are just as important in this realm as technical ability!
Finger-pointing.
It
is all too easy to blame a problem on someone else, for reasons of Ignorance,
pride, laziness, or some other unfortunate facet of human nature. When the
responsibility for system maintenance is divided into departments or work
crews, troubleshooting efforts are often hindered by blame cast between groups.
”It’s a mechanical problem . . . its an electrical problem . . . its an
instrument problem . . .” ad infinitum, ad nauseum, is all too common in the
workplace. I have found that a positive attitude does more to quench the fires of
blame than anything else.
On
one particular job, I was summoned to fix a problem in a hydraulic system
assumed to be related to the electronic metering and controls. My
troubleshooting isolated the source of trouble to a faulty control valve, which
was the domain of the millwright (mechanical) crew. I knew that the millwright
on shift was a contentious person, so I expected trouble if I simply passed the
problem on to his department. Instead, I politely explained to him and his
supervisor the nature of the problem as well as a brief synopsis of my
reasoning, then proceeded to help him replace the faulty valve, even though it
wasn’t ”my” responsibility to do so. As a result, the problem was fixed very
quickly, and I gained the respect of the millwright.

Leave a Reply