Re: G92 was Re: another EMC Glitch?

This g92 is pretty mystical stuff to me. That's why I wrote the little
script that helps you manage the normal coordinate offset systems. It really
is almost as easy to use as g92 and it's a whole lot more certain and a whole
lot more flexible.

I think that there is a lot of mis-application of g92. I also think that
there is a problem because the values inserted in the g92 variables is not
instantly written to the var file and then the var file re-read into the emc.

First things first. Let me start out with where I think the biggest nail has
been hit on the head. Jon E did it.

>    From: Jon Elson <elson@...>
> Subject: Re: another EMC Glitch?

<s>

> Another time, I plunged a 1/8" solid carbide end mill into 1/8" aluminum,
> and then started milling at 45 IPM.  That time I had just forgot to do a
> G92 for the Z axis, so the program thought it was clear of the work.

I think that we can attribute a lot of g92 problems to operator error. It
would also be interesting to compare a listing of how 20 users think that
g92, g92.1, g92.2, and g92.3 and those popup boxes with axis offsets ought to
work. I'd bet there'd be four different mutually exclusive sets.

G92, and I did not write about it in the handbook on purpose, is, in part,
the bastard child of a project that attempted to allow you to bolt a casting
anywhere on a machine and have the program locate it using a group of probe
points and then orient the program to that location and mill a perfect part.
IMO this is another of those "Yea Right" notions that I tend to discount.

That is not to say that part zero is not an extremely useful concept. I
still remember the first time I encountered a lathe that had it. Before that
I always had to include the distance from home in every motion or use
incremental moves which can be a mess after a while. But g92 and part zero
are NOT the same thing.

It is NOT a glitch that g92 offsets are reset to zero when a program ends
NORMALLY. Now we can futz around all day inventing ways to get around their
going away, but g92's offsets were never intended to persist. Let me quote
from a couple of comments in the code file named
emc/src/rs274ngc_new/rs274ngc_pre.cc itself.

"This handles stopping or ending the program (m0, m1, m2, m30, m60)

"[NCMS] specifies how the following modes should be reset at m2 or
m30. The descriptions are not collected in one place, so this list
may be incomplete.

"G92 coordinate offset using tool position [NCMS, page 10]
...
"The following resets have been added by calling the appropriate
canonical machining command and/or by resetting interpreter
settings. They occur on M2 or M30.

1. Axis offsets are set to zero (like g92.2) and origin offsets are set to
the default (like G54)
..."

So your next question is who the &&^%$# is NCMS. Well it's one of those
standards groups that purports to speak toward standardizing the language of
machining. When Tom Kramer wrote the interpreters used by the EMC, he
carefully studied the existing standards as well as best practice of folk
like Fanuc and AB. You will constantly find references like these throughout
his code.

Let me repeat, g92 is a temporary offset. It is not intended to work from
one run of a program to the next.

But as Bill Scalione notes, the first interpreter written by Tom is not the
same as the second.

>    From: "William Scalione" <wscalione@...>
> Subject: Re: another EMC Glitch?

<s>

> I always used M02 to end the program and on the old versions
> of EMC the offsets never went away at the end of the program.
> By old versions I mean the ones that ran under RH 5.2 Then the
> glitch got somehow worked into it after it was ported to RH 6.0.
> I don't think the port to 6.0 did it, but it showed up sometime after
> that.
> I did some experimenting on my system and using M02 to end
> the program would ALWAYS result in the offsets being lost, but at
> least the gui reflects it with everything going back to zero. Once
> I left the M02 off the end of the program, it worked the way I thought
> it should work. by remembering the offsets. Ray tells me that this
> is the way it is supposed to work, but I'm sure that the old versions
> worked differently. Try an M02 and see if there is a difference when
> you do your experimenting.

It is a part of the new six axis interpreter.

>    From: Jon Elson <elson@...>
> Subject: Re: another EMC Glitch?

<s>

> Well, it doesn't matter the "way it is supposed to work".  What matters is
> that it destroys information that is hard to reproduce, ie. it makes you
> re-zero the machine at the reference location for every part.  This is a
> disaster, and just by itself, it makes me stay with my 1999 version.

A disaster only in that someone thinks it ought to work one way but it
doesn't. I've trashed a lot of stuff because I thought I knew how it ought
to work and didn't need to read the manual. <g>

Jon E also says that he continues to use the old RH5.2 stuff. In part it is
because he likes the old interpreter -- and that's okay. Now if he took the
time, he could set the BDI to use the old interpreter just as well as it uses
the new. It's in there along with a zillion other options. But why should he
when he's found a control that he likes. Hell, if shops swapped out old
controls everytime a new one came along we'd all be confused, be makin bad
parts, and be broke to boot.

In the quote below, Tom Kramer explains how he thinks you ought to use g92
offsets in subsequent programs.

"You can set axis offsets in one program and use the same offsets in another
program. Program G92 in the first program. This will set parameters 5211 to
5216. Do not use G92.1 in the remainder of the first program. The parameter
values will be saved when the first program exits and restored when the
second one starts up. Use G92.3 near the beginning of the second program.
That will restore the offsets saved in the first program. If other programs
are to run between the the program that sets the offsets and the one that
restores them, make a copy of the parameter file written by the first program
and use it as the parameter file for the second program. "

And that sounds really simple. And at one level it is. If you start clean
-- no axis offsets of any kind out there in the var file. Then jog your
machine to the place where you think it ought to start -- call it part zero
if you will. Now go to mdi and issue g92 x0 y0 z0 a0 b0 c0 and all six
parameter settings will be changed to reflect the difference between the
current location and machine zero. They will in point of fact contain the
negitive of current machine location.

Part of the problem is that those values do not get instantly written into
the active var file. And while they are not in there, you can loose them
because of a reset or an error. In fact any time the EMC re-reads the var
file and they aren't in there yet, they are long gone. Some errors that
cause the control to fault out will also erase these values as will a reset.
(I will attempt to see to it that we get this instant write to var and
re-read going so that these things always behave like the writeup says they
should.)

There is a second kind of problem that has to do with the persistence of
these offsets. If g92 offsets are in that there var file, they will be read
in when the program restarts. A problem might develop if I startup my mill
with values in the g92 variables and home it out. If I don't look up there
and see an offset, and just start doing something like commanding a z -8 to
get down there 1 inch above my part and don't realize that I've already got
an offset down 5 inches I'll be drillin and millin stuff that I really didn't
plan to.

That's why I like g54-59.3. I can see them. I don't have to erase or set or
re-set zeros in order not to use them and all I have to do to use one is put
a g54 in my program, call up the script Set_Coordinates and touch off and
teach each of the axes that I have and go.

Now suppose I was cleaning up the first side of a bunch of castings and one
of them was short by a bit and didn't quite clean up. I could re-teach g54
or I could change tool length but both of these changes would affect all of
the castings after this short one. This is where I'd use g92 and expect it
to go away when the program ends.

It's at this point that we should remember Les' post.

>    From: "Les Watts" <leswatts@...>

<s>

> When I am doing these wood signs each one is a different thickness so
> I have to re offset. When I do a batch the same thickness I will try
> ending with a % or M00. I use M00 quite effectively for a tool change.
> I just hit resume to continue.

IMHO what Les should do is set a general offset to part zero using g54 and
then when he has moved to that zero location jog down to where he really
wants the surface of the sign and set g92 knowing that it will go away and he
will be safe to set it again on the next run. Then when he gets a whole
batch the same thickness set g54 to that part zero and just run it.

BTW a % in the first line of a part program trashes both the highlighted line
in the tkemc window and the color of lines in the backplotter.

HTH

Ray