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 had to jump to a sequence number and cannot find it. It happens on returns with a destination, on conditional macro jumps and in loops. The program stops without moving, so there is no immediate risk, but the program logic is broken at that point.
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 needs no maintenance; call if memory loses data.
Reset after correcting program.
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.
A sequence number is a label: the sequence letter at the start of a block marks that block as a possible destination. When the control has to jump, it scans the program looking for the first block starting with that label and continues from there. It is a literal search with limited scope: it is normally done within the program being executed, and a jump does not cross into another program except in the call forms that expressly provide for it. That gives rise to the three usual failures. First, the label was deleted or renumbered: it only takes somebody running an automatic renumbering tool or editing a line and dropping its label for every jump pointing there to be orphaned. Second, the label is in another program: whoever wrote it assumed the jump would reach the subprogram, and it does not. And third, more subtle: the label exists but sits in a part of the program that is never reached in that mode of execution, for example beyond the end of program or inside a block skipped with block delete active. That last one wastes the most time, because the number is there, you can see it, and the control still says it cannot find it.
In order, from the fastest and cheapest check to the most expensive.
01Note which number it was trying to jump to
Look at the block where it stopped and what destination it was asking for. Write the exact number down. From there, the whole diagnosis is working out where that label is, or where it should be.
02Search for that number with the control's search function
If the control cannot find it inside the program being executed, the label is not where it is expected. If it does find it, note exactly which part of the program it is in and whether that area is reached in the way the program is being run.
03Check whether the label is in another program
Open the subprogram or the related program and search there. If it is in another file, the jump is badly conceived: the logic has to be rebuilt with a subprogram call, not a jump.
04Rule out block delete and automatic edits
If the label's block carries the optional skip mark and that function is on, the block can be left out. And if somebody ran an automatic block renumbering, every label changed even though the jumps still point at the old ones.
05Compare against the good copy of the program
Open the original on the server and look for the label there. If it is in the original and not at the machine, there was an accidental edit or a corrupt transfer, and the right move is to reload the whole program.
06Fix it and test the jump logic in a dry run
With the label restored, dry run the program checking that the loop enters and exits the expected number of times. A restored jump pointing at the wrong block gives no alarm: it does something else.
The renumbering changed the labels and the jumps were left pointing at numbers that no longer exist. Confirm it against the previous version. Fix it by restoring the good copy or by updating every jump, which is more laborious.
It is in another program, past the end of program, or in a block excluded by active block delete. Confirm it by checking exactly where it is and which functions are active on the panel.
A search from an intermediate block does not see what is ahead of the start point, or the modals are not the same. It is confirmed because it works from the top. The answer is to restart from start blocks prepared for it.
Do not renumber blocks in programs that use jumps, or if you do, use a tool that updates the destinations as well. Use subprogram calls instead of jumps when the logic crosses from one file to another. Label only the blocks that really are destinations, so it is clear what is structure and what is filler. A master copy on the server and a full reload instead of patching. And dry-run validation of loop logic before producing, counting the actual repeats.
Fanuc does not find the sequence number/tag N referenced by M98, M99 or jump. It is an alarm from the Program area, and in the catalog it is listed as “Sequence number not found”. On the machine you notice it like this: M99 P failure, skip or resume, The loop cannot find the label, Occurs at one particular jump.
On the shop floor it almost always comes from one of these causes: N label deleted or renamed, Jump to non-existent number, Incomplete edition of the program, Search started from wrong block. Rule out the most likely one on your machine first, before touching parameters or swapping anything.
Reset after correcting program. Resetting without fixing the cause first only hides the problem: PS0078 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: Find the number N in the program, Confirm jump points, Boot from safe boot after correction. That alone will tell you whether it is the program or whether you need to raise a maintenance job.
With PS0078 active, avoid this: Do not resume from mid-program without understanding the modal states, Do not delete tags used by applets. Skipping any of these points is what turns a minor stop into an expensive breakdown.
Normally needs no maintenance; call if memory loses data. 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.
