Article
Repeat Machine Fault? How to Find the Last Fix That Worked
A repeat machine fault usually has a fix already on file. How to search past service reports by fault code, model and trip conditions to find what worked.
Short answer: To find the fix that worked last time for a repeat machine fault, search your own past service, test and inspection reports by the exact fault code, the machine model and the conditions when it trips, then read the full report. The manual lists possible causes. Your archive holds the cause that was actually found on that machine.
What does a repeat fault look like from the service desk?
Here is a public example. In March 2013 a technician posted on the Siemens Industry Online Support forum about an 18.5 kW MICROMASTER 440 drive. F0001 (overcurrent) kept coming back. Resetting it from the BOP didn't help, cycling main power didn't help, and the motor wouldn't run. He had already checked the motor winding resistance and found it balanced.
The first reply pasted the manual's cause list: short circuit on the output, earth fault, motor too large, output stage faulty. Then came the standard checks: cable length, motor parameters, stator resistance (P0350), ramp time, boost.
The useful reply came later. Someone linked an older thread where another user, with a drive that was "not a new one", had the same symptom. The fix in that thread wasn't in the cause list. In their words: "I disconnected all connectors from CPU card to base board and connected again-----> the controller(my MM440) is OK now!!"
So the fix existed. It was written down, and it worked. Finding it still took a second person who happened to remember that an older post existed. The thread kept going for years. A 2014 reply suggested isolating the motor to see whether the drive output was healthy. In 2017 someone else posted the same fault, still there with the motor disconnected, and asked for help again.
Most machine builders have this same thread inside their own company. It's just spread across email, PDFs and WhatsApp, where nobody can link to it.
Why doesn't the manual's cause list give you the fix?
The manual is written before the machine ships. It lists every cause the designer could think of, in no particular order of likelihood for your installed base. Field history works the other way. It records what was actually found on real units, in real plants, after a certain number of years.
| Manual / fault-code table | Your past service reports | |
|---|---|---|
| Written | Before shipment | After each visit |
| Covers | Every theoretical cause | The causes actually found |
| Order | Generic | Can be ranked by how often each cause shows up |
| Knows the unit's age and history | No | Yes (serial, firmware, prior visits) |
| Includes odd fixes (reseating a connector, a wrong parameter after a board swap) | Rarely | Often, if someone wrote it down |
| Easy to search | Usually (one PDF) | Usually not |
Both matter. The manual tells you what's possible and keeps you safe. The archive tells you what's likely on this model at this age, and the last row of the table is where the trouble starts.
Where do past service fixes usually end up?
At a mid-size machine or instrument maker, the record of one repair can be split across five places:
| Where it lives | What's there | Why it's hard to find later |
|---|---|---|
| Service report PDF or Word file | The full story: symptoms, readings, parts, fix | File names like SR_2291_final_v2.pdf; text sits in scanned pages or attachments |
| Ticketing or CRM system | A one-line summary and a closed status | "Resolved, replaced board" with no root cause |
| Email threads with the customer or a supplier | The back-and-forth that found the cause | Locked in one person's mailbox |
| WhatsApp or other chat groups | Photos, quick voice-note diagnoses | Not searchable across the team; lost when people change phones |
| Test and inspection reports from the factory | Baseline values the unit shipped with | Filed by production, not service, so nobody looks there |
ABB's 2023 "Value of Reliability" survey, which ABB commissioned and Sapio Research carried out, puts a cost on this. It reports that 88% of Indian industrial businesses surveyed have unplanned outages at least once a month, against 69% globally. The figures are self-reported by respondents. ABB's press release also notes the skills gap as experienced technicians reach retirement age. When that technician leaves, whatever was only in their mailbox and their memory goes with them.
How do you search your archive for a past fix?
If your reports are at least in one place, these steps get you from "I think we saw this before" to the actual report:
- Search the exact fault code, then the variants. Try
F0001,F 0001,F1and the plain-language name ("overcurrent"). Engineers write codes the way the display shows them, and every display is different. - Narrow by model and series before anything else. The same code on a different frame size or firmware can have a different usual cause.
- Add when it trips. At power-up, on the start command, under load, or after a set run time. In the MM440 thread, "fault stays with the motor disconnected" was the clue that pointed away from the motor and cable.
- Search the things people actually write. Part names, test readings ("IR test", "megger"), and phrases like "same issue again" or "came back after".
- Open the full report, not the ticket summary. The root cause and the odd detail ("reseated ribbon cable", "parameter lost after board swap") are usually in the body or the photos.
- Check the unit's own history. Earlier visits to the same serial number often explain the current fault better than visits to other units do.
One research result supports step 1. In a 2026 ICSE study of troubleshooting procedures at Fincantieri, semantic retrieval put the correct procedure in its top four results 41% of the time when questions used the manual's terminology, and 19% of the time when generic synonyms were used. The exact words matter.
How should you write a service report so the next engineer can find it?
Search can only find what's in the report. A few fields make an outsized difference:
- Fault code exactly as displayed, plus the plain-language name.
- Model, serial, firmware and installation date.
- Trip conditions: when, under what load, after what change.
- What was checked and ruled out, with readings. Next time, this saves the first hour.
- Root cause in one sentence, separate from the action taken.
- Parts replaced with part numbers, and photos with captions.
- Whether the fix held, added on the follow-up call.
None of this needs new software. A shared template and the habit of filling in "root cause" separately from "action taken" go a long way.
Can an AI chatbot tell you what fixed this fault last time?
A general chatbot has never seen your service reports, so it can't tell you what your team found on a specific serial number last year. At best it repeats a version of the manual's cause list.
Research on tools grounded in documents is more useful and more cautious. A 2025 PHM Society paper on fault-code recommendation from technical manuals found that retrieval-based methods outperformed LLM-based ones on matching symptoms to fault codes, and suggested retrieval-first approaches as a viable alternative. The ICSE study above found that retrieval-augmented answers were useful but have to come with their sources, so operators can check the recommendation before acting on it.
For a field engineer standing at a machine, the practical rule is simple: an answer you can't trace back to a real report shouldn't be trusted with a live drive.
Where does HangerSearch fit?
We built HangerSearch around that rule. It's service knowledge memory for machine builders: private, retrieval-only search over your team's own service, test and inspection reports. You search by fault code, model or symptom, and every result points to a real report from your own archive. Nothing is generated. If no similar report exists, it says so. It doesn't make one up.
If your team keeps solving the same fault twice, we'd like to show you how it works on your kind of reports.
Book a 20-minute demo: hangersearch.com
FAQ
How do I find out whether a fault has happened before on the same machine?
Search past service reports by serial number first, then by fault code and model. Check factory test and inspection records for that unit too. They show the values it shipped with, which helps you tell a new problem from a slow drift.
Why does the same machine fault keep coming back after a reset?
A reset clears the fault but not the cause. Common reasons are an intermittent connection, a component that's degrading, or a fix that dealt with a symptom. Record the trip conditions each time so a pattern shows up.
What should a service report include so the fix can be found later?
The fault code exactly as displayed, model and serial, trip conditions, checks done with readings, the root cause in one sentence, parts replaced, photos, and whether the fix held on follow-up.
Is the manufacturer's manual enough to fix a repeat fault?
It's the starting point and the safety reference. It lists possible causes, not the ones your team has actually found on your installed base. Use both.
Can AI search over our own reports be trusted for troubleshooting?
Only if every answer links to the source report so an engineer can check it. Published studies on industrial troubleshooting stress returning sources, and some found retrieval-first methods beat generated answers on fault-code matching.
Sources
- Siemens Industry Online Support forum, "F0001 CONTINUOSLY COMES ON MM440 DRIVE" (thread started 18 Mar 2013): https://support.industry.siemens.com/forum/gb/en/posts/f0001-continuosly-comes-on-mm440-drive/89116
- ABB press release, "ABB survey reveals unplanned downtime costs INR 7 million per hour" (11 Oct 2023; survey by Sapio Research, July 2023, self-reported): https://new.abb.com/news/detail/108271/abb-survey-reveals-unplanned-downtime-costs-inr-7-million-per-hour
- Lukens, S., Bishof, M., Siddiqui, N., & West, D. (2025). "An Evaluation Framework for Fault Diagnosis Using Technical Manuals in Retrieval-Augmented Large Language Models." Annual Conference of the PHM Society, 17(1): https://doi.org/10.36001/phmconf.2025.v17i1.4549
- Rossi, M. T., Mariani, L., Riganelli, O., et al. (2026). "'Where is My Troubleshooting Procedure?': Studying the Potential of RAG in Assisting Failure Resolution of Large Cyber-Physical System." ICSE-SEIP '26: https://arxiv.org/html/2601.08706