Re: Re: gcode comments

Ballendo

Well I guess I slipped a burr under the saddle blanket that time.

Thank you for the kind comments. I also appreciate the work that you do
for this group and your machine experience and willingness to help.

The essence of my comment surrounded your use of the term variant
as applied to RS274NGC because it is no more of a variant of RS274 than the
modern liturgical and scholarly Latin is a variant of that ancient
language. There are many variants of classic Latin that have become the
common languages of several nations but what the Latin scholars use is not
one of them. Offspring as opposed to cousin might better express the
relationship.

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

No. I'm not saying that you or anyone else should use any specific
language to communicate with your machine. What I am saying is that we
need to get the lineage of our languages correct.

I don't believe that it is appropriate to speak of MSdos and CPM as
variants. Except in the broadest context of both being operating systems.
If that is the way that you mean your term then 'scuse me for over reacting.
Dos, unix, and the new MSwindows may all access similar procedures for the
same hardware but they are not variants of a common thing. They come from
very different ways of thinking just as Mazatrol is not a variant of
g-code. Yes they both run machines and Mazatrol allows the input of some
M and G words but they come from different worlds.

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

IMO -- If a machine can't remember where it's home is, it has a problem.
Why add codes to the part program language to correct a machine problem.

Further, the purpose of roughing cuts is to get to a known distance from
the finish surface gracefully. Random steps in rough cuts will mess up a
part finish as quick as a lot of other things. And why would roughing cuts
mess up the location of a machine anyway -- the short answer is because the
programmer or machine operator screwed up and bound up a step motor in
open loop configuration. So again why add commands to the part programming
language in an attempt to make up for bad planning or stupid machine
operaton.

I like your use of the word "nice" because it makes part of my case for me.
One person's "nice" is another's "nasty." I wouldn't want that 50 ton
machine, with the 150kva spindle turning a face mill the size of a tractor
tire, trying to recover all on it's own. The thought reminds me to much of
HAL the onboard computer in the book "2001 ..."

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

In an age of multitasking computers it should be relatively easy to start
up a new feature in parallel rather than insisting that that feature be a
part of the motion language. Yes we should add all kinds of helps and
calculators and tests to assist programmers and operators but that stuff
needs to be available from the GUI not in the part program code itself.
Much of this kind of stuff doesn't need to be available at run time at all.

And last but not least with cross platform languages it should be possible
to write this kind of assisting stuff so that they will run equally well on
any system that we might want to use for programming or operating.

Thanks for the stimulating conversation here. I mean no disrespect.
--

Ray