Need Help!- Am I stupid or is my mill stupid?

[Ceramic Man]

Stupid question- machines do as they're told... or do they?
I can't figure this out and its probably something simple.
I have just upgraded my centroid M-50 control's PC so I could run version 8.21 of the control software which allows full advanced macro that I didn't have before. I'm very familiar with macro on Haas, but am still figuring out the little syntax quirks on the centroid.
Here's the problem in the program (only relevent lines shown):

#110=-.138 ; Target depth
#103=.015 ; rough step-down
;
#110=ABS[#110] ; set #110 to positive value
#111=[(#110/#103)-(#110MOD#103)] ; # of rough steps

At this point, #111 should be a whole number representing the number of loops to step down for a subroutine. BUT, the control returns a "divide by 0" error on the line setting #111. How is .015 a 0?!!? I don't get it.
I've tried using a different variable #, getting rid of the mod statement, getting rid of the division statement etc. This thing really just wont divide by .015!
And BTW- the parameter for floating point error is set to ignore past 6 decimal places and the floating point error never seems to be less than 8 places. (Default is no floating point correction)

PLEASE HELP before I punch this thing!
Also, if anybody knows if there's a way to view the value of variables or get to some kind of table that shows them, that would be very helpful as I cannot find anything about that in the software manual.

[beege]

Not absolutely sure what the MOD does, but if it removes the integer, then:

111=[(#110/#103)-(MOD(#110/#103)1)]

Would this work? or something like it?

What about INT(#110/#103)?

[HuFlungDung]

MOD determines the remainder, right?

(#110-MOD(#110/#103))/#103 should give an integer. I'm just guessing, I don't have anything handy to run the expression through to see what the computer thinks of it. After all it always looks right until you try it and it won't run!

I'm not sure of the syntax for MOD, maybe this would be better:

(#110-(#110MOD#103))/#103

[ChattaMan]

I don't know about your Centroid control but with Fanuc everything in
parenethesis () is ignored. All maths functions have to be in square brackets []

[Ceramic Man]

The Centroid manual describes MOD as being used just like the / division sign but it returns only the remainder without the integer.
This is the only function the manual shows that could be used to deal with remainders. I don't see anything like ROUND or INT although I really wish these were available.
On the Centroid control, [] brackets are used to specify a whole main function (like Haas) and () parentheses are used within brackets to deliminate priority of calculation- just like standard mathematics.

Again, the problem is not with the MOD statement. If I get rid of it and just try to divide #110/#103, it still returns a divide by 0.
Since my first post I even tried making #103=15 and then multiplying the result by 1000. IT STILL GIVES THE ERROR! I just don't get it!

[SBC Cycle]

You might be better off with an IF - THEN catch here. I assume you want to stop short of your target depth.

The way you are doing it is certainly more elegant but simplicity may be the key here.

[SBC Cycle]

I just reread your last post. "The Centroid manual describes MOD as being used just like the / division sign but it returns only the remainder without the integer".

A modulo operation should always return an integer.

Example 9 mod 4 should return 1 not 0.111111111 (1/9)

I can't be certain how the control would handle using the MOD function with real numbers.

[HuFlungDung]

#111=[(#110/#103)-(#110MOD#103)] ; # of rough steps

Maybe the control just doesn't like your naked # symbol in the comment and the "divide by zero" error is simply something "undefined" which is the same thing as divide by zero.

It wouldn't be the first time that a controller did not ignore what was in the comments

[Ceramic Man]

Originally Posted by SBC Cycle I just reread your last post. "The Centroid manual describes MOD as being used just like the / division sign but it returns only the remainder without the integer". A modulo operation should always return an integer. Example 9 mod 4 should return 1 not 0.111111111 (1/9) I can't be certain how the control would handle using the MOD function with real numbers.

Wikipedia disagrees: http://en.wikipedia.org/wiki/Modulo_operation

I like your idea with the IF-THEN, but I need to calculate the number of loops and possible remainder before it starts the subroutine so that it can start at a calculated depth (in this case between 0 and .015 should start at Z-.003). Example: Z-.138= -.003 - (9x.015). That way it will always hit the target depth on the last pass. This is part of a macro routine that will always be recieving different values and I want IT to be able to do this for me because I know it CAN. If I have to bust out the calculator every time, then whats the point?

REMEMBER: I said that it just thinks #103=0 --- I can get rid of the MOD statement leaving #111=#110/#103 only and it still gives me the error.
THAT IS THE PROBLEM ALL MODULO's ASIDE
But really, I appreciate everybody's input.

[Ceramic Man]

Originally Posted by HuFlungDung Maybe the control just doesn't like your naked # symbol in the comment and the "divide by zero" error is simply something "undefined" which is the same thing as divide by zero. It wouldn't be the first time that a controller did not ignore what was in the comments

Good call, I'll try getting rid of the comment tomorrow and see if it works.
"Keep it simple, stupid" is always good advise.

[James L]

I set up this part on my HAAS machine :
#110 = -.138;
#103 = 0.015;
#110 = ABS[#110];
#111=[[#110]/[#103]];
........
and it ran without error.
I had issues only when using the MOD statement.
I copied and pasted your original posting and got the same error as you did before trying it like this.

I typed this line into MDI and got the divide by zero answer too
#110 = .138;
#103 = .015;
#111 = [#110 MOD #103];

This did not give an error with:
#110 =138 and
#103 =1.5

The issue here is having a number too small for MOD to work with. The If Then statement may be your best bet, to contain an option to make the number larger in multiples of 10 pre-MOD and then dividing by multiples of 10 accordingly afterward. The idea here is to keep the Remainder large enough for your control to recognize it or it will return an error.

[Ceramic Man]

Ok, I figured out the problem and it was as simple and stupid as I originally thought!

The problem was not with the math line.
None of the variables had been set, so #103 WAS 0 along with all the others. This is not to say that I didn't set them.
The Centroid control does not provide any way to view what the variables are set to or I would have known the problem the first time around.
Today I ran the program and got the error. Then I tried rapiding to X#103 and it moved to 0. When I set the variable in MDI and tried again from MDI, it moved to X.015. Hmmmmm...
Looked at the manual again and found that variables 100-199 are reset to zero whenever a new program (or subprogram) is loaded.
So, its as stupid as I thought- I was using variables that cannot be passed to a called subroutine.

To help clear up the MOD issue: Some controls (and compilers when programming BASIC) will only accept Integers in a MOD statement, and some will accept real numbers (according to Wikipedia). My centroid control accepts only INTEGERS so I must do this (roughly):
#110=#110*10000 ---> these lines make any values entered non-decimal values
#103=#103*10000 --^
#112=[(#110MOD#103)/10000] -----> performs the MOD with INTEGERS and then divides result back to ten-thousandths.
Now #112 is set to the correct start position so that the subroutine can step down by #103 the calculated number of times and end up at #110 on the last pass. I tried it and it works.

Thanks for all the help!!