CNC Macro | Real versus Integer Values


Though perhaps inappropriate, Fanuc control is very liberal in the use of real numbers in place of integer numbers, and vice versa, in macro statements (only).

While integer numbers in place of real numbers do not cause any problem, real numbers (direct assignment or the value of an arithmetic expression) used in place of integer numbers are automatically rounded. This has already been explained with reference to designation numbers of variables.

Here are some different examples (once again, this is only a theoretical discussion, with the sole purpose of explaining the logic being followed by the control, as it might help in error diagnosis):

#1 = 1000.4999;
M03 S#1; (Equivalent to M03 S1000)
# 1 = 1000.5000 ;
M03 S#1 ; (Equivalent to M03 51001)
M03 S1000.0; (An illegal statement. 5-value must be an integer number)
# 1 = 3 .4999999;
M#1 S1000 ; (Equivalent to M03 51000)
#1 = 3 .5000000;
M#1 S1000; (Equivalent to M04 51000)
M3.0 S1000; (An illegal statement. M-value must be an integer number)

Although the last statement is illegal, if 3.0 (or some other real number or expression) is enclosed within square brackets, it becomes a macro expression, and rounding is done:

M[ 3.0 ] S1000; (Equivalent to M03 S1000)
M[ 3.4999999 ] S1000 ; (Equivalent to M03 S1000)
M[ 3.5] S1000 ; (Equivalent to M04 S1000)
This also applies to all other addresses (except G-eodes) such as spindle speed also:
M03 S[ 1000.0]; (Equivalent to M03 S1000)
M03 S[1000.4999]; (Equivalent to M03 S1000)
M03 S[1000.5000 ]; (Equivalent to M03 S1001)

All these square brackets can also contain arithmetic expressions. Note that if parameter 3451#2 (on a milling machine only; this parameter is not available on a lathe) is set to 1, the spindle speed can have up to one decimal point, though the interpreted speed would be the rounded integer value:

S1000.5 ; (Equivalent to S1001, if parameter 3451#2 = 1)
S1000.50 ; (Illegal, because of more than one decimal place)

Too much flexibility makes a programming language rather “undisciplined,” and it becomes error-prone. An inadvertent mistake by the programmer might be interpreted “correctly” by the machine, leading to undesirable consequences. And this is very possible because macro programming may involve complex calculations and complicated logic. In the author’s opinion, a real value must not be accepted where an integer value is required. Moreover, Fanuc control (in fact, perhaps all controls) treats a null variable as a variable having 0 value in arithmetic calculations. This is again illogical and may prove to be dangerous. Typing mistakes are always possible. Perhaps the control manufacturers should modify their macro compilers to make it a PASCAL-like disciplined language. Presently, the programmer has to very meticulously understand the logic followed by the macro compilers.

The problem is more severe in the use of G-codes. The control does not allow any macro expression as the number of a G-code. So, a command such as G[Ol] is not equivalent to G01, and is illegal. But, one must be aware that the control may not give an error message in all cases. For example, G[03] causes an unexpected tool movement at rapid traverse rate on 0i Mate TC control, which may cause an accident on the machine. So, as a rule of thumb, never use a macro expression as the number of a G-code.

G-codes can, however, use macro variables as their numbers. These variables also can be defined in terms of an arithmetic expression. Though no practical application may ever need to use expressions for defining these variables, one should be aware of even theoretical possibilities, which might be helpful in interpreting the outcome of certain mistakes in the program:

#1 = 0; (Stores 0.000 in #1)
#2 = 1; (Stores 1.000 in #2)
IF [#2 GT #1 ] THEN #3 = 99 ; (TRUE condition, so #3 becomes 99.000)
#4 = [#2 + #3] / 2; (Calculation makes #4 equal to 50.000)
G#1; (Equivalent to G00)
G#2; (Equivalent to G01)
G#3; (Equivalent to G99)
G#4; (Equivalent to G50)