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.
Two different causes under the same alarm: either the subprogram called does not turn up, or the number of nesting levels the control allows has been exceeded. The second one is the more misleading, because every individual call is correct and the problem is the accumulation.
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 subprograms disappear for no reason or memory does not list existing files.
Reset after loading the subprogram or reducing the nesting.
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 time the program enters a subprogram, the control stacks the information needed to come back: which program it was called from, at which block, how many repeats are left. That stack has a fixed number of levels, and the limit depends on the series and on whether macro calls are used, since they consume levels from their own count. As long as you go in and out in an orderly way, the stack rises and falls. The problem appears when the depth grows beyond what was planned, and that happens in two ways. The obvious one: a structure with many chained levels, typical of modular programs where the main program calls a family of operations, each operation calls a pattern and the pattern calls a cycle. The treacherous one: a subprogram that calls itself, directly or indirectly, because an exit condition is never met; there the stack fills in a moment and the alarm always trips at the same point, giving the impression the subprogram is wrong when what is wrong is the exit logic. The other half of the cases is simply that the destination does not exist on the device being executed from, and there it is worth remembering that internal memory, card and external execution are separate stores, and that a call to an external program needs the device to be available at that exact instant.
In order, from the fastest and cheapest check to the most expensive.
01First check whether the subprogram exists and where
List the directory and look for the number called. If it is not there, the diagnosis is about loading. If it is there, check which device the main program is running from: memory, card or external, because each one only sees its own.
02If it exists, count the nesting levels
Draw the call tree: main program, what it calls, what that calls, and so on to the end. Count the levels on the deepest branch and include macro calls. Compare against the limit given in your series' manual. If you are right on the edge, any recent addition has pushed it over.
03Look for recursive calls or loops with no exit
Check whether any subprogram ends up calling itself by an indirect route, or whether a repeat loop has no reachable exit condition. If the alarm always trips after the same number of repeats, this is almost certainly it.
04Check the return from every subprogram
A subprogram that does not return correctly leaves the level open, and the stack fills call after call even though the program appears to finish each cycle. You can tell because the alarm appears after several parts, not on the first one.
05If it is an external program call, check the link
Execution from an external device depends on the link being alive at the moment of the call. Check the connection, the selected device, and that the file is where the control looks for it with the exact name it expects.
06Flatten the structure if you have to
If the tree is legitimately deep, the answer is not to fight the limit: it is to remove one level, merging two subprograms or lifting a call up into the main program. It is easier to maintain and it does not come back the next time an operation is added.
Recursion or levels that never close: the stack fills progressively. It is confirmed by how repeatable the number is. Fix it by reviewing the exit conditions and the returns from every subprogram.
The structure was at the level limit and the addition pushed it over. Confirm it by counting the call tree before and after. Fix it by flattening a level, not by removing the operation.
Different devices: the control does not see the card from internal memory. Confirm it by checking the active device. It is solved by putting both in the same place, or by running everything from the same device.
A program structure with a reasonable, documented depth, and resisting the temptation to chain one more level every time a variant comes up. The shop's common subprograms in a reserved number range, always loaded in the same memory. Transfer the main program and subprograms as one package. Review the call tree whenever a modular program is modified. And name subprograms to a clear scheme, because half the nesting tangles come from not knowing what calls what.
Fanuc cannot find the subprogram called by M98/M198, or the nesting level is exceeded. It is an alarm from the Program area, and in the catalog it is listed as “Subprogram not found or nested too deeply”. On the machine you notice it like this: Failure in M98/M198, Program stops before entering sub, May occur with macros.
On the shop floor it almost always comes from one of these causes: Subprogram not registered, Nesting greater than allowed (typical 4-10 levels), Program on external device not available, Incorrect O number. Rule out the most likely one on your machine first, before touching parameters or swapping anything.
Reset after loading the subprogram or reducing the nesting. Resetting without fixing the cause first only hides the problem: PS0077 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 registration, Count nested M98/M99 levels, Check the external device if using M198. That alone will tell you whether it is the program or whether you need to raise a maintenance job.
With PS0077 active, avoid this: Do not skip blocks hoping it will load, Do not delete applets used by production. Skipping any of these points is what turns a minor stop into an expensive breakdown.
If subprograms disappear for no reason or memory does not 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. 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.
