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 was about to jump somewhere in the program and that somewhere does not exist. It can be a subprogram called with M98 that is not registered in memory, or a sequence number N that is jumped to and does not appear in any block. It stops before moving, so there is no crash risk, but the job is left half done.
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 programs disappear or memory does not correctly list existing files.
Reset after loading/correcting the applet and returning to a safe position.
Call syntax differs between Fanuc, Haas and OEM configurations.
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.
When the interpreter hits a subprogram call or a jump, it stops reading sequentially and has to locate the destination. For a subprogram it searches the directory of the active memory for a program whose O number matches exactly; for a sequence number it scans the body of the program looking for the first block that starts with that N. If the search ends without a match there is nothing to execute next, so it aborts with PS0073. The key point is that the search is literal and depends on where the control is looking: active memory is not the same thing when you are running from internal memory, from a memory card or over DNC, and a subprogram sitting perfectly on the card is invisible if the main program runs from internal memory. The same goes for the number: as far as the control is concerned, program 1234 and 01234 may or may not be the same thing depending on how the program number length is configured on that machine. The control does not guess and does not correct: either it matches or it does not exist.
In order, from the fastest and cheapest check to the most expensive.
01Read which number it was looking for
Look at the block where it stopped. If it is an M98 P, the number after the P is the subprogram. If it is an M99 P or a jump, it is a sequence number inside the program. Write that number down exactly as it appears, zeros included: leading zeros are part of the problem more often than you would think.
02List the control's program directory
Open the program list on screen and look for that number. If it is not there, the subprogram was never loaded or it was loaded under a different number. If there is something close, one or two digits out or different zeros, you already have your cause. If it is there and it still fails, move on to the next step.
03Check which device it is running from
The control runs from internal memory, from a memory card or over DNC, and each one is a separate store. If the main program runs from memory and the subprogram sits on the card, it will not be found. Confirm it by checking the active device on the program screen. With external program calls the requirement is stricter still: the device has to be available at the exact moment of the call.
04If it is a jump to an N, search for that number inside the program
Use the control's own sequence number search. If it cannot find it, the label was deleted during an edit or somebody renumbered the program. If it finds it but in a different program, the jump is pointing outside: sequence-number jumps do not cross from one program to another except in the specific call forms that explicitly allow it.
05Review the edit history and how the files were loaded
Ask what was touched last. A subprogram renamed on the server, a transfer that was cut off halfway, or a memory clean-up to free space all produce exactly this symptom. If it was an interrupted transfer, the program may be in the list but incomplete; compare it against the original on the server.
06Fix it and start from the top
Load or correct the subprogram, return to the start of the main program and dry run at least until you are past the call. Do not restart from the alarm block: the call may have been left half executed and the modal state is not trustworthy.
That job uses its own subprograms and they were not loaded alongside the main program. Confirm it by listing every O number the main program calls and looking for each one in the directory. The usual story is that the main program was transferred and the subprograms were forgotten.
A shared subprogram used by several jobs was deleted. It is confirmed by the fact that different jobs fail, all of them on the same M98. Restore it from backup; if there is no backup, this is the moment to make one for everything else.
A number or device mismatch: different leading zeros, a number outside the permitted range, or the main program in memory with the subprogram on the card. Confirm it by comparing the P number against the directory character by character and checking the active device.
Reserve a number range for the shop's common subprograms and never touch it: job subprograms live in another range and test programs in a third. Always transfer the main program and its subprograms as one package, not one at a time. Take a full directory backup before deleting anything to make space. And if a subprogram is general purpose (tool change, probing, safe retract), document it on a list posted at the machine so nobody deletes it thinking it belongs to an old job.
The control cannot find the block, tag, or subprogram number called by the main program. It is an alarm from the Program area, and in the catalog it is listed as “Sequence or subprogram number not found”. On the machine you notice it like this: Failure on M98, skip, repeat or search for N number, The program stops before entering the subprogram.
On the shop floor it almost always comes from one of these causes: Subprogram not loaded, Incorrect O/N number, Wrong memory or folder. Rule out the most likely one on your machine first, before touching parameters or swapping anything.
Reset after loading/correcting the applet and returning to a safe position. Resetting without fixing the cause first only hides the problem: PS0073 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: Confirm applet name, Check the active memory path, Find the sequence number from the control. That alone will tell you whether it is the program or whether you need to raise a maintenance job.
With PS0073 active, avoid this: Do not rename subprograms without checking every call, Don't run if you don't know which routine you should jump to. Skipping any of these points is what turns a minor stop into an expensive breakdown.
If programs disappear or memory does not correctly list existing files. 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. Call syntax differs between Fanuc, Haas and OEM configurations.
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.
