Re: [CAD_CAM_EDM_DRO] Re: G92 was Re: another EMC Glitch?

Ray Henry wrote:

> 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.

Well, G92 is pretty important. Some companies have fixtures that sit on a machine
for years without being moved. When the machine operator comes in and powers
the control on, he homes the machine. The G92 offset is read in from the
emc.var file (equivalent of parameter storage on dedicated CNC controls)
and the reference position of the fixture is automatically set as the offset
from home. So, the operator doesn't have to spend 15 minutes fiddling with
dial test indicators, coax indicators, edge finders, or whatever.

The G55-59 offsets can be used to hold the offsets to multiple parts held in a
multi-part fixture, so the same program can be run on the multiple parts.

The G92 is cleared by an F6, so I am careful to never hit that. It probably
should ask before clearing the offsets, though.

> 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.

I simply DON'T CARE what any manual says! AND, I will tell you that there
is ONLY one way to change these on many controls. Either the program or
the user in MDI commands them to change. I can categorically state that
NOTHING, including powering off and back on, will clear the G92 offset
in an Allen-Bradley 7320 control. (Reloading the executive or powering off
the memory backup battery will clear it, of course.) You can change it
explicitly, of course.

Anyway, if this becomes standard behavior for EMC, I will either fix it myself,
or stop using (new versions of) EMC, as it will make it completely impossible
for me to do a 2nd part.

> 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.

Unfortunately, NCMS is not alive. The group disbanded after failing to complete
the document that Tom Kramer based a lot of his work on. The problem is that
Tom was not a machinist, and didn't understand the implications of some
features, and how they were used.

I have the last draft of "Part Programming Functional Specification" which is
blatantly copied from an Allen-Bradley document with scribbled notes all over
the thing. Some pages are almost hyserical in their confused alterations of some
hyper-obscure AB special feature that should have never been in this basic
document at all.

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

Well, maybe in some systems. In others, it is the ONLY offset, if you don't use
it, then HOME is 0,0,0, and everything will just have to be measured directly
from home! That would be REALLY painful!

> 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.

Well, maybe I just have to retrain myself, then. I didn't need to retrain myself
on this function, as EMC did it exactly the way my A-B 7320 did it. But, maybe
that was the old way.

> 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.

OK, well, I have to think about the implications of this a bit.

Jon