On Thu, Oct 31, 2013 at 6:26 AM, Bertho Stultiens <ber...@vagrearg.org>wrote:
> On 10/31/2013 07:38 AM, Gregg Eshelman wrote: > > Once achieving a state where all of a program works, it's a good idea to > > do a renumber then continue work on a copy. > > > > If G-Code cannot handle gaps in its line numbers, then perhaps an editor > > could do so, then have a Save As runnable output function which > > automatically renumbers with a step of one and another option to save > > the editing version with the gaps? > > If you already are in need for a program to help you to fix a program, > then why not fix the language in the first place? > > G-code has already evolved through time to support many more features > than originally envisioned, but it still suffers from the the same > archaic syntax. That was (and is) my objection. Even basic evolved into > a (almost) context-free grammar, for the better or worse, in visual > basic. Please note that you can write "bad" code in any language... > > I am not forcing anybody to change their habbits or preferences, only > hoping to. I am trying to provide an alternative. Explaining why I want > to provide an alternative seems a reasonable thing to do. > Guys: I don't understand this obsession with line (aka block or sequence) numbers in G-Code, e.g., instances of the "N" word. They are optional and exist for the benefit of the programmer / operator, not the interpreter. Use your favorite search engine to find examples of utilities which can add, remove, or renumber line numbers in G-Code programs. (Sorry, many are not free, but that's the way life is. Write your own if you feel the need. It's an easy exercise.) Note that "O" words are the proverbial horse of another color. Bertho, there is no need to dwell on the archaic syntax of G-Code. G-Code was invented long ago and will continue to live on given the installed base of machinery, design/control software, trained operators, and G-Code programs stored away for future use. Sure it's a conservative industry, but the emergence of CAD/CAM software means most professionals no longer generate G-Code by hand anyway. There is no need to dwell on the justification for providing an alternative, either. As my grandmother was fond of saying, "the proof of the pudding is in the eating." Let's get on with finishing the pudding and let the CNC world decide if it likes the taste. If it does, then gcmc will be its own justification. If it doesn't, you'll still have a program which satisfies your needs and sensibilities. My guess is that some will like it, some won't. A long-ago friend liked to remind me, "there's no accounting for taste." Just my 2-cents worth. Regards, Kent PS - Never forget the lesson taught by history. Esperanto was a "perfect", easy-to-learn language with many desirable features and intended to promote peace and harmony in the world. Lingua Franca was a bastard, polyglot language which grew out of necessity to support growing commerce among countries surrounding the Mediterranean. Guess which one was consequential in world history. ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
