We use technical and security cookies and, only if you accept, analytics with no cross-site tracking. More in the Cookie policy and Privacy policy.
We use first-party cookies and technical storage to make the site work, Google reCAPTCHA security technology and, only if you accept, Vercel analytics (no cookies, no cross-site tracking). You can accept or reject analytics; both options are equivalent and you can change your choice at any time. More info: Cookie policy, Privacy policy, Legal notice and Terms and conditions.
A communication error on the serial channel while data was coming in: lost characters, badly formed frames, or the control receiving faster than it could process. Whatever program was loading is left incomplete or corrupt, so the first thing is not to run it.
For reference only: alarms change with the manufacturer, the control and the machine PLC. Check the full code in the official manual before doing anything. Legal notice.
If it fails with cable and verified parameters.
Reset after canceling transfer and correcting communication.
Choose the manual matching your control series, software version and machine builder. A support portal is a starting point; it does not establish applicability to every model.
In a serial transmission, the receiver collects characters one at a time and stores them in a small buffer while it processes them. That scheme works as long as the arrival rate does not exceed the processing rate. If the sender transmits faster than the receiver can absorb, the buffer fills and the following characters are lost: that is what overflow means. If on top of that the data bit, parity or stop bit settings do not match at the two ends, the receiver misreads where each character starts and finishes and detects badly formed frames. And if there is electrical noise on the cable, bits get flipped and the control sees them as parity errors or as impossible characters. All three cases end in the same alarm and they share something important: they are fixed by adjusting the link, not the machine. The key piece is flow control, the mechanism by which the receiver tells the sender to pause while it catches up. If it is not properly configured at both ends, any long transfer will eventually overflow the buffer, and the characteristic symptom is that the transfer starts fine and always cuts off around the same point. And there is a modern factor: PC USB-to-serial adapters introduce their own buffering behaviour, and a cheap adapter can produce exactly these errors on a link that worked perfectly with a real serial port.
In order, from the fastest and cheapest check to the most expensive.
01Discard the program that was received
What arrived during a transfer with errors is not trustworthy even if it looks complete. Delete it from the control and do not run it under any circumstances: one changed character in a dimension is a crash. Start the transfer again from scratch.
02Match the settings at both ends
Baud rate, data bits, parity, stop bits and flow control. Write them down from both sides on a piece of paper and compare them point by point. At the control, also check that the selected channel is the one that is wired.
03Lower the baud rate and try again
Reducing the rate at both ends is the most informative diagnostic test there is: if the transfer comes through complete and verifies at low speed, you have noise, a cable in poor condition or inadequate flow control. If it fails just the same, the problem is settings or hardware.
04Check the cable and its route
Connector condition, strain, and above all where it runs: a serial cable laid alongside power lines or near drives picks up noise. Swapping for a cable known to be good rules out half the causes in two minutes.
05Suspect the PC's USB-to-serial adapter
If the link goes through an adapter, try a better quality one or a PC with a real serial port. It has been a very common cause since PCs stopped coming with serial ports, and it produces intermittent errors that are hard to explain any other way.
06Always verify after transferring
Once the transfer goes through, verify between the control and the source. Only when it verifies with no differences is the program usable. That check is the filter that stops you running a corrupt file.
Buffer overflow from badly configured flow control. It is confirmed because it comes through complete at a lower baud rate. Fix it by setting up flow control at both ends, not by leaving the rate low as a permanent patch.
Electrical noise coupled into the cable. It is confirmed by the correlation. Fix it by separating the cable from power lines, using screened cable with the screen properly connected, or switching to another transfer route.
Different settings or a poor quality adapter. Confirm it by comparing settings and trying another adapter. Fix it by matching the configuration and, if necessary, changing the adapter for one of known quality.
Each machine's communication settings on a visible label next to the port. Good quality screened serial cables, identified and routed away from power. A USB-to-serial adapter that has been proven and reserved for this job, not whatever anybody has in a drawer. Mandatory verification after every transfer, as part of the procedure. And migration to memory card or network wherever the machine allows, leaving serial only as a backup.
Fanuc detects overrun, framing or other communication failure when saving data via ASR/RS232. It is an alarm from the PLC/machine area, and in the catalog it is listed as “Serial communication error when storing data”. On the machine you notice it like this: Fails when loading over RS232/DNC, Corrupted characters, The transfer is cut off.
On the shop floor it almost always comes from one of these causes: Incorrect baud rate/parity, Faulty RS232 cable, Misconfigured handshake, Electrical noise. Rule out the most likely one on your machine first, before touching parameters or swapping anything.
Reset after canceling transfer and correcting communication. Resetting without fixing the cause first only hides the problem: PS0085 trips again and, in the meantime, you keep working with the machine in bad shape.
With the machine stopped and in a safe state, start with these checks: Check the baud rate, parity and stop bits, Try another cable, Reduce transfer speed. That alone will tell you whether it is the program or whether you need to raise a maintenance job.
With PS0085 active, avoid this: Do not run a downloaded program with errors, Do not modify communication parameters without writing down previous values. Skipping any of these points is what turns a minor stop into an expensive breakdown.
If it fails with cable and verified parameters. If you are not sure how far it goes, stop the machine and report it: a repeat alarm always works out cheaper than a crash.
It is a warning: the machine carries on, but it is flagging something that will get worse if you let it go. Deal with it between parts, not at the end of the shift. Guidance reference. Always confirm the full text in the exact machine/control manual.
List of G and M Codes for CNC Programming. Search and filter ISO commands by control, machine or function.
CNC IDE: editing with G/M tooltips, line inspector, conversion between controls and 2D/3D toolpath.
Estimate CNC turning and milling cycle time from G-code. Calculate parts per hour with a breakdown of cutting, rapids, canned cycles and tool changes.
