G code standard vs. opinion was Re: Learning G Code

Doug,

The EIA rs-274D standard which defines G code states that whitespace
is to be ignored. It was last updated/adopted in late 1980; date is
1981) So if the controllers you are using won't process each of my
sample blocks/lines the same way (excepting the already mentioned
upper/lower case), then you should ask the manufacturer, "why not?"

FWIW, It surprises me to hear you say this. Most modern commercial
controls I have seen will work with white space correctly, although
there are other syntax issues (like whether G1 is regarded the same
as G01). Could it be that the controls you are using are older, and
HAD to diverge from the standard due to the lower level
of "available" technology? (limited speed/memory space/etc.)

The use of decimal points in axis "departure" params is another
example of a syntax issue which has (thankfully) all but disappeared
on new controls (old controls used an "implied" fixed point, meaning
1.5 needed to be expressed as 1500 or 15000, depending on the
specific control). There were LOTS of "operator" errors over that
one!

Another common syntax related error came from the need to PUT a
decimal point after whole numbers so as not to have them misread as a
small movement/distance; i.e., a one inch move needed/needs to be
entered "one,decimal point" (1.) If it is instead entered as (1) the
control might only move .001 or .0001 inch. This is one of the FIRST
things to determine about an unknown control you are about to write
code for! Some pc based controls require the decimal point after
whole numbers, others do not.

And finally, the "r" in rs-274D stands for "recommended", which
gave/gives the control writers an out. NO ONE should be taking that
sort of "out" nowadays, IMO.

So if anyone is behind the times, it is the writers of cnc controls
that do not/did not address the standard...

Hope this helps.

Ballendo

P.S. My opinion is that the standard should be followed wherever it
CAN be, to increase standardisation of g code usage... The reality is
that at various times, the technology available meant that the
standard could not be followed. Also, more than a few controls have
been written by people who have never even READ the standard (I have
personal knowledge of this as fact).

A second fact is that the standard needs updating. Some codes have
become commonly used in ways which the old standard could not
anticipate. G20 and G21 for inch and mm units, for example; these
used to be G70 and G71, respectively. In the limited technology of
past years, the G20 and G21 were used for "other things" that aren't
necessary now (like whether the movement was under 10 inches or over
10 inches). As these "holes" developed, mfrs. put "new" codes in the
old places. In the example given, the 70's (group of ten codes, g70-
G79) were more and more used for fancy "expanded" canned cycles, like
pocketing. So the necessary "units" codes (g70,71) were moved to
G20,21 by a successfuly marketed control, and so becoame the
new "standard" (even tho the 274D sez use 70,71).

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

P.P.S. I guess this type of thing will happen in any "evolving"
thing. Kind of like what is happening with the English language as
more people communicate by typing on the net: "then" is used
where "than" should be used, and the contraction of "you are"
becomes "your" instead of the correct "you're". <rant off>

--- In CAD_CAM_EDM_DRO@y..., "doug98105" <dougrasmussen@c...> wrote:
> Ballendo,
>
> I'm not aware of any commercial/production CNC controls that allow
> this type of "free form" syntax. All controllers I'm familiar with
> are very syntax specific. You either program according to their
> rules of syntax or not at all.
>
> Are you expressing an opinion of the way you'd like things to be,
or
> am I way behind the times regarding interpreters?
>
> thanks,
>
> Doug
>
>
> --- In CAD_CAM_EDM_DRO@y..., "ballendo" <ballendo@y...> wrote:
> > Brian, list,
> >
> > A properly written G code interpreter will ignore "white space".
> > Therefore the lines (called blocks in g code):
> >
> > G01 x5 f12
> > G01x5f12
> > G 0 1 x 5 f 1 2
> > G01 x5 f 1 2
> >
> > will all be treated the same way.
> >
> > G code is also SUPPOSED to ignore case, but many interpreters
> require
> > the use of upper case letters to work correctly. MaxNC is one
> example.
> >
> > Hope this helps.
> >
> > Ballendo
> >