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.
The control's data input and output communication has failed: it could not read or send a program over the serial channel or over DNC. The machine itself is fine; what is not working is the link. It is nearly always configuration, cable or the equipment at the other end.
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 communication fails with cables/parameters confirmed.
Reset after closing 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.
On a great many machines the control's serial channel is still the route programs come in and go out by. For it to work, both ends have to agree on a set of settings: baud rate, data bits, parity, stop bits and the flow control method, plus the wiring, which is not just any cable but one with the signals crossed or straight through depending on what each device expects. The control also ties those settings to a specific channel, and the one in use has to be selected. When the control tries to read and receives nothing within the expected time, or receives characters that do not fit the agreed configuration, or the other end stops responding halfway, it raises an interface alarm. The part that wastes the most time is that these settings are symmetrical: changing the baud rate on the PC and not on the control, or the other way round, means you receive rubbish or nothing, and the symptom is identical to a broken cable. Another very real quirk: as soon as the link goes through a USB-to-serial adapter, the PC driver comes into play, and it can change the port number without warning or behave differently after a system update, so a link that had worked for years stops working with nobody having touched the machine.
In order, from the fastest and cheapest check to the most expensive.
01Check the other end first
That the PC or sending device is switched on, with the transfer software open, the correct port selected and the file ready to send. A large share of these alarms is resolved right here, especially if somebody changed PC, updated the system or moved the adapter.
02Compare the settings on both sides, one by one
Baud rate, data bits, parity, stop bits and flow control have to match exactly. Write them down from both ends on a piece of paper and compare. At the control, also check that the selected channel is the one that is wired.
03Check the cable and its connectors
That it is properly plugged in at both ends with no strain, and that it is the right cable for this machine; not all serial cables carry the same signals. If you have another cable known to be good, swapping it is the fastest test. Long cables run through the shop next to power lines pick up noise and fail intermittently.
04Lower the baud rate
If the transfer starts and cuts off halfway, or corrupt characters arrive, try lowering the rate at both ends. A link that fails at high speed and works at low speed is telling you there is noise or a cable in poor condition, even if it lets you work for now.
05Try the other direction
If receiving fails, try sending a small program from the control to the PC. If output works and input does not, the problem is narrowed down. If both directions fail, look at cable and settings before anything else.
06If everything matches and it still fails, it is a maintenance job
With settings verified, the cable proven and the other end working, what is left is the control's board or port. That is a maintenance diagnosis. In the meantime, if the machine accepts a memory card or USB, use that as an alternative so production does not stop.
Different settings in the new software, or a port number changed by the USB-to-serial adapter. Confirm it by checking the sending program's settings and the port assigned by the system. Fix it by matching the settings to the control's.
Noise or badly configured flow control: the control cannot tell the sender to pause while it processes. Confirm it by lowering the baud rate and seeing whether it arrives complete. Fix it by setting up flow control and reviewing the cable route.
Electromagnetic interference on the cable. It is confirmed by the coincidence. Fix it by separating the cable from power lines, using properly earthed screened cable, or moving to a transfer route that does not depend on serial.
Each machine's communication settings written on a label stuck next to the port, with baud rate, parity and flow control: that alone saves half these incidents. Serial cables identified, of good quality and routed away from power lines. A stable transfer PC, with no updates mid-shift and the software configured and saved. Migrate to memory card or network wherever the machine allows, keeping serial as a backup. And a master copy of every program on the server, so you do not depend on the transfer working first time.
Fanuc detects data input/output communication failure, DNC or reader/puncher interface. It is an alarm from the PLC/machine area, and in the catalog it is listed as “Reader/punch interface error”. On the machine you notice it like this: Does not load or send programs, RS232/DNC transfer failure, Alarm when reading tape/file.
On the shop floor it almost always comes from one of these causes: Incorrect communication parameters, RS232/DNC cable, Baud rate/parity, External device not ready. Rule out the most likely one on your machine first, before touching parameters or swapping anything.
Reset after closing transfer and correcting communication. Resetting without fixing the cause first only hides the problem: PS086/PS087 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: Review communication parameters, Test the cable/device, Check the file name and format. That alone will tell you whether it is the program or whether you need to raise a maintenance job.
With PS086/PS087 active, avoid this: Do not bypass safety devices, Do not manipulate energized electrical cabinet, Do not continue producing if the alarm reappears. Skipping any of these points is what turns a minor stop into an expensive breakdown.
If communication fails with cables/parameters confirmed. 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.
