Fanuc PS110/PS111/PS112 alarm: Overflow or division by zero in calculus

What happens on the machine

Macros and cycles work with variables the control stores in a format with a defined range and precision. Every arithmetic operation is checked: whether the divisor is zero, whether the result falls outside the representable range, whether a function's argument is inside its domain. When any of that happens, the control does not invent a result or carry on with a nonsense value, because a nonsense value in a macro ends up as a nonsense coordinate and a crash. It aborts and raises the calculation alarm. The usual shop-floor cause is not a mathematical error: it is a variable arriving empty or holding an unexpected value. A local variable that was not passed as an argument in the macro call is left undefined, and doing arithmetic with it gives exactly this result. A variable that holds a probe measurement stays at zero if the measuring cycle never ran. A common variable used as a counter keeps the previous part's value if nobody initialises it at the start. There is also a classic trap in conditionals: comparing decimal variables expecting exact equality fails, because the internal representation is not exact, so a branch of the program that was supposed to initialise something never runs and the later calculation blows up. That is why the diagnosis is done by looking at the variable values at the moment of the failure, not by re-reading the formula.

Step-by-step diagnosis

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

1. 01Look at the variable values on screen

   The control has a macro variable screen showing the common variables and, during execution, the local ones of the active level. Right after the alarm, look at what the variables involved in the failed calculation hold. One at zero or empty when it should have a value is the answer in nine cases out of ten.

2. 02Check the macro call and its arguments

   Go over the line that calls the macro and compare it against the arguments the macro expects. A forgotten argument leaves its local variable undefined. An argument written with the wrong letter fills a different variable from the one the macro reads. Both give the same symptom.

3. 03Look for divisors that could be zero

   Walk through the divisions in the code and ask yourself whether the divisor could be zero in some situation: a calculated number of passes, a diameter that arrives empty, a step that works out as nil. The same goes for roots whose argument could come out negative from a subtraction of measurements. That is where a prior check belongs.

4. 04Check whether it depends on the part or on the moment

   If it only fails on certain parts, or only on the first part of the shift, there is a variable that is not initialised and is carrying values over. If it always fails, it is a structural error in the macro. The difference tells you whether to add initialisation or to fix the logic.

5. 05If probe measurements are involved, check the measurement actually happened

   Variables that receive probing results are left at zero or undefined if the measuring cycle never ran or never touched. There the problem is not the arithmetic: it is that the probe did not measure. Check the measuring cycle before touching the calculations.

6. 06If the macro belongs to the builder, do not edit it

   Many machines carry the builder's own macros, often protected, implementing machine cycles. If the failure happens inside one of them, the useful information is the values being passed to it from your program. Modifying builder macros without documentation is how you break machine functions.

Typical cases