Re: [CAD_CAM_EDM_DRO] Re: G92
Posted by
Matt Shaver
on 2002-07-16 20:43:18 UTC
Here's my take on this:
I. G92 has changed from being completely "sticky" to being reset by M2 and
M30. (This is essentially the core of Tim & Jon's posts.)
This was caused by Tom Kramer's rigorous interpretation of a standard which
many people feel is irrelevent (they may be right), and which contradicts
"traditional" machine control behavior (they are almost certainly right about
this). The problem arises when G92 is used as the offset method to set "part
zero". After the first pass through the program, G92 is reset ,which causes a
crash on subsequent runs (or at least considerable operator consternation).
Some questions are:
1. When you use G92, do you:
A. right click on the axis display and set the axis value using the GUI?
or
B. enter the G92 command in MDI mode?
or
C. use G92 in your program code directly (this shouldn't be a problem)?
2. Other than the G92 problem, are there any other problems with the new
interpreter?
3. Other than interpreter problems, are there any reasons not to upgrade
from RH5.2 systems to BDI (RH6.2) systems?
Please post answers if you have time! Short pithy answers are fine! I said
P_I_T_H_Y, not ...
Some possible solutions are:
1. If the problem is only with situation "1A", we could change the GUIs to
use G54 (or whatever offset is in effect), rather than using G92.
2. If the problem is with situation "1B", we could add an ini file
parameter like G92_BEHAVIOR = TRADITIONAL or CONTEMPORARY so the user can
have it the way they want.
3. If there are other interpreter problems (situation "2") we could make it
easy to specify which interpreter you want to use, the old or the new (ini
parameter rather than recompiling).
4. If there are other OS problems (situation "3") we'll have to do some
more thinking... ;)
II. Les described some discrepancies which, if verified, are bugs and need
fixing. They sound pretty serious, especially the "offset in effect but not
displayed" one...
III. Joel agreed with Tim & Jon, plus, I think his "backlash value is added
to the home position every time you rehome an axis" bug is still in there as
well, which must add to his frustration (although I think he told me he
changed to ballscrews to get past this problem). Needless to say, this needs
to be fixed as well...
I've been putting a lot of hours in on a contract to help get a CD labeling
plant running smoothly, but I read the list every night.
Thanks,
Matt
I. G92 has changed from being completely "sticky" to being reset by M2 and
M30. (This is essentially the core of Tim & Jon's posts.)
This was caused by Tom Kramer's rigorous interpretation of a standard which
many people feel is irrelevent (they may be right), and which contradicts
"traditional" machine control behavior (they are almost certainly right about
this). The problem arises when G92 is used as the offset method to set "part
zero". After the first pass through the program, G92 is reset ,which causes a
crash on subsequent runs (or at least considerable operator consternation).
Some questions are:
1. When you use G92, do you:
A. right click on the axis display and set the axis value using the GUI?
or
B. enter the G92 command in MDI mode?
or
C. use G92 in your program code directly (this shouldn't be a problem)?
2. Other than the G92 problem, are there any other problems with the new
interpreter?
3. Other than interpreter problems, are there any reasons not to upgrade
from RH5.2 systems to BDI (RH6.2) systems?
Please post answers if you have time! Short pithy answers are fine! I said
P_I_T_H_Y, not ...
Some possible solutions are:
1. If the problem is only with situation "1A", we could change the GUIs to
use G54 (or whatever offset is in effect), rather than using G92.
2. If the problem is with situation "1B", we could add an ini file
parameter like G92_BEHAVIOR = TRADITIONAL or CONTEMPORARY so the user can
have it the way they want.
3. If there are other interpreter problems (situation "2") we could make it
easy to specify which interpreter you want to use, the old or the new (ini
parameter rather than recompiling).
4. If there are other OS problems (situation "3") we'll have to do some
more thinking... ;)
II. Les described some discrepancies which, if verified, are bugs and need
fixing. They sound pretty serious, especially the "offset in effect but not
displayed" one...
III. Joel agreed with Tim & Jon, plus, I think his "backlash value is added
to the home position every time you rehome an axis" bug is still in there as
well, which must add to his frustration (although I think he told me he
changed to ballscrews to get past this problem). Needless to say, this needs
to be fixed as well...
I've been putting a lot of hours in on a contract to help get a CD labeling
plant running smoothly, but I read the list every night.
Thanks,
Matt
Discussion Thread
Les Watts
2002-07-15 08:18:09 UTC
Re: [CAD_CAM_EDM_DRO] Re: G92
imserv1
2002-07-15 11:23:13 UTC
Re: G92
Ray Henry
2002-07-15 19:34:49 UTC
Re: Re: Re: G92
Ray Henry
2002-07-15 19:38:49 UTC
Re: Re: G92
Tim Goldstein
2002-07-15 23:03:28 UTC
RE: [CAD_CAM_EDM_DRO] G92
Les Watts
2002-07-16 09:05:22 UTC
Re: [CAD_CAM_EDM_DRO] G92
Ray Henry
2002-07-16 19:25:46 UTC
Re: Re: Re: G92
Ray Henry
2002-07-16 19:25:48 UTC
Re: RE: G92
Matt Shaver
2002-07-16 20:43:18 UTC
Re: [CAD_CAM_EDM_DRO] Re: G92
Jon Elson
2002-07-16 21:50:17 UTC
Re: [CAD_CAM_EDM_DRO] Re: G92
Jon Elson
2002-07-16 22:17:15 UTC
Re: [CAD_CAM_EDM_DRO] Re: G92
Joel Jacobs
2002-07-17 08:07:07 UTC
Re: [CAD_CAM_EDM_DRO] Re: G92
Tim Goldstein
2002-07-17 09:42:10 UTC
Re: [CAD_CAM_EDM_DRO] G92
Tim Goldstein
2002-07-17 09:46:13 UTC
Re: [CAD_CAM_EDM_DRO] G92
Jon Elson
2002-07-17 10:31:47 UTC
Re: [CAD_CAM_EDM_DRO] G92
Keith Rumley
2002-07-17 14:15:12 UTC
Re: [CAD_CAM_EDM_DRO] Re: G92
Matt Shaver
2002-07-17 21:07:46 UTC
EMC Bug List (was G92)
Ray Henry
2003-03-07 11:09:19 UTC
Re: Re: G92
pcfw
2003-03-07 16:54:39 UTC
Re: G92
Ray Henry
2003-03-08 09:42:46 UTC
Re: Re: G92