Re: Re:Gcode
Posted by
ballendo@y...
on 2000-09-03 20:13:39 UTC
Hugh,
Answers interspersed below, snips where apropo
the UNINVOLVED AXIS to determine CW,CCW.
frustrating. And the reason the example uses 0,0,0. The answer to
your first sentence is ...YES! Depends on the control, the parameter
settings, the phase of the moon, etc.
But really, the IJK are "usually" the SIGNED distances "from" the
START POINT "to" the ARC CENTER. Set up in the system parameters. Now
that I've said that, I will warn you, FIND OUT WHAT YOUR CONTROL DOES!
some are unsigned. some are using a code like 90.1 to mean absolute
coords, EXCEPT IJK which will be relative. Very confusing, especially
if you are running several MFR's systems. Makes for some spectacular
crashes when the FANUC guy uses the YASNAC system!
lot of stuff in these examples to show things besides the arcs. Sorta
let it soak, then, oh! that's why he did that! (I hope)
from cosys zero or current position(as referred to above)) The
uninvolved(in the arc) axis will make either no move or a linear
move, depending on its value and the mode(G90 or G91)set. In G90, xy
plane(G17),starting from 0,0,0 any Z value other than 0 (in a G02 or
G03)will cause a helical move in controls supporting it, and an
error/alarm in other controls.
In other words,the center location of a helical move is still ON the
plane selected for arcs, and specified by IJ,JK,IK. But the END point
can be OFF the plane IF the uninvolved(in the arc) axis is programmed
to move.
values until it makes sense; then venture to the other planes. For
example:
G90G20G17G40G80 (safety block,sets the machine in a known state)
G0x0y0z0 (we know why!)
G02x0y0z-1. (a helical 360 degrees,moving down 1 inch)
IMPORTANT NOTE: See that decimal point after the one? For MOST
commercial controls, leaving it off will result in a move down (in
the example given) of .001 or .0001 ! I have been using PC based
controls for so long now that I sometimes forget how important that
decimal point is! CNC controls NEED the decimal point to know you
want to move one whole unit! This dates from when all controls were
programmed with leading and/or trailing zeros so the control did not
need to do floating point math. Since there are still a lot of old
machines out there, modern control MFR's use the decimal point to
determine which mode of coord entry is being used! VERY COMMON
BEGINNER MISTAKE TO LEAVE THESE DECIMAL POINTS OFF WHOLE NUMBERS!!!
(insert more spectacular crashes here)
Many PC based controls ASSUME floating point, just as their ancestors
ASSUMED fixed point. Someone pointed this out to me (off-list)
yesterday so I wanted to clear that up. WHEW! So, Know Your Control.
are garbage. Same goes for most control manuals. The HAAS programming
manual is the best of the ones I've seen. No, I don't work for HAAS,
and we don't even have one, but the book is good. Of the rest, Mike
Lynch has two books ( and an online site,CNC concepts, I think; try a
search of Mike Lynch CNC) which I think are very clear.
Yes, EMC is relatively standard (actually,VERY standard in the common
codes, most of their GXX.X codes are unusual.
Also very complete, getting more completer, all the time. :)
a single-v or threadmill (program the helix)is FUN, and can get you
out of some sticky situations.
Ballendo
Answers interspersed below, snips where apropo
>I'm sorry but I'm still a little confused about the recentYes. Right hand Rule. Look at the arc FROM the positive direction of
>discussions of
>g02 and g03. Would someone kindly let me know if I'm understanding
>correctly. So:
>So g90/g91 absolute/relative and fx for feed rate. Then g17/g18/g19
>for the plane to be used as XY/XZ/YZ. Also, the first point on the
>arc is the current location of the cutter, above set to 0,0,0. OK.
>Now, g02 is a clockwise arc. Are clockwise and counterclockwise
>(g03)defined by the third axis, here +Y, in terms of a right handed
>coord.system? (Counterclockwise positive) This would seem logical.
the UNINVOLVED AXIS to determine CW,CCW.
>Then in specifying the above g02 move the final point x10/z10 andYes.
>the center point x5/k5 have no Y specified so the start, end and
>center are in the same XZ plane. This should create a circular arc
>in that plane.
>Are the inputs X/Z and I/K absolute or from the start point? DoYou've hit the main reason people find this whole IJK thing
>either depend on the g90/g91 specified? I can't tell with the start
>point at 0,0,0.
frustrating. And the reason the example uses 0,0,0. The answer to
your first sentence is ...YES! Depends on the control, the parameter
settings, the phase of the moon, etc.
But really, the IJK are "usually" the SIGNED distances "from" the
START POINT "to" the ARC CENTER. Set up in the system parameters. Now
that I've said that, I will warn you, FIND OUT WHAT YOUR CONTROL DOES!
some are unsigned. some are using a code like 90.1 to mean absolute
coords, EXCEPT IJK which will be relative. Very confusing, especially
if you are running several MFR's systems. Makes for some spectacular
crashes when the FANUC guy uses the YASNAC system!
>But then for:G's)
>G0 xoyozo (caps doesn't matter)
>G90g20G18 (spaces don't either,but some ctrls wld not allow multi
>g01F25 (set 25 InchesPerMinute, is modal so not needed next line)<snip>
>G03 x2y0z0 I1 K-.25 (this will take ballmill to x2, max 1/4inch deep)
>For this move the same parameters are set (absolute/feed) and aThe Y0 is useless, extra code. Put there to show you could. I put a
>plane specified XZ. However, the parameters in the g03 code have
>X/Y/Z and I/K set.
lot of stuff in these examples to show things besides the arcs. Sorta
let it soak, then, oh! that's why he did that! (I hope)
>I ran a couple of variants of this in EMC (no hardwareCorrect. See my next comment.
>connected). It seems to not allow a center point off the plane
>specified by g17/g18/g19 and the start point. The above code is OK
>in not specifying a J for center location. In fact EMC won't allow
>entering a J in the above.
>However, EMC allows an end point off this plane. A move like:Yes, and no. The center location is defined ONLY by IJK.(referenced
> g03 x2y1z0 i1 k-.25
>is allowed. But this doesn't look like an arc but a helix. It
>looks like an arc in the XZ plane with a linear move in the Y. If
>this is true, the center location really locates an out-of-plane
>axis (here the plane being XZ so the axis is in the Y).
>Is this right?
from cosys zero or current position(as referred to above)) The
uninvolved(in the arc) axis will make either no move or a linear
move, depending on its value and the mode(G90 or G91)set. In G90, xy
plane(G17),starting from 0,0,0 any Z value other than 0 (in a G02 or
G03)will cause a helical move in controls supporting it, and an
error/alarm in other controls.
In other words,the center location of a helical move is still ON the
plane selected for arcs, and specified by IJ,JK,IK. But the END point
can be OFF the plane IF the uninvolved(in the arc) axis is programmed
to move.
>Finally:Yes. Let me suggest you stick with the XY plane and try different Z
>A helical cut is very useful when milling. Means you dont try to
>"drill" with an endmill designed for side cutting. MUCH less strain
>on your machine!
>Is the above how to get a helical cut?
values until it makes sense; then venture to the other planes. For
example:
G90G20G17G40G80 (safety block,sets the machine in a known state)
G0x0y0z0 (we know why!)
G02x0y0z-1. (a helical 360 degrees,moving down 1 inch)
IMPORTANT NOTE: See that decimal point after the one? For MOST
commercial controls, leaving it off will result in a move down (in
the example given) of .001 or .0001 ! I have been using PC based
controls for so long now that I sometimes forget how important that
decimal point is! CNC controls NEED the decimal point to know you
want to move one whole unit! This dates from when all controls were
programmed with leading and/or trailing zeros so the control did not
need to do floating point math. Since there are still a lot of old
machines out there, modern control MFR's use the decimal point to
determine which mode of coord entry is being used! VERY COMMON
BEGINNER MISTAKE TO LEAVE THESE DECIMAL POINTS OFF WHOLE NUMBERS!!!
(insert more spectacular crashes here)
Many PC based controls ASSUME floating point, just as their ancestors
ASSUMED fixed point. Someone pointed this out to me (off-list)
yesterday so I wanted to clear that up. WHEW! So, Know Your Control.
>Can anyone indicate a good reference to learn this from? Or wouldI think I have every current book (and a LOT of old ones too). Most
>it be as useful to just try different codes in EMC? Is EMC
>reasonably standard and complete?
are garbage. Same goes for most control manuals. The HAAS programming
manual is the best of the ones I've seen. No, I don't work for HAAS,
and we don't even have one, but the book is good. Of the rest, Mike
Lynch has two books ( and an online site,CNC concepts, I think; try a
search of Mike Lynch CNC) which I think are very clear.
Yes, EMC is relatively standard (actually,VERY standard in the common
codes, most of their GXX.X codes are unusual.
Also very complete, getting more completer, all the time. :)
>Eh, chances are I'll not need these but then again a helical wouldChange useful to necessary and you've got it. Also,tapping holes with
>be very useful for plunge cutting, etc.
a single-v or threadmill (program the helix)is FUN, and can get you
out of some sticky situations.
>Thank you.You're welcome. This was a long post.
Ballendo
Discussion Thread
ballendo@y...
2000-09-02 14:30:30 UTC
Re:Gcode
Alan Marconett KM6VV
2000-09-02 16:20:48 UTC
Re:Gcode
ballendo@y...
2000-09-02 17:55:53 UTC
Re:Gcode
Alan Marconett KM6VV
2000-09-02 22:13:41 UTC
Re:Gcode
ballendo@y...
2000-09-02 22:53:04 UTC
Re:Gcode
Alan Marconett KM6VV
2000-09-03 14:44:39 UTC
Re:Gcode
Hugh Currin
2000-09-03 14:46:07 UTC
Re: [CAD_CAM_EDM_DRO] Re:Gcode
Alan Marconett KM6VV
2000-09-03 15:01:42 UTC
Re:Gcode
ballendo@y...
2000-09-03 18:43:47 UTC
Re:Gcode
ballendo@y...
2000-09-03 18:51:19 UTC
Re:Gcode
ballendo@y...
2000-09-03 20:13:39 UTC
Re: Re:Gcode
Gene
2002-06-05 13:47:36 UTC
Gcode
James Stevens
2002-06-05 14:03:16 UTC
Re: [CAD_CAM_EDM_DRO] Gcode
Jon Elson
2002-06-05 16:55:17 UTC
Re: [CAD_CAM_EDM_DRO] Gcode
bjammin@i...
2002-06-06 04:37:12 UTC
Re: [CAD_CAM_EDM_DRO] Gcode
robert charles weiss
2002-06-06 14:48:06 UTC
Re: [CAD_CAM_EDM_DRO] Gcode
andrewyslee
2002-06-06 18:04:10 UTC
Re: Gcode
doug98105
2002-06-06 20:10:36 UTC
Re: Gcode
Jon Elson
2002-06-06 22:26:10 UTC
Re: [CAD_CAM_EDM_DRO] Re: Gcode
remy
2003-11-13 15:58:21 UTC
Gcode
Torsten
2003-11-13 17:43:24 UTC
Re: Gcode