Fanuc alarm 085, 086 and 087: causes and fixes
Three alarms cover almost every failed program transfer on a Fanuc control. Each one is telling you something specific — which means each one has a short list of causes, in a known order. Here is what the control is saying and what to change, for the person standing at the machine right now.
The one-line version: 085 is a settings mismatch, 086 is a cable or a dead device, and 087 is flow control. On 30i and 0i-F controls the same alarms appear as SR0085 / SR0086 / SR0087 and mean exactly the same things.
Start from the symptom, not the number
You already know what you saw. Find that row, and it tells you which alarm you are about to read about and the first thing worth changing.
| What you saw | Alarm | Change this first |
|---|---|---|
| Transfer starts, then dies. Garbage or missing characters. | 085 | Baud rate, then parity and stop bits |
| Nothing transfers at all. Alarm the moment you press READ or PUNCH. | 086 | Cable, converter power, handshake lines |
| Short programs fine. Long programs or drip-feed die part-way. | 087 | Flow control — XON/XOFF end to end |
| No alarm at all, and nothing happens. | — | Wrong I/O channel (parameter 0020), or the wrong mode on the control |
Alarm 085 — the data arrived in the wrong shape
The control read characters through the reader/puncher interface and could not make sense of them: an overrun, a framing error or a parity error. Nothing is broken. Two devices are speaking at each other with different assumptions about how a byte is packaged, and the control is the one that noticed.
Causes, in the order worth checking:
- Baud rate mismatch. The most common cause by a distance. Remember that the Fanuc parameter holds a code, not a number — 11 means 9600, not eleven baud. Confirm the control, the converter and the software all say the same thing.
- Parity or data bits. 7 data bits with even parity is the classic Fanuc combination, 8 bits with no parity the common modern one. Either works. Half of each does not.
- Stop bits. One end sending one stop bit to an end expecting two shows up as a framing error part-way through a file rather than immediately, which makes it feel intermittent when it is not.
- Baud too high for the cable run. 19200 down a long cable taped alongside servo wiring will drop characters that 9600 carries all day. If the settings genuinely match, drop one step and try again.
- ISO vs EIA. If what comes out is clearly a program but in the wrong alphabet, the two ends disagree about the character set.
How to confirm you have fixed it: punch a short program out of the machine and read it on the PC. If it comes out clean, the byte format now agrees in both directions, and any remaining failure is a different problem.
Alarm 086 — the control cannot see a device at all
The DR — data set ready — signal from the I/O device went off, or was never on. The control is not complaining about your data; it is saying there is nothing at the other end of the cable to talk to. It usually appears the moment you start the transfer, before a character moves.
Causes, in the order worth checking:
- The device is not powered.Check the converter's power light before anything else. A serial-to-Ethernet converter fed from a panel socket that is switched with the machine light is a genuine cause of this alarm and a genuinely annoying one to find.
- The cable is wrong, not broken. A working cable from another machine proves nothing here. Controls differ in which handshake lines they insist on seeing held high — some are content with three wires, others sit and wait on DR. This is why the same cable can be fine on one machine and raise 086 on the next one down the row.
- Handshake lines not looped. Where the control expects modem-control signals that a plain PC connection never provides, shop cables commonly satisfy it by looping those lines back at the control end. Which lines, and whether to do it at all, comes from the maintenance manual for your control — not from a cable someone made for a different machine.
- A break or a bad connector. Last, not first. Cables do fail, but far less often than they are wrong to begin with.
Note the shape of this one: 086 is the alarm that is not fixed by changing settings. If you find yourself adjusting baud rates against an 086, stop and go back to the cable.
Alarm 087 — the control said stop and nobody listened
The control's input buffer overflowed. It had asked the sender to pause — and the sender carried on. This is the flow-control alarm, and it is the one that costs the most, because it waits. A short program fits in the buffer whatever happens, so everything looks fine until the day someone drip-feeds a long one and loses it part-way through the cut.
Causes, in the order worth checking:
- XON/XOFF not enabled on every hop. Control, converter, and PC software all have to agree to it. Two out of three is the same as none: whichever hop ignores the pause is the one that overflows the buffer.
- A converter that buffers.A serial-to-Ethernet converter can accept the control's XOFF, stop the PC, and then keep feeding the control from data it has already taken in. The pause happened; the characters kept coming anyway.
- Software that sends blind. Anything that streams a file down a COM port without honouring DC3 will produce this alarm on any program long enough to matter. A terminal program is fine for proving a cable and wrong for drip-feed.
- Hardware handshake wired but not used.If the control is set for RTS/CTS and the cable does not carry those lines through, the control's request to stop physically cannot arrive.
- Baud rate faster than the machine can execute. In drip-feed the control is cutting metal while it reads. Send faster than it consumes and the buffer fills no matter how correct everything else is — this is the case where slowing down is the fix rather than a workaround.
How to confirm you have fixed it: re-test with a genuinely long program, not a short one. An 087 fix that is only proven on a 20-line test file is not proven at all — that is precisely the file that never triggered it.
Clearing the alarm, properly
- Press RESET on the control to clear the alarm.
- Cancel the transfer at the PC end too. Otherwise the next attempt starts with the sender part-way through the file, and the retry fails for a reason that has nothing to do with the original one.
- Change one thing. Re-test. Write down what you changed — two changes at once is how a ten-minute fix becomes an afternoon.
- Prove it by receiving before you trust it for sending: pulling a program out of the machine risks nothing in the control.
When it is none of the three
If the transfer does nothing at all and raises no alarm, the control is not failing to communicate — it is not trying. The usual reasons:
- The wrong I/O channel. Parameter 0020 selects the port the control actually uses. Settings carefully entered against a channel the control is not reading from will behave exactly like nothing happening.
- The wrong mode. The control has to be in a mode that permits the operation before it will accept a program at all.
- Program protect. A control that will not be written to will decline quietly rather than alarm.
- Memory. A program larger than free control memory is a different failure from a communication one, and the fix for it is drip-feed, not a cable.
The parameters behind all three
Every fix above eventually lands on a parameter: the I/O channel, the character format, the device number, the baud-rate code. The Fanuc RS-232 settings reference has the parameter numbers per channel and the full baud-rate code table — including the fact that the value you type is a code rather than the rate itself, which is its own small source of alarm 085.
Read next
If these alarms keep coming back on a long program, drip-feeding programs bigger than control memory covers how the transfer is supposed to behave. If the serial link is the thing you are trying to get rid of, there is program transfer over Ethernet and the converter buying guide, which covers which units pass flow control properly and which quietly do not. To test any change without risking what is in the control, pull a program out of the machine first.
Questions
What does Fanuc alarm 085 mean?
The control received a character it could not make sense of during a transfer through the reader/puncher interface — an overrun, framing or parity error. In plain terms, the bytes arrived but in the wrong shape, which is almost always a settings mismatch between the control, the converter and the PC rather than a fault in any of them. Check baud rate first, then parity and stop bits.
What does Fanuc alarm 086 mean?
The DR (data set ready) signal from the I/O device went off, so as far as the control is concerned nothing is connected. This is wiring or power, not data: a dead converter, a broken or wrong cable, or handshake lines the control expects to be held high and nobody has wired. It usually appears the instant you start the transfer, before a single character moves.
What does Fanuc alarm 087 mean?
The control told the sender to stop and the sender kept sending, so its input buffer overflowed. It means flow control is not reaching the PC. Because a short program fits in the buffer regardless, alarm 087 typically only appears on long programs and during drip-feed — sometimes forty minutes into a cut.
How do I clear alarm 085, 086 or 087?
Press RESET on the control to clear the alarm itself, then cancel the transfer at the PC end before retrying — otherwise the next attempt starts with the sender mid-file. Clearing the alarm does not fix the cause: the same transfer will fail the same way until the setting, cable or flow control behind it is corrected.
What is SR0085 on a Fanuc 30i or 0i-F?
The same alarm. Newer controls prefix serial I/O alarms with SR, so 085, 086 and 087 appear as SR0085, SR0086 and SR0087, with identical causes and fixes.
Why does the same cable work on one machine and not another?
Because the two controls do not expect the same handshake. One may be satisfied with three wires and ignore the modem control lines; another will sit there waiting on DR and raise alarm 086. This is why a cable that has worked in the shop for years can fail on the machine you bought last month, and why a cable is not proof of anything until it has worked on that machine.
Can a serial-to-Ethernet converter cause these alarms?
Yes, and it is a common cause of 087 in particular. A converter that does not pass XON/XOFF through to the PC, or that buffers aggressively, will happily accept the control's request to stop and keep feeding it from its own buffer. Set the converter's serial parameters to match the control exactly, and enable the same flow control on every hop.
Do these alarms mean the machine is faulty?
Almost never. All three are I/O alarms raised by the reader/puncher interface, and they describe a conversation that went wrong between two devices. A control that machines all day and only alarms during transfers has a communication problem, not a hardware failure.