Re: gcode comments

Ray,

Lotta comments! (snips, inserts below)

>And it was intended for those days long gone when it was much harder
>to edit a part program than it is today. You could use (/) to write
>in stuff to test the program and then switch it out by turning on
>the ignore blocks that start with (/) switch.

Block skip is for much more than "skipping" 'test code! It's pretty
darn useful,IMO...

>All we would need to do is use a software switch in tkemc and we
>could reinvent the old skip block feature.
>IMO Putting the (/) elsewhere in the line would trip me up 9 times
>outa 10.

I hope you do implement this. Please DO allow (but that would be
TomK's job) "/" in the middle of a block. Did you see my examples?
More are in Michael Lynch's EXCELLENT CNC books... Search on CNC
concepts.

>I also have a real difficult time when Ballendo reminds me that EMC's
>g-code is a variant. Damn if I didn't grow up on AB and GE controls
>when they were the only folk building controls and most of the stuff
>in RS274NGC is common to both.<snip>

It IS a variant! This is like saying that we should use Wordstar
editing commands since they 'used to be' the only ones... CPM is a
lot like DOS, WANNA GO BACK?!?

What I keep pushing is to RESPECT the MARKETPLACE 'evolved' standards
when writing new stuff... This is AT LEAST as important as 'backward
compatibility' ,which most people agree is useful. What I'm pushing
is 'forward compatibility'! Example: G20,G21 are COMMONLY used
nowadays for inch/mm programming. Used to be G70,G71. For now I think
we should be 'backward compatible to 70 and 71, BUT we should also
support 20 and 21... There are LOTS of other examples!

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.

>Seems to me EMC's language is a minimallist and others
>with "frills" are the variants. Hope we all come to terms with this
>difference before the book or at least in a footnote to the relevant
>chapter.

EMC is not minimalist, IMO. And it has frills, just like the other
variants... See g38.2 above
I too hope that the people working writing controls nowadays will
work to come TOGETHER, instead of continuing the separation. We've
already spent enough list time discussing WHY 'they' do it, but we'd
all benefit if the Gcode WAS standard, WHERE it CAN BE standard!

>I still consider a home command to be a frill. You notice how many
>ways to get home that have recently been suggested here<snip>

There is a BIG difference between going TO A PREVIOUSLY ESTABLISHED
zero (home); and EXECUTING A HOMING OPERATION! Having the ability
to 'establish home' in the middle of a program is VERY useful,
especially if you consider the increased use of in process probing.
The machine with this capability could "recover" on its' own. Also ,
it might be nice to be able to 'check' before finish milling (after
the heavy, roughing cuts) to be SURE we're where we 'think' we are...

>IMHO - Why muddle up relatively simple g-code language with all of
>the great ideas that we can think up.

We actually AGREE on this! I think the RS-274 standard IS entirely
adequate. BUT, it was written with the "holes" in place to create new
features, as discovered or required.

I'll say it again, "Do you want to go back to CPM?" None of
that "messy" GUI 'stuff' to worry about! Just SIMPLE TEXT COMMANDS!

BTW, when we discuss CNC controls on list, not all of the suggestions
refer to the GCODE! Some are intended FOR the User interface (GUI or
not) or "conversational" components...

>We can write a language any way we want. Just don't pretend that
>it's the "real" g-code. Call it RS274ALAN or RS274BNDO.

Exactly! OR do as NIST has done, and call it RS274NGC !!!!!

Hope this helps.

Ballendo

P.S. Ray, I have great respect for your work and efforts. I really
hope EMC becomes THE standard, BUT... It needs to realise that A/B
and GE ARE NOT the 'only ones' making controls NOW!