using a counter

[gravy]

I've used a variable as a counter in a number of macros to control the number of times things are done, in what order, etc.. Like in the logic below which does a macro at different places in X, the first at zero, the second at 6.5, third 16., fourth 22.5. (These are vise stops)


N1
G65 P20
#101=[#101+1.] (increment counter)
IF[#101EQ1.]THEN[#102=6.5]
IF[#101EQ2.]THEN[#102=16.]
IF[#101EQ3.]THEN[#102=22.5]
G52 X#102
GOTO1

What I'm wondering is if this is something where the limitations of binary arithmetic will eventually burn me. If I'm doing a bunch of math in a macro it seems to be an issue but just doing a counter seems to work. Am I just lucky?

[Eurisko]

Checking for equalities with floating point numbers can be a little tricky. However, your counters are essentially integers, and that's a different story.

As long as the counter is properly initialized, and is checked for a terminal value at each iteration, you should be fine.

I would also use a default (harmless) value for #102. If none of the comparisons succeed, what is the value of #102 ?

[gravy]

Checking for equalities with floating point numbers can be a little tricky. However, your counters are essentially integers, and that's a different story.

As long as the counter is properly initialized, and is checked for a terminal value at each iteration, you should be fine.

I would also use a default (harmless) value for #102. If none of the comparisons succeed, what is the value of #102 ?

Quick questions on break here.

What do you mean "terminal value"? So integers pretty much always succeed?

Thanks for your help!

[Eurisko]

...What do you mean "terminal value"?...

A terminal value would be the first invalid count that the routine sees.

If you're using 3 vise stops, the value of the counter can only be 1, 2 or 3.
If the counter increments to 4, your program has to recognize that and take the appropriate (terminating) action.

...So integers pretty much always succeed? ...

It is still a floating-point representation of an integer. It is valid only if the "integer" doesn't exceed the physical limits of the control. For example, If the control is capable of 12 significant digits, that would limit the size of the integer. You can calculate incredibly large or small numbers, but only the significant digits are stored. 3.02178362898 E +200 would truncate a LOT of digits.

The problem with comparing floating point numbers is due to these limits of precision (and rounding). Hope this makes sense.

[gravy]

A terminal value would be the first invalid count that the routine sees.

If you're using 3 vise stops, the value of the counter can only be 1, 2 or 3.
If the counter increments to 4, your program has to recognize that and take the appropriate (terminating) action.


It is still a floating-point representation of an integer. It is valid only if the "integer" doesn't exceed the physical limits of the control. For example, If the control is capable of 12 significant digits, that would limit the size of the integer. You can calculate incredibly large or small numbers, but only the significant digits are stored. 3.02178362898 E +200 would truncate a LOT of digits.

The problem with comparing floating point numbers is due to these limits of precision (and rounding). Hope this makes sense.

I just thought of this. If it is really a problem I could do this

#101=[#101+.1]
#101=FIX[#101]

before the IF THEN statements to first make the numbers greater than the target integer and then truncate them.

That's a lot of trouble. Is it really necessary do you think?

[Eurisko]

I just thought of this. If it is really a problem I could do this

#101=[#101+.1]
#101=FIX[#101]

before the IF THEN statements to first make the numbers greater than the target integer and then truncate them.

That's a lot of trouble. Is it really necessary do you think?

Don't do it. Your counters will work fine just by incrementing them. The control will have no problem adding 1 to a small integer. It will have no problem comparing 2 small integers. Precision won't be a problem.

[stevo1]

Gravy,
What Eurisko is referring to on "if the comparisons don’t succeed" is how do you end the program. If you come out of your program 20 sub on vise #3 this means that #101=3. Now when it runs through your calculations it get’s set #101=4. You have no X#102 value or equation programmed for #101 if it’s set to 4 so you would run the same vise(3) over and over again.

I would stick a calculation in the program so when your 3 vises are complete then the program ends.

N1
G65 P20
#101=[#101+1.] (increment counter)
IF[#101EQ1.]THEN[#102=6.5]
IF[#101EQ2.]THEN[#102=16.]
IF[#101EQ3.]THEN[#102=22.5]
IF[#101GT3.]GOTO2
G52 X#102
GOTO1
N2M30

Ahhhh the joys of floating point math. This just burned me about 6 months ago. I write a lot of extensive macros and never had a problem until I came to this new place. I was writing a C-bore macro and the data would show equal to each other when viewing the variable settings but it would not jump out of the loop of the macro. An example of what Eurisko is referring to is:
I was using #2 as a counter but this counter was adding the pick. And at the end the last pick could be any amount past the decimal 0.xxxxxxxxxx. I set #1 as a hard number for #2 to be equal to and end.

#1=2.
N1
IF[#2GE#1]GOTO100
…
…
#2=#2+.039
GOTO1
N100M30

My problem was that even though #2 would read 2. It was actually 1.999999999999999 so it never jumped out of the loop until the next pass. So the fix was to add a rounding function in the program. This would round the 1.99xxx number to the placement that I wanted which was .xxxx

#25=10000(ROUNDING)
#1=2.
N1
IF[ROUND[[#2*#25]/#25]GE#1]GOTO100
…
…
#2=#2+.039
GOTO1
N100M30

(these numbers are just examples they don’t actually add up to the 1.9)

Stevo

[Maxter]

I'm fairly new here and just now am reading up on all these great old posts. Stevo your comments on floating point math was most interesting! I've scratched my head in the past over the same thing until I figured out what was going on. Your number manipulation with the Round function shows how programming can circumnavigate any function limitation. I did notice that you had your delimiters in the wrong place. I think you ment IF[[ROUND[#2*#25]]/#25GE#1]GOTO100

My solution wasn't quite as elegant as yours but worked for me. If I wanted 50 passes in this example I would use a DOC of .04 (2/50=.040) I would add .001 to the target in #1:

#1=2.001
N1
...
...
#2=#2+.04
IF[#2LT#1]GOTO1
M30

If I wanted a .01 finish pass I would use #2=.0398 (*50=1.99)
and program in the finish pass between the GOTO and M30

[sinha_nsit]

This is one thing I hate about Fanuc, and possibly all other controls.
They do not differentiate between a real-number variable and an integer variable.
How can a programming language be so indisciplined!

In the given situation, instead of verifying equality between two variables, one can check if the abs value of difference is smaller than a "small" number. The other way has already been suggested (add a small value and FIX it).

[gravy]

I am still adding 1, or 2, or 5 to numbers and using them in loops, like in...


G55 X#[#101] Y#[#102]
#101=#101+3.
#102=#102+3.
X#[#101] Y#[#102]

to use the I and J variables since I J K I J K equals #4 #5 #6 #7 #8 #9.

I use GE, LE, or FIX if variables actually are numbers the machine goes to, depths, etc., if they are not whole numbers, yadda, yadda. I tend to trust counters, flags, etc.

I don't use my macros a WHOLE lot. BUT the company is needing some made which will see more extensive use.

So I ask again, is adding and subtracting integers for use in logic going to give me problems with floating point math?

I have an engraving macro which engraves a six digit number and a decimal. It checked for the leftmost number, engraved it, subtracted 900,000 if it was a nine, 800,000 if it was an eight, etc., then multiplied by 10 and looped back. It ALWAYS wrote an endless number on the right side of the decimal point without FIX ing the number each time. By the time I had done this six times, it was never just zero left. Still, this is big numbers, many operations, etc..

[sinha_nsit]

Floating point maths does cause problem sometimes.
Can use ROUND function ('rounds' to nearest integer) to eliminate erroneous digits.
Note, however, that the result is still stored as a real number with zeroes after decimal.