Equation format in g-code

[Jester966]

Here are a few lines from a macro I'm trying to write, but I'm not sure of the correct formatting/syntax for doing equations in g-code. Can someone help me out? I'm trying to simulate it on "Torcomp CNCez Pro" for a Hass controller.

N100 #4 = [COS[#1]]* [#18 + [#7 / 2]] + [#24] (FIND X POS)
N110 #6 = [SIN[#1]] * [#18 + [#7 / 2]] + [#26 - [#7/2]] (FIND Z POS)
...
N150 G02 I-[#4 - #24] F#9
...
N170 IF [#6 NE #26] GOTO100
N180 G00 Z[#26 + #18 + #11]

Thanks for the help.
-Chris

[gar]

070706-1145 EST USA

Jester966:

Define your variables and the intent of the program.

I do not see anything in your N100 loop to modify #6 or #26. Therefore, you are in a continuous loop (infinite) or you pass thru the loop once.

.

[lerman]

I assume that the areas indicated by "..." include modification of #6 or #26.

In general, it is unwise to compare for EQ because of roundoff error. Instead, compare LE, LT, GE, or GT, depending on what you need.

It appears that #7 represents the diameter of a cutter, and #18 represents the radius of a circle. Then #1 represents an angle.

I see no problems with your formatting.

Ken

[Jester966]

lerman, you're right on all of your assumptions. Thanks for the EQ tip, I'll change it.

I used the Hass programming manual to try to get the format correct, but had no luck. Could the problem be with the simulator's interpretation, rather than the code? I guess I'll try to simulate it on the control itself and see if it works.

Thanks for the help.

-Chris

[Stu_M3]

I always use variables #100 onward as good practice some of the lower variables can change depending what other stuff you are doing ie if you are doing G65 calls in the same programe which use #1 #2 etc


Stu.

[gar]

070709-0810 EST USA

Stu M3:

I believe the use of the word "MACRO" was used in place of a more correct term "subroutine".

Thus, I expect that Jester966 wants to pass parameters into a subroutine from a G65 call. He has shown segments of that subroutine. So #1 maps from A in the subroutine calling line, #18 from R, #7 from D, #24 from X, and #26 from Z. #4 and #6 are probably local to the subroutine and a don't care on return from the subroutine.

However, if another G65 subroutine (second subroutine) is called from this first subroutine and any of the local variables are used in the second subroutine, then on return to the first subroutine the local variables as viewed in the first subroutine will remain unchanged from their values before the call to the second subroutine. I suspect this is because the local variables are actually stored on a stack.

See my post #2 at http://www.cnczone.com/forums/showthread.php?t=32630 for some information on local variables in a HAAS machine.

.