# The alarm someone already solved three years ago

An unfamiliar alarm, and someone may have fixed it years ago. How to find that report: read the CNC or drive fault history for dates first, search every way the code was written (SV0401, 401, VRDY off), check scanned reports are searchable, ask colleagues the right way, and check the fix applies.

**Short answer:** Start at the machine. Most drives and CNCs keep a fault history with a date or running-hours stamp, which tells you whether this alarm has happened before and roughly when. Then search the old reports for every way the code was written at the time, plus the serial number. Ask colleagues with those details, not just the code.

**Applies to:** service teams and maintenance engineers looking for an earlier report on an alarm they haven't seen themselves. Worked examples use the FANUC Series 30i/31i/32i-B and 0i-D controls, Siemens MICROMASTER 440, Yaskawa A1000 and ABB ACS580 drives. Menus and parameter numbers differ between models, so check your own manual · **Manuals used:** FANUC Series 30i/31i/32i-MODEL B Maintenance Manual B-64485EN/01; FANUC Series 0i-MODEL D Maintenance Manual B-64305EN/03; Siemens MICROMASTER 440 Parameter List 6SE6400-5BB00-0BP0 (Issue 01/06); Yaskawa A1000 Technical Manual SIEP C710616 27C; ABB ACS580 Firmware Manual 3AXD50000016097 Rev J · **Last verified:** 27 Oct 2026

## What does this look like on site?

Amol Nikam described it in a LinkedIn post in September 2026: "A machine stops with an unfamiliar alarm." The engineer knows the machine, "but has never seen this particular problem before." Then comes the usual routine: "Traditionally, he would open the manual, search old service reports, call a colleague…" and ask: “Have you ever seen this alarm?”

His next line is the one this post is about: "And somewhere, perhaps another engineer solved exactly the same problem three years ago."

Łukasz Kincel put the same scene in a plant basement in an October 2026 post: "No signal. A fault he hasn’t seen before. Someone on your team fixed exactly this two years ago, but that fix is buried in a service report nobody can search."

Nikam's summary: "The knowledge exists. The challenge is finding it when you need it."

This page is about that challenge. It's a practical order for finding the old report: what to read off the machine first, how to search for an alarm that was written down differently three years ago, what to do about scanned paperwork, how to ask a colleague a question they can answer, and how to tell whether the old fix applies to today's machine.

If the alarm is a repeat on a machine your team already knows, our guide on [how to find a past service fix for a repeat machine fault](https://hangersearch.com/blog/find-past-service-fix-repeat-machine-fault) covers where fixes usually live and a six-step archive search. This post starts one step earlier, when nobody on site recognises the alarm at all.

## Why is a three-year-old fix so hard to find?

Usually because it isn't filed under the words you're searching for. Three things get in the way.

- **The code was written differently.** Alarm formats change between control generations and between screens on the same drive. More on this below.
- **The report is free text.** Kincel names the hard part as "your repair history: free-text reports, mixed languages, photos without context." One engineer writes the alarm number, another writes "servo not ready", a third writes "machine down, reset OK".
- **The report is a picture of a page.** A scanned job card or a phone photo of a handwritten report holds no searchable text unless someone has run OCR on it.

There's a fourth, simpler one: nobody knows *when* to look. "Sometime before I joined" covers a lot of folders. The machine itself can often narrow that down.

## Step 1: What does the machine remember about this alarm?

Before you search any archive, read the fault history on the control or the drive. It can tell you whether this alarm has happened on this machine before, and give you a date or running-hours figure to match against old service visits. Don't clear it first.

| Equipment | Where the history is | What it records | Ways it gets lost |
|---|---|---|---|
| FANUC 30i/31i/32i-B | Alarm history screen: function key, continuous menu key, soft key [HISTORY] | Alarms most recent first, each with date and time, alarm type and number, and message | Memory clear deletes it. [(OPRT)] → [(CLEAR)] deletes all history. Shares storage with other history and deletes oldest first when full, unless parameter 11354#2 (SAH) = 1, which keeps the last 50 alarms in their own area |
| FANUC 30i/31i/32i-B | Maintenance information screen: soft key [M-INFO] | Free-text notes, which FANUC says the screen is for: recording the history of maintenance performed by a FANUC or machine tool builder service person. Stored in Flash ROM | Only as good as whoever typed into it |
| Siemens MICROMASTER 440 | r0947 (last fault codes), r0948 (fault time), r0949 (fault value) | The active trip and up to three earlier trips, two codes each, with a time stamp per trip | Clearing the fault memory with P0952 = 0 also resets the fault times |
| Yaskawa A1000 | Monitors U3-01 to U3-10, and U3-11 to U3-20 | The ten most recent faults, and the cumulative operation time (hours) at each | After ten faults the oldest is deleted. Initializing the drive doesn't reset them, but o4-11 = 1 erases them |
| ABB ACS580 | Menu → Diagnostics → Fault & event log, or the Drive composer PC tool | The last 32 fault recordings and the last 32 warnings and events, each time-stamped. Each stored fault shows its code, time and nine parameter values | Can be reset from Drive composer. New faults push out old ones |

*Our summary of the manuals listed in the sources. Menus and capacities vary by model and software version.*

Three practical notes:

- **Check the clock before you trust the date.** FANUC says the correct date and time need to be set for the history to be right. ABB's ACS580 raises warning A6A7, "System time not set", and says that while it's active, fault log dates are not correct. The MM440 stamps r0948 from its runtime counter (r2114) unless the AOP's real-time clock (P2115) has been synchronised, so on most units you'll get a running-time figure, not a calendar date. A running-hours figure is still useful: compare it with the hours recorded on old service reports, if your reports record them.
- **Look at the M-INFO screen on FANUC machines.** It's easy to forget it exists. If an earlier service engineer used it, the note may name the alarm, the date and what was changed, on the machine itself.
- **Write the history into today's report before anyone clears it.** Our [MM440 F0001 post](https://hangersearch.com/blog/siemens-mm440-f0001-fault-wont-reset) walks through reading r0947 to r0949 and why clearing P0952 makes the next diagnosis harder.

If the history shows this alarm has never happened on this machine, the old report you want (if it exists) is on a different machine of the same model. That changes how you search, so note it.

![Ink line drawing of an industrial control cabinet with its door open, showing a wall-mounted variable frequency drive, a contactor, DIN-rail terminal blocks and cable ducts, with the drive's detachable operator keypad hanging in front of the cabinet on a coiled cable, the keypad shaded pale blue](/blog/media/alarm-already-solved-three-years-ago-mvq797m5.png)

## Step 2: How was this alarm written three years ago?

Build a list of search terms before you search. The same fault can sit in the archive under several spellings.

**FANUC servo ready alarm.** On a 0i-D or 30i-B control the alarm is SV0401, "IMPROPER V_READY OFF". In a Practical Machinist thread from February 2026, the owner of a Vectrax knee mill with a much older FANUC 0-MC control listed his startup alarms as "400 Servo Drive Overload 401 VRDY off 414 X Axis not ready 424 Y Axis not ready 434 Z Axis not ready". Same family of alarm, written "401" and "VRDY off". A search for "SV0401" won't find that page, and it won't find a report from the same kind of machine in your own archive either. (The thread's ending is below.)

**Drive fault numbers.** The MM440's r0947 shows fault codes as plain numbers. Siemens' own example is "r0947[0] = 3 Undervoltage (F0003)". A technician who copied the number off the parameter rather than the display may have written "fault 3" or "F3".

A search list for one alarm might look like this:

| Search for | Example (SV0401) | Example (MM440 F0001) |
|---|---|---|
| Current code format | SV0401 | F0001 |
| Older or shortened formats | 401, SV401 | F1, fault 1, "1" in r0947 |
| Alarm message text | IMPROPER V_READY OFF, VRDY off | Overcurrent |
| What a technician might write instead | servo not ready, all axes not ready, MCC not on | OC trip, trips on start |
| Machine identity | Serial number, model, control type | Serial number, drive model and power rating |
| Other languages your team uses | However the alarm is described in your service team's languages | Same |

*Our example list. The code formats and messages come from the manuals and thread cited in the sources; the "might write instead" phrases are illustrations, not quotes.*

Then search in this order:

1. **This serial number, any alarm, around the date from Step 1.** If the history shows the alarm on a known date or at known running hours, the report from that visit is the best match there is.
2. **This serial number, every code variant.** Earlier visits may have seen the alarm and not left it in the history (it was cleared, overwritten or the clock was wrong).
3. **The same model and control, every code variant.** This is where Nikam's "another engineer" usually turns up: on a sister machine at another site.
4. **The message text and symptom words, with no code at all.** This catches the reports that say "servo not ready" and nothing else.

## Step 3: What if the old reports are scans or photos?

Then a text search won't see them, whatever you type. Two things to check.

**Is OCR switched on, and when was it switched on?** If your reports live in SharePoint, Microsoft's OCR service can extract printed or handwritten text from images and documents, including scanned PDFs, and index it for search. It's a pay-as-you-go service someone has to set up. The detail that matters for old archives: Microsoft says images uploaded after OCR has been enabled are the only images that are scanned. A folder of job cards scanned in 2023 and uploaded before OCR was turned on is still just pictures to search. Ask whoever runs your SharePoint whether OCR is on and from what date. Also, for PDFs and TIFFs the extracted text goes into the search index, not into a metadata column you can see, so test it by searching for a word you know is on a scanned page.

**For a handful of files, run OCR yourself.** Adobe Acrobat applies OCR automatically when you choose Edit on a scanned PDF. Adobe's own tip is to check the OCR accuracy and use Scan & OCR → Recognize Text to improve results. Handwritten alarm codes are exactly the kind of thing OCR misreads, so search for the variants in Step 2 and read the page yourself.

**Photos without context** are Kincel's third hard part. A phone photo of a parts label or a burnt board, sent in a chat with no message, can't be found by any search. If you find one in an old thread, the useful context is usually in the messages around it, so read the conversation, not just the image.

![Ink line drawing of a service workbench with no one at it, showing a stack of blank job cards, an open ring binder of blank report sheets, a flatbed scanner with its lid raised, a closed laptop, a replacement power supply module in an open parts box and a desk lamp, the open binder page shaded pale blue](/blog/media/alarm-already-solved-three-years-ago-mvq79bb7.png)

## Step 4: How do you ask "Have you ever seen this alarm?" so someone can answer?

The bare question works if the colleague happens to remember. It works far more often with enough detail to jog a memory or to search with. Send this:

- The alarm exactly as the screen shows it, plus the other alarms that came with it
- Machine model, serial number and control or drive type
- What the fault history says: first occurrence, how often, dates or running hours (Step 1)
- When it trips: at power-up, on start, under load, at random
- What you've already checked and what you measured
- A photo of the alarm screen, with a line saying what it is

That last point matters for the next person too. A photo with "SV0401 on all axes at power-up, Line 3 mill, serial …" is findable later. A photo with no message isn't.

## Step 5: You found an old report. Does the fix apply here?

An old fix is a lead, not a diagnosis. Before you order the part, check:

- **Same machine, same model, or just the same alarm?** The same alarm number can have several causes. Our [SV0401 post](https://hangersearch.com/blog/fanuc-sv0401-alarm-all-axes) shows how one alarm on every axis points somewhere different from the same alarm on one axis.
- **Same control generation and software?** A fix on an older control may involve different hardware from yours.
- **Did the fix hold?** Look for a later report on the same serial number with the same alarm. If there's one a month later, the first "fix" wasn't the cause.
- **Was the cause confirmed, or did it just start running?** "Reset, ran OK" is not a fix. Our checklist on [what to write before you close a breakdown job](https://hangersearch.com/blog/its-running-now-is-not-a-fix) explains why.
- **What was ruled out, with readings?** Measurements you can repeat are worth more than the conclusion.

The 0-MC thread is a good example of reading an old fix carefully. Its poster measured the 24 V circuits at the power supply module, roughly 14–20 V at CX4 and 16–22 V at CX2B. He had also tried to get documents: "I don't have a wiring diagram. I've contacted MSC and they're trying to find it, but it's probably a long shot." Nearly three weeks later he came back with the answer: "Probably no one's still looking at this, but I got it figured. It was a cooked PSM", and he replaced the power supply module. That's a fix confirmed by the person who did it, with the readings that led to it. It's also a single report, on an older control than most machines in service now, so it tells you where to measure, not what to replace. Notice where the answer sits too: in the last post of the thread, under "401", weeks after the question. That's what a three-year-old fix looks like from the outside.

## How do you make sure the next engineer finds yours?

You're writing tomorrow's old report today. A few habits make it findable in three years:

- Write the alarm exactly as displayed, and add the message text.
- Record the serial number, the control or drive model and the software version if you can see it.
- Copy the fault history entries (code, date or running hours) into the report.
- Say what the cause was, how you confirmed it, and what you ruled out with readings.
- If photos are attached, say in words what each one shows.
- If the machine has a FANUC M-INFO screen, a one-line note there stays with the machine.

The full close-out checklist is in ["It's running now" is not a fix](https://hangersearch.com/blog/its-running-now-is-not-a-fix).

## Where does HangerSearch fit?

Nikam pictured AI helping in a specific way: "Not to tell the engineer blindly what to do." Instead: “Here are three similar cases. Here’s what caused them. Here’s where you should start looking.” He was also clear that "AI cannot replace the sound judgement, intuition and hands-on experience of a good service engineer."

That's close to how we built HangerSearch. It's private, retrieval-only search over your team's own finalized service, test and inspection reports. You search by fault code, model or symptom. It shows the few prior cases that match and why each matched, and opens the cited page. Nothing is generated, and if there's no similar report, it says so. The engineer still decides what applies. See [how we handle your reports](https://hangersearch.com/trust).

Book a 20-minute demo: hangersearch.com

## FAQ

### How do I find old service reports for an alarm?
Start with the machine's own fault history to see whether the alarm has happened before and when. Then search your reports by serial number around that date, then by every format of the code (for example SV0401, 401, "VRDY off"), then by the same model, then by the message text and symptom words. Check whether scanned reports are actually searchable.

### Where does a CNC or drive store its alarm history?
On a FANUC 30i-B, the alarm history screen under the [HISTORY] soft key lists alarms with date and time. A Siemens MM440 keeps recent fault codes in r0947 and their times in r0948. A Yaskawa A1000 keeps the last ten faults in U3-01 to U3-10, with operation hours in U3-11 to U3-20. An ABB ACS580 keeps a time-stamped log of the last 32 faults.

### Why does the alarm history show the wrong date?
Usually because the clock was never set. FANUC says the correct date and time must be set for history. ABB's ACS580 warns "System time not set" (A6A7) and says fault log dates aren't correct until it's fixed. A Siemens MM440 uses its runtime counter for fault times unless the AOP real-time clock has been synchronised.

### Why can't I find scanned service reports in SharePoint search?
Scanned pages are images, so they need OCR before their text is searchable. Microsoft's SharePoint OCR service only scans images uploaded after it was enabled, so older uploads aren't covered. For a few files, Acrobat can run OCR on a scanned PDF.

### Should I just apply the fix from the old report?
Not straight away. Check it's the same model and control generation, that the cause was confirmed rather than "ran OK after reset", and that there's no later report showing the same alarm came back. Treat it as where to start looking.

## Sources

1. Amol Nikam, LinkedIn post "The Service Engineer’s Toolbox Is Changing — And AI May Be the Next Essential Tool", 9 Sep 2026: https://www.linkedin.com/posts/amol-nikam-79539546_artificialintelligence-serviceengineering-activity-7503489119331901440-uI5p. Read 27 Oct 2026. Supports: all Nikam quotes.
2. Łukasz Kincel, LinkedIn post, 9 Oct 2026: https://www.linkedin.com/posts/lukasz-kincel_your-technician-is-in-a-plant-basement-no-activity-7514242153645203456-ubdP. Read 27 Oct 2026. Supports: the plant-basement quote and "free-text reports, mixed languages, photos without context".
3. FANUC, Series 30i/31i/32i-MODEL B Maintenance Manual, B-64485EN/01. Supports: the maintenance information screen [M-INFO], its purpose and Flash ROM storage (section 1.10, p. 131); the history function, oldest-first deletion, memory clear, correct date and time, [ALL CLEAR] with parameter 3195#7 (section 1.10.6, p. 135); the alarm history screen, its contents and procedure (section 1.10.6.1, p. 136); deleting history with [(CLEAR)] and parameter 11354#2 SAH holding 50 alarms (p. 137). Printed page numbers. Paraphrased.
4. FANUC, Series 0i-MODEL D Maintenance Manual, B-64305EN/03. Supports: SV0401 "IMPROPER V_READY OFF" (Appendix A, p. 462). Paraphrased.
5. Siemens, MICROMASTER 440 Parameter List, 6SE6400-5BB00-0BP0, Issue 01/06. Supports: r0947 fault codes and the "r0947[0] = 3 Undervoltage (F0003)" example (p. 106); r0948 time stamp from r2114 or the AOP real-time clock P2115 (p. 107); P0952 clearing fault times (p. 108). Printed page numbers.
6. Yaskawa, A1000 Technical Manual, SIEP C710616 27C. Supports: U3-01 to U3-10 most recent faults, oldest deleted after ten, U3-11 to U3-20 cumulative operation time at each fault (p. 450); o4-11 and fault history not being reset by drive initialization (p. 289). Paraphrased.
7. ABB, ACS580 Standard Control Program Firmware Manual, 3AXD50000016097 Rev J. Supports: two time-stamped event logs of 32 faults and 32 warnings/events (p. 538); fault code, time and nine parameter values per stored fault, 05.80–05.88, Fault & event log menu and Drive composer (p. 539); A6A7 "System time not set" (p. 546). Paraphrased.
8. Practical Machinist, "Alarm 400, 401, 4n4 on fanuc 0-MC OM controller (maybe an MCC issue)", started by pasper20, 10 Feb 2026, resolved by the poster 1 Mar 2026: https://www.practicalmachinist.com/forum/threads/alarm-400-401-4n4-on-fanuc-0-mc-om-controller-maybe-an-mcc-issue.446392/. Read 27 Oct 2026. Supports: the alarm list, the 24 V readings, the wiring-diagram quote and the resolution quote.
9. Microsoft Learn, "Overview of optical character recognition in SharePoint": https://learn.microsoft.com/en-us/microsoft-365/syntex/ocr-overview. Read 27 Oct 2026. Supports: printed and handwritten text extraction, scanned and hybrid PDFs, pay-as-you-go billing, PDF/TIFF text indexed in search but not in the metadata column, only images uploaded after OCR is enabled being scanned. Paraphrased.
10. Adobe, Acrobat Help, "Edit scanned documents": https://helpx.adobe.com/acrobat/using/edit-scanned-pdfs.html. Read 27 Oct 2026. Supports: automatic OCR when editing a scanned PDF, and the Scan & OCR → Recognize Text tip. Paraphrased.