Why a method beats experience alone

Run the senior engineer's loop on any fault — symptom, hypotheses, cheapest discriminating test, result — and recognise when experience or an error code is leading you to the wrong part.

The cost of guessing

Every service engineer has done it: the machine shows an error, you have seen something like it before, you order the part that fixed it last time, and you fit it. Sometimes the fault goes away. Often it does not, and now you have a new board on the bench, a machine still down, a clinic that is losing patients and a manager who wants to know why the bill is so high.

Guessing has four costs. The first is money: parts for imaging and laboratory equipment are expensive, and many cannot be returned once they have been fitted. The second is time: each wrong part means another delivery, another visit, another day of downtime. The third is risk: every time you open a machine, unplug a connector or replace a board you can create a new fault, disturb a calibration or damage a part that was healthy. The fourth is trust: a clinic remembers the engineer who replaced three boards and the fault came back.

There is a quieter cost too. When you replace a part and the fault disappears, you learn that this part causes this symptom, even if the real cause was the connector you unplugged and re-seated while fitting it. Guessing teaches you wrong lessons, and they feel exactly like experience.

What experience gives you, and where it fails

Experience is valuable. A senior engineer recognises patterns quickly: this sound means a bearing, this smell means a capacitor, this error on this model usually means the cable in the moving arm. Pattern recognition is what makes experienced engineers fast, and you should build it deliberately.

The trouble is that pattern recognition answers 'what is this usually?' and the job asks 'what is it this time?'. On an X-ray unit that would not switch on and showed a start-up error, the engineers' first suspect was the emergency stop button on the panel, a known weak point on that model. The real cause was a limit switch on the tube stand that even passed a continuity test. A test of the limit-switch circuit found the open contact, and that switch was condemned. The known weak point was a reasonable first hypothesis. It became a mistake only when nobody tested it against the others.

Experience also anchors you. Once you have decided what the fault is, you start noticing the facts that support it and explaining away the ones that do not. Every engineer does this; a method is how you protect yourself from it.

The senior engineer's loop

Watch a good senior engineer work and you will see the same loop every time, even if he never describes it. It has four steps, and he repeats them until the fault is found.

Symptom: state precisely what is wrong, in observable terms. Not 'the analyser is broken' but 'the analyser starts, aspirates the sample, and reports a clog on both cell counts with very low values'. A precise symptom already rules things out.

Hypotheses: list the possible causes, at least two or three, including the unexciting ones — supply, cable, settings, consumables, operator technique, environment. Write them down. A hypothesis you have written down is one you can test; a hypothesis in your head is one you will defend.

Cheapest discriminating test: choose the test that best separates your hypotheses for the least cost, time and risk. 'Discriminating' is the important word. A test that would give the same result whichever hypothesis is true teaches you nothing, however clever it is.

Result: do the test, write down what you saw, and update your list. Some hypotheses die, some become more likely, sometimes a new one appears. Then go round again.

• Symptom: what exactly, when, how often, under which conditions.
• Hypotheses: at least two or three, including power, cables, settings and consumables.
• Test: the cheapest, safest test whose result differs between hypotheses.
• Result: recorded before the next step, and the list updated.

Choosing the next test

For each hypothesis ask two questions: how likely is it, and how much does it cost to test? Cost means time, money, risk to the machine and risk to you. A visual inspection, a look at the error history, a check of the supply or of the consumables costs minutes. Swapping a board costs hours and may cost the board. A likely cause that is cheap to test goes first. An unlikely cause that is very cheap to test often goes early too, because ruling it out costs almost nothing.

Then ask: what would I expect to see if this hypothesis were true, and what if it were false? If you cannot answer, you do not yet understand the hypothesis well enough to test it. On a haematology analyser that kept reporting clogs after a corroded electrode wire was repaired, the wire measured perfectly. The engineer kept looking at the hardware for three days. The reagents had been stored badly and were spoiled. A run with fresh reagents is cheap and separates 'hardware' from 'chemistry' in one step; it should have been one of the first tests, not the last.

Prefer tests that can prove you wrong. If you think a pump is weak, measure what it produces rather than listening to it. If you think a board is faulty, look for a measurement at its inputs and outputs that would show the board receiving good signals and producing bad ones.

Error codes are where the machine noticed

An error code is produced by a monitoring circuit or a piece of software that checks a condition: a voltage in range, a pressure reached in time, a sensor answering, a switch in the expected state. It tells you which check failed. It does not tell you why.

On a tabletop sterilizer that aborted with a vacuum error, the obvious hypotheses were a leak or a weak vacuum pump. The cause was a flat backup battery. On an electrosurgical unit, a start-up error that the documentation linked to a pressed footswitch was caused by a burnt track and failed components on a relay board; the processor board was fine. On another X-ray unit, an error that the manual linked to a potentiometer was caused by a broken cable at the potentiometer's connector.

So read the error code as a pointer to a circuit, not to a part. Ask: what does this check measure, what feeds it, and what else could make it fail? The sensor, its cable, its connector, its supply and the thing it measures are all on the list.

When to stop and step back

If you have done three tests and your list has not changed, something is wrong with the list, not with the machine. Go back to the symptom. Re-read the log. Ask the user again what happened just before the fault. Check the things you assumed: is that really the right test bag, the right software version, the right mains phase?

Time-box your work. Decide in advance how long you will spend before you ask a colleague, call the manufacturer's support or take the unit to the bench. Asking early, with clear notes of what you have tested, is a sign of a senior engineer, not a weak one.

None of this changes the safety rules. You never test a hypothesis on equipment connected to a patient. You isolate and lock off before opening, discharge stored energy as the manufacturer describes, and treat radiation, high voltage, gas under pressure, cryogens and contaminated parts with the procedures they require. Electrical hazards are covered in detail in the Electrical Safety course; the method in this course always works inside those rules.

On-site checklist

• Write the symptom in observable terms before you touch anything.
• List at least two or three hypotheses, including supply, cable, settings and consumables.
• For each test, know what result you expect if each hypothesis is true.
• Do cheap, safe, likely tests first; board swaps last.
• Record each result before the next step.
• Read an error code as a failed check on a circuit, not as a part number.
• If three tests have not changed your list, go back to the symptom.
• Never test on equipment connected to a patient.

Check yourself