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 family of program management messages: the data searched for does not turn up, the number of programs memory allows has been exceeded, the number is already in use, or the verification between what was sent and what was stored does not match. None of them is a machine fault, but they all share the same trap: the quick fix is usually to delete, and deleting without a backup is how programs get lost.
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 memory does not list existing programs or checks fail with correct cables/parameters.
Reset after correcting memory, program number or transfer.
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.
The control's program memory is a store with two independent limits: total space and the maximum number of registered programs. The control also keeps a directory of registered numbers and, when asked to save one that already exists, behaves according to its configuration: it can reject it rather than overwrite. Verification is another matter: when a program is transferred, what is in the control can be compared character by character against the source; if a difference turns up, the control flags it. And that is where the useful information in this family lies: a failed verification almost never means the control is wrong, it means the transfer introduced an error. When that happens on the serial channel, the cause is usually noise, a cable in poor condition, or badly configured flow control that loses characters when the control falls behind processing. A program that has come through a transfer with errors can look perfectly normal and have one dimension changed in the middle, which is exactly the kind of fault you discover with the tool inside the part. So verification is not a formality: it is what separates a transferred program from a correctly transferred program.
In order, from the fastest and cheapest check to the most expensive.
01Classify what the control is telling you
Not finding a piece of data, not fitting any more programs, the number already existing, and verification not matching are four different things. Note the exact alarm number and look its meaning up in your series' manual. The treatment is different in each case.
02If it is full memory or duplicate programs, back up before touching anything
Get every program out to the server or a card and check the copy is complete. Only then decide what to delete, one at a time and deliberately. The shop's common subprograms are not touched, however old they look.
03If it is a duplicate number, decide deliberately before overwriting
Check whether the program that already exists is a different version of the same job or something else entirely with the same number. Compare them before replacing anything: overwriting the good version with an old one is a mistake you pay for on the next batch.
04If verification fails, do not run that program
A program that does not verify very probably has some character different from the original, and that could be a dimension. Delete it and transfer it again. If verification fails again, the problem is the link, not the file.
05Attack the link if verification fails repeatedly
Lower the baud rate at both ends, check parity and flow control, try another cable and check it does not run alongside power lines. If it verifies correctly at low speed, you have noise or a cable in poor condition, even if it works for now.
06If memory does not behave as it should, tell maintenance
If deleting does not free space, if the control reports less capacity than it should, or if corrupt programs appear with nobody having touched them, there may be a memory or control battery problem. With a backup in hand, let maintenance look at it.
Noise or badly set flow control losing characters. Confirm it by lowering the baud rate and seeing whether it then verifies. Fix it by setting up the communication and reviewing the cable route and condition.
The program is on another device or in a protected range that is not listed in the active view. Confirm it by checking the different devices and the program protection configuration. It is solved by using another number.
Accumulation of versions and tests with no clean-up policy. Confirm it by listing the directory. Fix it with automatic backup to the server and scheduled clean-ups, plus a numbering convention that distinguishes production from tests.
Always verify transfers, not just send them, and never run a program that has not verified. Automatic backup of each machine's programs to the server. A numbering convention separating common subprograms, production and tests. Scheduled memory clean-ups with a backup taken first. And migrate to card or network wherever the machine allows, which removes serial channel verification problems at the root.
Fanuc detects data not found, excess programs, program number already used or difference in verification. It is an alarm from the Program area, and in the catalog it is listed as “Memory errors, duplicate programs or verification”. On the machine you notice it like this: Does not load or save program, Fails when verifying the transfer, The program already exists or does not appear in memory.
On the shop floor it almost always comes from one of these causes: Memory full or fragmented, Duplicate program, Incomplete DNC/RS232 transfer, Wrong O number. Rule out the most likely one on your machine first, before touching parameters or swapping anything.
Reset after correcting memory, program number or transfer. Resetting without fixing the cause first only hides the problem: PS0071/PS0072/PS0079 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: Make a backup before deleting, Compare the source file with the control, Repeat transfer with correct parameters. That alone will tell you whether it is the program or whether you need to raise a maintenance job.
With PS0071/PS0072/PS0079 active, avoid this: Do not delete memory without backup, Do not overwrite production programs without checking differences. Skipping any of these points is what turns a minor stop into an expensive breakdown.
If memory does not list existing programs or checks fail with correct cables/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.
