FANUC Robot Alarm Codes: Read the Chain, Fix the Right Part
A FANUC alarm line has four parts: the family, the number, the text, and a group/axis reference such as G:1 A:2. The family tells you which subsystem raised the fault, not which part failed. The severity tells you whether the line stops, and the history tells you what happened before it did.
If you know what the robot is doing but not which code to look at, start from the symptom.
- Servo will not power on: SRVO-021, SRVO-058, SRVO-001 / 002 / 007
- Robot will not jog: SRVO-062, SRVO-038, SRVO-406 to 410
- Robot jogs but will not run a program: MOTN-049, MOTN-017
- Same alarm returns after a repair: the SRVO-065 to SRVO-062 chain
- Controller will not boot: SYST-035 and the mainboard 7-segment display
- Everything looks normal but the robot still will not move: SRVO-230 / 231, SRVO-408
The sections follow the order that resolves most alarms fastest: what the code means, whether the line stops, reading the history, the first ten minutes, the SRVO reference, battery and mastering, DCS safety codes, and what to send us.
If the alarm came back after a part was already replaced, send the alarm text, the controller model and a list of what has been changed. We read it with you remotely.
1. What the code is telling you
A FANUC alarm line carries four pieces of information. The family name, such as SRVO, SYST, MOTN, INTP or HOST, identifies the subsystem that raised the fault. The number selects the specific fault inside that family. The short text is the official name, for example BZAL or FSSB init error. The group and axis reference, written G:1 A:2, tells you which motion group and which axis the controller was talking about. On a single robot G is almost always 1, but a cell with a positioner or a second robot will produce other values.
The distinction that matters on the floor is simpler than any code list: the family names a subsystem, not a part. SRVO covers amplifiers, motors, encoders, brakes, the FSSB fibre link and the DCS safety signals. A code beginning with SRVO is not evidence that the amplifier has failed. It is evidence that something on that chain is not in the state the controller expects.
The chain here is not a cable. It is the four things a move depends on: the position data the controller needs before it can move at all, the safety signals that permit the move, the communication between controller and amplifier, and the mechanical load that resists it. Every code in this article sits on one of those four, and naming the one it sits on is what turns a code into a next step.
A case posted on a public robot forum in December 2022 shows how far that distinction can go. An R-30iB Mate Plus controller running an LR Mate 200iD had raised SRVO-062 BZAL. The four encoder batteries had already been replaced once and the robot re-mastered, and it ran normally afterwards. Then the same alarm returned and the robot would not jog at all. All four cells measured 1.5 V and the polarity was correct. The cause sat in the battery housing: the springs in the base and in the cover had been pressed flat, so the cells were no longer making contact. Lifting them with a screwdriver cleared the alarm.
The battery was good, the circuit around it was open, and the alarm was telling the truth. What failed was the reading of the alarm. That is the habit this guide to FANUC robot alarm codes is built around: read the chain, not the noun.
2. Does the line stop: reading the severity
Every entry in the FANUC robot alarm code list also carries a severity, and the controller displays the code in a colour assigned to that level. Most online lists reprint the number and the text and skip this, which is unfortunate, because severity answers the first question a shift supervisor asks.
| Severity | Display colour | What it means at the cell | Can you reset and run |
|---|---|---|---|
| WARN | White | Advisory. Motion continues, or the robot can still be jogged. | Yes, and schedule the fix for the next window |
| PAUSE | Yellow | Program paused and motion stopped. Servo power may stay on. | Yes, once the cause is gone |
| STOP | Yellow | Motion and program stopped by a stop request. | Yes, after the cause is cleared |
| SERVO | Red | Servo power removed. The robot cannot be jogged. | Only after the cause is cleared |
| SERVO2 | Red | Servo-level fault with a wider scope, usually a group rather than one axis. | Same as SERVO |
| ABORT | Red | The running program was aborted, not merely paused. | Yes, but the program restarts from a safe point |
| SYSTEM | Red | Controller-level fault: memory, configuration, boot sequence. | Often needs a power cycle or a restore |
| RESET | Blue | Not a fault. Marks a reset event in the history. | Not applicable |
Two entries in that table are widely misread. PAUSE.G and SERVO2 are severity levels with a scope qualifier, not separate alarm families, so they do not need their own troubleshooting path. And when DCS, STBERR or CRCERR appear inside an alarm message, they are fragments of message text, not severities.
Severity measures urgency, not cost. SRVO-065 is a WARN, and it is also the alarm that costs a full re-mastering if it is ignored until the encoder data is gone. A white line deserves attention on the same day even when the robot keeps running.
3. Read the history first
How the screen is ordered
Press MENU, then 4 ALARM, then F3 [HIST]. The newest entry is assigned number 1, so the oldest entry sits at the bottom of the list, and that is usually where the cause is. The screen displays up to 100 lines, a figure that appears in the R-30iB, R-30iB Mini Plus and R-30iB Mate maintenance manuals alike, and F5 opens the detail view with the cause code. Photograph or export the list before you reset anything, because the history is the only record of what the controller saw before you intervened.
One setting deserves a mention. The system variable $ER_NOHIS controls what gets recorded: set to 1, WARN and NONE entries are not written to history; set to 2, reset events are skipped; set to 3, all three are skipped. If a colleague insists a warning appeared and you cannot find it, check that variable before doubting them.
What a real sequence looked like
In January 2021 an engineer published a service record from a cell that had been standing idle for about two weeks. On power-up the controller showed two alarms at once: SRVO-223 DSP dry run (9,1) and SRVO-058 FSSB init error (2). Reset did nothing, and a full power cycle changed nothing either. Amplifier connections, amplifier supply, amplifier fuses, the fibre and the amplifier itself were checked and found normal. FANUC support asked him to unplug the CRF8 connector on the servo amplifier and power up again. The alarm changed to SRVO-068 DTERR, which means the controller is requesting data from the serial pulsecoder and receiving none. That narrowed the fault to the RP1 cable, and the cable on the mechanical unit turned out to be damaged. With the cable replaced, the controller came up showing SRVO-062, because two weeks without power had drained the encoder batteries.
Three things in that sequence matter more than the code definitions. An alarm that will not clear does not prove that the part named in the alarm has failed. Changing one connection changed the alarm, and that change is what localised the fault. Repairing the first fault exposed the second one, which had been waiting behind it.
4. The first ten minutes
Five steps cover almost every alarm, regardless of prefix.
- Make the area safe. Confirm the robot is stopped, isolate anything that can fall, and put a lock or a tag on the controller before anyone opens a cabinet.
- Write the line down exactly, including G and A, and note the time it appeared.
- Open the history and read to the bottom of the list, not the top.
- Classify the alarm into one of four groups: position data, safety signal, communication, or mechanical load. The group decides who looks at it and which document they open.
- Change one thing, then observe. A second change before the first result erases the information you just paid for.
Three actions turn a repairable fault into an expensive one. Do not swap two amplifiers in a row to see whether the code moves, because you will lose track of which one was original. Do not widen $PARAM_GROUP limits to silence a limit alarm, because the mechanical limit did not move. Do not initialise the controller before you hold a recent image backup, because initialisation is not reversible.
None of these five steps requires a complete list of FANUC robot alarm codes on the wall. They require the history, the group and axis reference, and one controlled change at a time.
5. SRVO quick reference
The codes you will meet most
SRVO is the largest family in the FANUC robot alarm code list, and the least uniform. It covers the emergency stop chain, the amplifier, the encoder, the fibre link, the mechanical load and the DCS safety signals, which is why one prefix can lead to six different investigations.
| Code | Official meaning | First check | More detail |
|---|---|---|---|
| SRVO-001 / 002 / 007 | Operator panel E-stop, pendant E-stop, external E-stop | Which of the three chains is open, then the panel and fence wiring | |
| SRVO-021 | SRDY off: the amplifier ready signal dropped | Read the history first; the manual's own first action is to look for a simultaneous alarm | |
| SRVO-038 | Pulse count mismatch between power-off and power-on | Encoder cable, then battery, then mastering | Section 6 |
| SRVO-044 | DC link voltage too high | Incoming supply and regeneration | |
| SRVO-045 | High current in the amplifier main circuit | Motor cable insulation, then the amplifier | |
| SRVO-046 | OVC: RMS current above the allowed value | Load, brake release, supply voltage, then the motor | |
| SRVO-050 | CLALM: disturbance torque far above the motion model | Collision, payload, stuck brake, program | SRVO-050 guide |
| SRVO-058 | FSSB init error: an axis did not answer at power-up | PSU fuse, fibre, 24 V, amplifier LEDs | SRVO-058 guide |
| SRVO-062 | BZAL: encoder backup battery not connected or exhausted | Battery, holder contacts, internal battery cable | Section 6 |
| SRVO-065 | BLAL: encoder battery voltage below the reference | Replace the battery with the controller powered | Section 6 |
| SRVO-075 | Pulsecoder position not established | Jog the axis until the alarm clears, then confirm mastering | Section 6 |
| SRVO-214 | Fuse FS2 or FS3 blown in the 6-axis amplifier | Find the cause before fitting a fuse | |
| SRVO-406 to 410 | DCS safety output signals switched off | Safe I/O Connect mapping and the safety PLC | Section 8 |
Prove the part before you replace it
Three of those codes have a dedicated article, because the isolation procedure is longer than a table row can hold. SRVO-050 is a load and motion problem. SRVO-058 is a communication problem at boot, and its official action list runs from the power supply fuse through the fibre to the axis control card. SRVO-408 is a safety configuration problem that has nothing to do with the servo amplifier.
One habit is worth more than any single code: prove the part is bad before you replace it. Swap the suspect fibre with a known good one, measure the supply at the amplifier, read the LEDs. A swap test takes ten minutes and produces evidence. A replacement produces a bill and, if you guessed wrong, the same alarm on the next shift.
Where the rest of the codes live
The table above is SRVO only. When the line on your pendant starts with something else, this is what that prefix covers, using the facility names and descriptions printed in the official code list:
- SYST (System): the controller itself, not the arm. Covered in section 7.
- MOTN (Motion): the motion instruction layer. Covered in section 9.
- INTP and PROG (Interpreter): the teach pendant program is being read or executed. A power failure in the middle of a cycle leaves INTP-127 behind.
- PRIO (Digital I/O): an I/O assignment or precedence problem, not a servo problem.
- HOST (Host communications): the link to a PLC, cell controller or host computer.
- FILE (File system): loading, saving and restoring files, including memory card and FTP transfers.
- MEMO (Memory): memory allocation and program storage.
Prefixes outside this list still tell you the subsystem. SPOT, ARC and PALT are application packages, so a fault there comes from the application rather than from the robot hardware.
6. Battery and mastering
Two batteries, two procedures
There are two batteries in a FANUC system, they protect different data, and the procedures are not interchangeable. Mixing them up is the most common way a two-minute job becomes a two-day job.
| Item | Mainboard battery | Encoder backup battery |
|---|---|---|
| Location | Inside the controller, on the mainboard | On the mechanical unit, usually at the base |
| What it protects | SRAM contents: programs, parameters, system variables | Pulse counts that let the controller know the axis position |
| Alarm when low | SYST-035 | SRVO-065, then SRVO-062 when the data is gone |
| Power state during replacement | Power on, wait 30 seconds, power off, then swap | Keep the controller powered while the data is still valid |
| If the data is already lost | Not applicable | Power state no longer matters |
The encoder battery is specified per mechanical unit. The two sizes are A98L-0031-0005 (size 1) and A98L-0031-0027 (size 2), and each box holds four cells. Confirm the size against the battery you remove or against the maintenance manual for that robot model, because the wrong size fits the holder badly and fails early.
From a low battery to a stopped robot
The chain has five links, and each one has its own message. SRVO-065 appears while the voltage is still above the threshold that keeps the data alive. SRVO-062 appears when the data is gone and the robot stops completely. A pulse reset follows, either through $MCR.$SPC_RESET or through F3 [RES_PCA] on the mastering screen, and the controller needs a power cycle afterwards. SRVO-075 then appears because the pulse count has not been re-established, and the axis is jogged until that alarm clears. SRVO-038 can appear if the count at power-up does not match the stored value, and mastering closes the sequence.
Four things that get missed
The first is that a new battery does not restore a pulse count that was already lost. The battery preserves the count while the power is off; it does not recreate it.
The second is that the battery protects pulse counts, not the whole position. The precise position the controller reports is the encoder reading combined with the revolution count, and only the count depends on the battery.
The third is that a healthy cell voltage does not prove the voltage reaches the encoder. The case earlier in this article is the clearest example: four cells at 1.5 V, correct polarity, and an open circuit at the spring contacts. Corroded terminals, a cover that is not seated, oil inside the holder and a broken internal battery cable all produce the same alarm as a flat battery. FANUC's own note on SRVO-062 says that if the alarm continues after a new battery is fitted, the internal battery cable may be broken.
The fourth concerns which mastering method to use. Quick mastering relies on the factory zero data recorded at build time, and that data becomes invalid if a motor or encoder has been replaced. Within those limits it can correct a deviation of no more than half a motor revolution, and FANUC's Shanghai documentation states that the restored accuracy can reach the factory value. Full mastering aligns every axis to the witness marks by eye, so its accuracy depends on how well the marks line up and is normally below factory accuracy. For a handling cell that is usually acceptable. For a process where the taught path matters, quick mastering is the better choice whenever its conditions are met.
One thing worth keeping
The factory zero data is normally shipped with the robot, often in the same crate as the teach pendant. Keep it. Without it, the quick method is not available and every future recovery costs a full mastering.
If you are standing in front of an SRVO-062 right now, send us the robot model, the serial number and the battery part number you removed. We confirm the correct battery for that mechanical unit and the reset sequence that follows it, so the replacement happens once.
7. SYST codes are about the controller
SYST alarms come from the controller itself: memory, configuration, boot state and system-level checks. They rarely mean that an axis has failed, and treating them like servo faults sends people to the wrong cabinet.
SYST-035 is the mainboard battery. The correct order is to take a backup, replace the battery with the controller powered off after a 30 second wait, then restore. Replacing the battery first and looking for a backup afterwards is the wrong order, because the SRAM content is what the battery was protecting.
If the seven-segment display on the mainboard shows "1", the SRAM content is already gone and the system cannot boot. A new battery will not fix that state. The controller needs an image restore, and without a backup the recovery is a configuration rebuild.
SYST-308 is a special case that catches people during recovery. Clearing a DCS-related alarm requires T1 mode and SHIFT plus RESET, not a plain reset. An operator pressing RESET in AUTO will conclude that the alarm is stuck when it is simply being cleared from the wrong mode.
8. DCS safety codes: SRVO-406 to 410
How the five signals map
These five codes look like servo faults because of the prefix, and they are not. They report the state of the DCS safety outputs, and each one maps to a single signal. SSO[1] is C_SVOFF and produces SRVO-406. SSO[2] is C_FENCE and produces SRVO-407. SSO[3] is C_EXEMG and produces SRVO-408. SSO[4] is C_SVDISC and produces SRVO-409. SSO[5] is C_NTED and produces SRVO-410.
The two that stop cells most often, 408 and 409, have a step-by-step isolation sequence in How to solve FANUC alarm SRVO-408. The section below explains why they appear, and why they rarely mean a failed servo component.
Why a sudden 408 is usually a configuration change
The behaviour that explains most of these calls is in the DCS manual, B-83184EN/12 section 5, and easy to miss: the initial value of each signal is ON, and the alarm does not occur when the signal is not used in Safe I/O Connect. A robot that has run for years without a DCS alarm and suddenly raises 408 has therefore not developed a servo fault. Either the mapping was changed, or the wiring was changed, or the safety PLC stopped delivering the signal.
A public forum thread from 2019 shows the same mechanism from the simulation side. A backup taken from a working cell and opened in ROBOGUIDE produced SRVO-406, 407, 408 and 409 together, because the virtual controller had no safety PLC feeding the mapped inputs. Removing the Safe I/O Connect entries cleared all four, which confirms that the codes follow the mapping rather than the hardware.
Two hardware facts complete the picture. SRVO-230 and SRVO-231 report a mismatch between the two safety channels: the manual defines them as a condition where a contact on chain 1 is closed while the corresponding contact on chain 2 is open. That is what happens when someone shorts a dual-channel circuit into a single channel to get a cell running, and it is why that shortcut is not acceptable. Separately, the R-30iB and R-30iB Mate controllers do not have a servo disconnect function, so SRVO-409 has no hardware premise on those cabinets.
9. MOTN codes: nothing is broken
MOTN-017: the controller refuses the path
MOTN alarms come from the motion instruction layer. The mechanics are intact and the controller is refusing to execute, which is a different kind of problem from a servo fault. MOTN-017 is a software limit violation: the controller computes that the commanded path would take an axis past its configured limit, and it stops before the move starts.
Common causes are a position taught at the edge of the envelope, a user frame that was edited or restored from another cell, a configuration flip between two adjacent points, and on SCARA models a world-coordinate jog that has no valid kinematic solution at the current pose. The quick diagnostic is the jog mode: if joint mode moves and world mode raises the alarm, the problem is in the frame or the configuration, not in the hardware.
MOTN-049: mastered is not calibrated
MOTN-049 is a calibration state, not a mechanical fault. Mastering establishes the reference relationship between the encoder and the axis. Calibration then makes that reference usable for motion. A robot can be mastered and still refuse to move because calibration was never completed, and no amount of battery replacement will change that state.
The dividing line between these two families is worth remembering. If the robot jogs but will not run a program, look at calibration and the program. If it will not jog at all, look at the hardware and the safety chain.
10. When the cause is outside the robot
Three overload alarms are often treated as one, and they are not. OVC is calculated inside the servo unit from the RMS current, and it reacts within a short time window. OHAL comes from a thermostat inside the motor and responds over a longer period. HC is raised by the amplifier when the main circuit carries an abnormally large current, which protects the transistors and prevents the motor magnets from being demagnetised. All three can appear on the same axis, and all three usually point at the load rather than at the amplifier.
The mechanical suspects are short and boring: a brake that does not release, a reducer that has lost its lubricant, a guard or cable that interferes partway through the stroke, and a payload that was changed without updating the model.
The electrical suspects are equally boring and equally common: incoming voltage outside the rated range, a damaged encoder cable in the dress pack, and a ground fault in the motor cable.
The rule that saves the most money is the same one stated earlier. Prove the part is bad before you replace it. Insulation test the motor cable, swap the fibre, read the amplifier LEDs, compare the commanded current against a sister axis. Evidence is faster than guessing and considerably cheaper.
11. Who should act on the code
The same alarm means different work depending on where you sit.
On a production line, the priority is the next good part. Severity decides whether the cell stops: WARN can run to the next planned window, SERVO and SYSTEM cannot. Spares should follow failure rate and supply risk, not a general list of parts that might fail.
During commissioning, most alarms are not hardware at all. A new cell raises limit, configuration and safety mapping faults because the frames, the payload and the DCS configuration are still being set up. The first suspect should be the last thing that was changed.
On a repair bench, the useful map runs from code to board and component. This article stops at the subsystem on purpose, because board-level isolation needs a different set of documents and measurements.
For a trader or a reseller, the risk is quoting the wrong part. A code tells you which subsystem is involved, not which part number to ship, and a wrong number costs more in returns than a slow reply costs in lost margin.
12. What to send us
Six items let a remote engineer reconstruct the fault without travelling.
- Robot model and serial number.
- Controller model and software version.
- The complete alarm text, including the group and axis reference.
- A photograph or export of the alarm history, not just the current line.
- What was changed or repaired before the alarm appeared.
- What the robot does now: jogs in joint mode, jogs in world mode, or does not move at all.
The serial number alone is enough to start. The rest shortens the conversation, and item 6 often answers the question before anyone opens a manual.
What we supply. FANUC spare parts for the components these alarms point at: encoder battery units in both sizes, servo amplifiers, FSSB fibre cables, encoder and motor cables, and axis control cards. We also take the same units in for board-level repair, where most repairs carry 12 months and discontinued series are confirmed per unit. Send the robot model and serial number and we confirm the part against that mechanical unit before we quote it. Parts carry 12 months warranty, with extended cover on request.
If you have an alarm you cannot place, send the serial number and the alarm text. We confirm what the code covers, what it does not cover, and which part, if any, is actually involved. If the root cause is something your own team can fix, we will say so.
Send the serial number and the alarm text with the button below. What comes back is the subsystem the code covers, whether a part is actually involved, and a quote if one is needed. If nothing is down yet and you are planning spares, send the model list instead, and we will tell you which of these parts come up first on that model.
FAQ
What does G:1 A:3 mean in a FANUC alarm?
G is the motion group and A is the axis inside that group. G:1 A:3 means group 1, axis 3. On a single robot the group is almost always 1, so the value to act on is the axis. On a cell with a positioner or a second robot, the group tells you which machine the controller was addressing.
Can I reset a FANUC alarm and keep running?
It depends on the severity. WARN, PAUSE and STOP alarms can usually be reset once the cause is gone, and production can continue. SERVO and SYSTEM alarms should not be reset repeatedly to keep a line moving, because the underlying condition is still present and the next stop will be harder to diagnose.
Why does the same alarm come back after I replace the part?
Because the part was not the cause, or because a second fault sits behind it. Two patterns are common: a circuit problem around a healthy component, such as the spring contacts in the battery housing, and a fault that only appears after the first one is repaired, such as encoder batteries drained during a long shutdown.
What is the difference between SRVO-062 and SRVO-065?
SRVO-065 is a warning that the encoder battery voltage has fallen below the reference value, and the data is still intact. SRVO-062 means the backup is no longer maintaining the absolute position, so the robot stops and the axis will need a pulse reset and mastering. 065 is the alarm you want to act on.
Do I need to re-master after changing the encoder battery?
If the alarm stayed at SRVO-065 and the controller was powered during the swap, usually not. If SRVO-062 appeared, the pulse count is gone and the axis needs a pulse reset followed by mastering. Quick mastering is available when the factory zero data is still valid and the deviation is within half a motor revolution.
What information do I need to send for a quote?
The robot serial number is enough to start. Adding the controller model, the software version and a photo of the alarm lets us confirm the exact part and return a quote, normally within 24 hours.
Can I ask a technical question without buying a part?
Yes. A large share of the questions we receive are about reading a code, with no purchase attached. If the root cause is something your team can fix, we will tell you that directly.
References
Technical references
- FANUC, Robot Series alarm code list, publication B-83284EN-1/04 and B-83284CM-1/04.
- FANUC, Dual Check Safety function manual, publication B-83184EN/12, section 5 and section 24.
- FANUC, R-30iB / R-30iB Mate controller maintenance manual, publication B-83195CM-07 and B-83525EN/01.
- FANUC, R-30iB Mini Plus controller maintenance manual, publication B-84175EN/03, alarm history section.
- Shanghai FANUC, zero point calibration after power loss, guidance manual, sections 2 and 4.
- FANUC Taiwan technical FAQ, alarm code section, accessed October 2026. https://www.fanuc.com.tw/skill.php?t=1
Case sources
The two records below are cited as examples of what happens in the field, not as technical authority. Every procedure in this article follows the FANUC publications listed above.
- Public robot forum thread, "Can't clear SRVO-062 BZAL alarm after replacing batteries", 8 December 2022. https://www.robot-forum.com/robotforum/thread/43123-can-t-clear-srvo-062-bzal-alarm-after-replacing-batteries/
- Public service record published in Chinese, "SRVO-223 and SRVO-058 fault summary", 3 January 2021. https://blog.csdn.net/duxiaokang2014/article/details/112133073
- Public robot forum thread, "HandlingPro import backup", 9 December 2019. https://www.robot-forum.com/robotforum/thread/33809-handlingpro-import-backup