CAD CAM EDM DRO - Yahoo Group Archive

Re: [CAD_CAM_EDM_DRO] G code standard vs. opinion

Posted by Paul
on 2001-12-25 04:03:25 UTC
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.)

Discussion Thread

woodknack 2001-12-23 05:34:18 UTC Learning G Code cncdxf 2001-12-23 06:08:56 UTC Re: Learning G Code Richard Konnen 2001-12-23 06:13:05 UTC Re: [CAD_CAM_EDM_DRO] Learning G Code Scot Rogers 2001-12-23 09:04:03 UTC RE: [CAD_CAM_EDM_DRO] Learning G Code wanliker@a... 2001-12-23 10:26:38 UTC Re: [CAD_CAM_EDM_DRO] Learning G Code Michael Milligan 2001-12-23 12:14:39 UTC RE: [CAD_CAM_EDM_DRO] Learning G Code ka1bbg 2001-12-23 15:23:52 UTC Re: [CAD_CAM_EDM_DRO] Learning G Code Chris L 2001-12-23 18:19:54 UTC Re: [CAD_CAM_EDM_DRO] Learning G Code ballendo 2001-12-24 05:27:50 UTC Re: Learning G Code ballendo 2001-12-24 07:09:42 UTC Re: Learning G Code doug98105 2001-12-24 08:58:09 UTC Re: Learning G Code ballendo 2001-12-25 00:26:51 UTC G code standard vs. opinion was Re: Learning G Code Paul 2001-12-25 04:03:25 UTC Re: [CAD_CAM_EDM_DRO] G code standard vs. opinion ballendo 2001-12-25 05:09:55 UTC Re: G code standard vs. opinion Matthew King 2001-12-25 05:36:32 UTC Re: [CAD_CAM_EDM_DRO] G code standard vs. opinion was Re: Learning G Code wanliker@a... 2001-12-25 09:52:01 UTC Re: [CAD_CAM_EDM_DRO] G code standard vs. opinion was Re: Learning G Code Paul 2001-12-25 13:58:30 UTC Re: [CAD_CAM_EDM_DRO] Re: G code standard vs. opinion