Re: gcode comments

Matt,

Thank you for your response! Gcode, like any 'language', is
constantly evolving. Ever try to read Chaucers' Canterbury Tales in
the ORIGINAL middle english? Some parts don't even LOOK like english
words...

G70,71 could easily be added to the interpreter code. They are not as
much used anymore, and if the typical gcode cycle repeats itself,
will eventually be "claimed" for some other advanced usage.

>It's G20, G21 in the EMC's interpreter. Should G70/71 be added?

>> And IF a code is already being used generally, let's USE THAT CODE!
>> Why G38.2 for probing in EMC? G38 is 'typically' used
>> for "specialized feature" probing routines. Is this what EMC's
>> 38.2 does? NO.

>What G-code should be used, and how should it work?

I have not followed the EMC development closely for the last few
months. The last time I talked to the fellows at NIST, thay seemed to
not care whether what they were doing fit "commercial" standards, and
stated that "no one can keep everyone happy, so why try?!" This is
the type of thinking which has LED to the Gcode 'flavors' in the
first place. Totally turned me off...

The answer depends on "exactly what" the 'probing routine' is doing.
If it is a simple "go until switch is detected", it should be G31. If
it is a tool or pocket detection routine, it could fall into a few
other categories, ONE of which IS G38. Point is, a probing "routine"
is different than probing "support". If you provide details of how
the CURRENT G38.2 works(I have gotten into trouble with RayH and JonE
for assuming things in EMC are 'still' the way they 'useta' be!), I
will search for compatible codes, and you could lobby for something
in-line with what's already 'out there'.

>Although the EMC doesn't have G28, I thought that its function was
>just to send an axis to its home position, not initiate a homing
>operation (slow seek, hit the switch, find the index pulse, etc.).
><snip>Should we add G28, and what should it do?

Yes, it is a "goto" home, NOT an "establish" home. Controls I have
seen which support 'programmed' homing use M codes. I am surprised
that NIST doesn't have an "in-process" establish home command, since
their project is based on automating the entire manufacturing process.

G28 is a 'constructed' one or two line linear interp move from
current position to the home point. G28XYZ will go to home position
in all "named" axes in a straight line. G28 x4.5 will go to x4.5
FIRST, THEN on to home position. Y and Z will not move, since they
are un-"named" in the G28 command. This should be enough info to
implement G28.

HERE is a place where I think we could "add" to the gcode.
G28.1 "could" mean: Proceed as if doing a G28, but when we get
to 'home', CHECK to see if we're really there!
G28.2 "could" be: Proceed as if G28, but perform a homing operation
when we get there, to ESTABLISH a new home.
This would be useful for someone who "suspects" his stepper machine
has 'slipped'...

Of course, If research shows that this sort of thing is already being
widely done with M codes; We should implement THAT instead, IMO.

I think it always has, and always will, be a case of 'maintaining'
the backward compatibility, WHILE 'pushing' the forward approach. At
some point(assuming the forward approach IS being adopted),
the 'backward' compat is dropped, and the Forward approach becomes
the new standard. The process then repeats. And niche
marketers 'spring up' to support those who want to stay in the "old
ways". Think vinyl records, CDs, Vidtapes, DVDs.

>> I really hope EMC becomes THE standard
>Me too, but I need a list of proposed changes before I can lobby for
>them! Matt

I have some knowledge in this area, but am certainly not an expert on
all controls... I created my Gcodes egroup to "pull together" this
osrt of info, with the hope of unifying Gcode implementations INTO
the greatest common denominator. And creating in the process, a
resource for those who are, or will write the next cnc controls...

Hope this helps.

Ballendo