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 has read a numeric value with more digits than that address allows, or a block whose format it cannot interpret. It is a pure program-writing error: nothing to do with the machine. It always stops in the same place and it takes a minute to fix once you find 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.
Normally it does not require maintenance unless it occurs in valid programs or there is a memory failure.
Reset after correcting the block and returning to safe startup.
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.
Every address in a block has a permitted format: how many digits it can carry before and after the decimal point, whether it accepts a sign, and what range of values makes sense for that function. When the interpreter reads a word, it converts it to the control's internal representation using that format; if the number does not fit, it is not truncated or rounded, the block is rejected. The same happens if the block contains characters outside the valid set or if the structure cannot be interpreted. Two details explain most real cases. The first is the decimal point: on Fanuc, a value with no decimal point is interpreted according to the configured input format and can mean something very different from what the person writing it intended, so a number that looks reasonable can end up being enormous and out of range. The second is invisible characters: programs edited on a PC with an editor that inserts control characters, tabs or odd encodings, or serial transfers with errors that corrupt a character here and there. On screen the block looks normal, but the interpreter sees something else. So when the block looks perfect and it still fails, suspect where the file came from rather than what you read on screen.
In order, from the fastest and cheapest check to the most expensive.
01Find the block and read it character by character
Look for extra digits, a duplicated decimal point, a stray sign, a comma instead of a point, or two letters run together. Compare against the equivalent block from an earlier operation that does work. The difference nearly always shows up when you put two similar lines side by side.
02Check the decimal points on every dimension
Look at whether the program's coordinates and feed rates carry decimal points consistently. A value written with a point in one place and without one in another is the signature of a hurried manual edit. It is the most common cause of out-of-range values.
03Think about where the file came from
Generated by CAM, edited by hand at the machine, edited on a PC with a word processor, transferred over serial or brought in on USB. If it was edited with anything other than a plain-text editor, it may have inserted characters the control does not accept. Retyping the block directly at the control rules that out in a moment.
04If it came in by transfer, compare against the original
Open the original file on the server and compare the failing area against what is in the control. A difference in one specific character indicates a corrupt transfer, and then the problem is not the program but the communication: cable, baud rate or serial parameters.
05Fix it, go back to the top and dry run
Correct the block, return to the start of the program and let it read in single block with the axes clear above the part and the spindle stopped. If it stops on another similar block, the problem is systematic and the whole file has to be reviewed or re-posted from CAM.
06If it happens on programs that used to run fine, look at memory
A program that ran for months and suddenly has an odd character points at memory corruption or an accidental edit. Compare against the server copy. If corruption appears in several programs, tell maintenance: it may be the control battery.
A typing error: an extra digit, a forgotten point or a duplicated letter. Confirm it by comparing against the server copy. Fix it at the control and update the master copy too, so the error does not come back next time.
An invisible character inserted by a PC editor or by a corrupt transfer. Confirm it by retyping the block by hand at the control: if that gets it through, that was it. Fix it by using plain-text editors and by checking the transfer.
The post or the CAM output format changed, typically in how decimals are handled. Confirm it by comparing a new program against an old one for the same job. Fix it in the CAM system, not part by part at the machine.
Edit programs only with plain-text editors or at the control itself, never with word processors. A post processor that always emits a decimal point, which is how you stop depending on the input format. Transfer verification when serial is used, and a preference for media that does not corrupt data. A master copy of every program on the server, and the habit of updating it whenever something is corrected at the machine. And a dry run of the first execution of any new or edited program.
Fanuc detects incorrect tape/program format or a numerical value with more digits than allowed. It is an alarm from the Program area, and in the catalog it is listed as “Format error or too many digits”. On the machine you notice it like this: The program stops at a specific line, It usually appears after hand editing or post-processing.
On the shop floor it almost always comes from one of these causes: Number too long, Invalid character/format, Misplaced decimal point or sign, Wrong post-processor. Rule out the most likely one on your machine first, before touching parameters or swapping anything.
Reset after correcting the block and returning to safe startup. Resetting without fixing the cause first only hides the problem: PS001/PS003 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: Note the exact block, Check the X/Y/Z/F/S values and the decimals, Simulate after correcting. That alone will tell you whether it is the program or whether you need to raise a maintenance job.
With PS001/PS003 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.
Normally it does not require maintenance unless it occurs in valid programs or there is a memory failure. 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 stop alarm: the cycle will not continue until you fix the cause. It does not always mean serious damage, but it leaves the machine where it is and you have to check it before running again. 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.
