On 06.02.12 10:03, andy pugh wrote: > On 6 February 2012 04:35, Erik Christiansen <dva...@internode.on.net> wrote: > > Granted, if I had them ingrained in my brain, after decades of use, I > > would not change either. There is no reason to. An optional input filter > > only provides flexibility to anyone wanting more. The filter I'm playing > > with will offer decluttered old syntax, and a more human readable form. > > Should it be completed, its use is discretionary. > > I think that any existing and working file with the .ngc extension has > to carry on working, but if folk want to smarten up the interpreter to > work without <> tags and O-numbers in the control structures, that > seems fair.
Thanks for that, Andy. :-)) Any existing file with <> tags and O-numbers will still work though, if the filter is not used, or made transparent or tolerant of those characters as optional input. I'll look at the latter as we go along. (At the moment, I'm adding error handling, as a break from writing gcode grammar, which needs a bit of grubbing about in the doco) Complete error handling is an ambitious target. At the moment it's just a fair bit of useful error handling that is the goal. > However I see no reason why we shouldn't consider starting from > scratch with a new machine-control language, possibly based on Python > syntax. I would prefer to see that translated directly into motion > commands in LinuxCNC rather than into any sort of G-code, though. Though I haven't thought that one through with a lot of caffeine in the veins, I'm having trouble working out how to do it. The current LinuxCNC dialect looks ugly, but is a powerful problem-domain language which provides problem-domain statements which do real things on the machine. Python-C-Basic-Fortran-whatever-style higher level flow control has been added to that, giving the best of both worlds. Take out the gcode, and what is left? Where would we go from functions, flow control, and arithmetic, to make a swarf-making machining language out of a counting and text-shuffling pythonesque one? > However, fun though that might be, I doubt it would reach completion, > or gain any sort of market acceptance outside a very small subset of > LinuxCNC users, and almost certainly wouldn't expand outside our > project. Can't disagree there. Whether my fooling around with an attempt to give a bit of the look and feel of that, by just making LinuxCNC flow control and function calls _look_ like python, will be met with jubilation is doubtful. If there are any bites on my questions about preferred syntax for the literate form of gcodes, in my prior post, then this exercise can at least serve to exercise our minds about what we're looking for. If we don't know what could serve as a reasonable next step, possibly toward a longer-term goal, then we're stuck here. Maybe Dave was using a table-driven translator, rather than a language grammar below, but generating gcode from something else means defining that something else, preferably in a reasonably broad consensus: On 05.02.12 18:35, Dave Caroline wrote: > I too wrote a gcode generator for some of my standard shapes but found > it was more elegant to do it in gcode as I could use sensible(ish) > variable names. why enter in a form, generate code, transfer, when it > is a simple edit to a standard gcode file. > > Gcode needs bringing up to date we no longer need cater for paper > tape. Mostly we need some immediate benefits, if adoption is to be a realistic prospect, I think. Erik -- Any project you tackle is always hardest at the beginning, like working up a swing. - P.K. Shaw ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
