Troubleshooting Method

Troubleshooting an elevator is a method, not a memory game. Units are too varied and faults too intermittent for symptom-answer recall to carry you; what carries you is a sequence: read the evidence, prove the safety chain, split the system in half, and change exactly one thing at a time.

Why it matters on the job

Callbacks are where reputations are made in this trade. A methodical mechanic clears a callback once; a parts-swapper clears it until it comes back. Adjusters are paid for exactly this discipline applied to the hardest cases (the intermittents, the ones that “never do it while you watch”).

The method

1. Read before you touch. Pull the controller fault log and the unit’s recent history. Ask the building what the car was doing, when, and how often. An intermittent’s pattern (one floor? one time of day? one direction?) is half the diagnosis.
2. Verify the symptom. Run the car and reproduce what you can. Confirm what actually fails, not what was reported: “the elevator is broken” arrives at the shop as everything from a leveling error to a stuck reopening device.
3. Prove the safety chain first. If the car will not run, establish whether the safety string is open and where (the controllers lesson worked the meter technique). This one step separates “the unit is protecting itself” from “the unit cannot respond,” and each points somewhere different.
4. Split the system. Divide the suspects in half with each test. Does the fault follow one landing or every landing (door lessons)? One direction or both (hydraulic lessons)? Does it occur under load, at speed, or at rest? Each answer eliminates half the machine.
5. Change one thing, then prove it. One adjustment or one component, then reproduce the original conditions and watch the fault stay gone. Two changes at once means you learn nothing even when it works.
6. Log what you found. The record turns your afternoon into the next mechanic’s ten minutes, and repeat-callback patterns feed the maintenance program.

Worked example: the intermittent shutdown

A microprocessor-controlled traction car shuts down mid-run a few times a week, then restores. The log shows a string of door-interlock faults, each logged while the car was moving between floors 4 and 5.

Split: an operator or gate-switch fault would not care where the car is; a single landing’s interlock would fault at that landing, not between two. What moves past floors 4 and 5 while the car runs? The car itself, and its clutch path. Inspection between those floors finds a landing 5 interlock roller sitting proud, brushing the passing clutch and momentarily opening its contact.

The evidence (which fault, and exactly where) named the component before a single part was touched. That is the method working.

Every answered question cuts the suspects in half: the fastest route from symptom to component

Where it bites

• Swapping boards is not a method. Modern controllers make board-swapping seductive. When the swap “works,” you own a mystery that will return, plus a possibly good board in the trash.
• Intermittents demand evidence, not patience. Waiting around to witness a fault is the slowest tool you have. Logs, patterns, and reproduction under controlled conditions are faster and honest.
• Never troubleshoot past a safety. If the string is open, the answer is to find the open, not to make the car move. The unit is doing its job; do yours in the same spirit.
• Beware the fix that fits the invoice. The correct finding is sometimes ten minutes and a roller. Resist the pull to justify the trip with parts.