Fanuc PS0076 alarm: P address not defined (M98)

What happens on the machine

When the interpreter reads a subprogram call, it expects to find in the same block the address identifying the destination and, optionally, the number of repeats. That address is mandatory: without it the instruction is incomplete and the control has no basis for deciding where to jump, so it aborts before doing anything. The interesting part is how you end up with a block like that. Somebody rarely writes a call and forgets the destination from scratch; what usually happens is that the block was left half-edited, that a find-and-replace on the PC took out part of the line, that the transfer was cut off right there, or that the original block carried the number in a macro variable that has no value at run time. That last case is the most interesting: in programs that build the call from a variable, if the variable arrives empty because it was not passed as an argument or was never initialised, the control sees a call with no valid destination and complains exactly as if it had never been written. So when the block looks complete on screen and it still fails, look at the variable values at run time and not only at the text.

Step-by-step diagnosis

In order, from the fastest and cheapest check to the most expensive.

1. 01Read the whole block where it stopped

   Check whether the destination address is present and correctly written, with digits and no odd characters. Also look for anything stuck to it that should not be there, such as leftovers from a previous edit. Most cases are visible at a glance.

2. 02Compare against other calls in the same program

   If the program has other subprogram calls that do work, put them side by side. The difference in format between the failing one and the working ones points at the error immediately, and it also tells you what the correct form is on that machine.

3. 03If the destination comes from a variable, look at its value

   On the macro variable screen, check what the variable supplying the number holds at the moment of the failure. If it is empty or zero, the problem is not the block: the variable never arrived. Review the macro call and its arguments.

4. 04Compare against the server copy

   Open the original program and look at that same block. If it is complete in the original and not at the machine, there was an accidental edit or a corrupt transfer, and it is worth reviewing the rest of the file, not just that line.

5. 05Review the post processor if it repeats

   If the same failure appears in several programs from the same CAM system, the post is emitting the call wrongly. Fixing it there stops the scene repeating every week. The clue is that the error always lands on the same kind of operation.

6. 06Fix it and validate from the top

   Correct the block, go back to the start of the program and dry run at least until you are past the call, checking that it enters the right subprogram. A corrected call with the wrong number gives no alarm: it runs something else, which is worse.

Typical cases