Re: G code standard vs. opinion

Paul,

Yes, I agree Toms documentation is excellent. Which is why I added
the last paragraph to my post so that the message would be shot, not
the messenger.

It is great news to hear of your support for improving emc toward
both standard and convention. Unfortunately, some choices will not be
that easy to correct, as they are in place and have become already
THE standard for those using EMC. And it is nearly always harder to
get the horse back in once he is out... I lobbied for the standard
having sway over the A-B document(noted as NCMS,I think) before the
release of the 274ngc 6 axis interpreter, but as I said, Tom just
wanted to be done(and on to adaptive controls, I think), and
replied, "well you can't please everybody".

I also tried to create a repository for different flavors of Gcode,
by creating the gcode yahoo group. It is still there, but there is
little INDIVIDUAL incentive for individuals to contribute, and one
person who DOES have lots of Gcode flavors available, actually told
me it was better to NOT standardise, since there is money to be made
on the differences, through tech support and individualised posts
(post-processors).

I KNOW what the standard sez, and I have my own IDEA of what the
conventions are, but it sure would seem correct to "hash them out" in
a multi-person way. The gcode group is still there, waiting...

So, for the first foray, I would suggest you start using G20 and G21
for units (which frees up the G70's for fancy "canned" routines). I
suppose it really is too late to get rid of the GXX.X codes... How do
you handle a G121? (multiply to 1210,increase the array size to
accomodate it,etc: at least last time I looked at the code?)

I have said on this list before that I think the HAAS flavor should
be seriously considered when making decisions, not because of any
connection to HAAS, but simply that they are selling more cnc
machines than nearly anybody else (definitely domestically; USA) and
therefore the developed decisions will have a wider audience. This
will only increase with their latest mini-mill offerings, IMO.

G code is at the same place that screw threads were at the beginning
of the last century. I read an article recently about this, wish I
could remember where. It took a "connected", respected machinist
gentleman and a "helpful" war (we yanks didn't like making your
English whitworth threads as we helped in the war effort) to effect
the change to 60° v-threads which today is taken for granted.

I would love a world where a g04 ALWAYS used P and a floating-point
param which was in seconds/100. And the other Gcodes consistent as
well. Training would be facilitated, in much the same way MS,
love 'em or hate 'em, has standardised the office worker trade. FWIW,
I hate 'em, but I repect their awareness of the way the world REALLY
works...

Again the problem is that not everyone will be interested in planting
seeds, from which trees grow to definitely help the world, but which
may not have immediate effect personally...

Maybe a first step is to get/find the eia rs 274D standard online!
I have a paper copy somewhere, but have not found it available
anywhere online, except to purchase.

Thank you for your initiative,

Ballendo

--- In CAD_CAM_EDM_DRO@y..., Paul <Paul.Corner@t...> wrote:
>
> Hi Ballendo
>
> Of all the code written for EMC, Tom's contribution is by far the
best
> documented. Reading the sources, it very easy to determine how ach
line is
> parsed and the G and M codes are interpreted. To sit down and
change any of
> the G codes either redefining them or altering the syntax is
trivial. Even
> adding new codes is a doddle.
>
> If you don't like something, or it appears to be 'non-standard', it
can be
> changed. The line number limit of 99999 (when using Nxxxxx) has
been removed
> from my copy of the sources. I'm in the process of adding a couple
of new M
> codes - But the only "standards" I have are based on ISO documents
(and I
> still use G70/G71). I have never seen the EIA RS274 specifications
nor many
> of the manufacturers manuals. Heidenhain and ANC are about my only
> programming references.
>
> I would wellcome a debate/discussion on where EMC deviates from
a "standard"
> either on or off list - There is no reason why changes can not be
made to the
> EMC sources hosted at Sourceforge.
>
> Regards, Paul.
>
>
> On Tuesday 25 December 2001 8:26 am, ballendo wrote:
>
> > So it is not a simple answer. I had hopes that the EMC interpreter
> > would become the "new" standard (and in some ways it has), but as
has
> > been pointed out recently, the man who programmed it worked
largely
> > alone and mostly from an A-B(allen-bradley) document,
> > thereby "preserving" some pretty weird stuff. And also
implementing
> > some other weird stuff, IMO. There were government politics
> > involved... He DID have access to(and read) the 274D standard,
but in
> > places of confusion between the standard and the A-B "owners
manual"
> > document (disguised under a govt. program name), he inexplicably
> > chose the A-B document for guidance.
> > I even asked him why he chose certain things, when the marketplace
> > had obviously developed differently. pretty far along, he just
wanted
> > to finish the job, as Gcode is/was not a favorite of his anyway.
And
> > g code is again made more complicated than needs be...
> >
> > NOTE: I'm not saying he did bad work! Quite the contrary. I only
wish
> > he was able to "see" the impact of his choices on the future of
> > gcode, and avoid the NIH (Not Invented Here) syndrome so common in
> > govt. projects. (and of course I have NO idea what his defined job
> > REALLY was; he may have had his hands tied.)