Re: [Emc-users] question on gcode parsing
Hi Alan, that is an interesting idea. from the interpreter perspective there's in principle no issue why some other language couldnt emit canon calls just alike; possible (with a lot of work) note that other parts of linuxcnc have some assumptions about the language, for instance the UI's - not just from the input language, but also features like UI startup, and backend issues like run-from-line, and those assumptions arent spelled out in some spec - you're off to reading code that said, dropping rs274ngc as a language from the scene completely is going to break a lot of corners of linuxcnc, and IMV its not desirable to start with however, I think it possible with limited effort to have a second language basically besides rs274ngc; this would require some minor adaptation of a UI to understand that there's more than one language to execute (as a file, and 'MDI', if you will) and default would be rs274ngc. It is IMV the only realistic migration scenario because it can be done incrementally. flatly the more discussion I read about *designing* a new language, the less I see the point - it would be IMV useless work in building from scratch a new language with stepping, breakpoints, state model, introspection etc and arrive on something less that whats alreday out there in existing other interpreted languages. What I can image is taking an existing interpreter, say Python, and make it understand G-code in some shape or form, and that would call on the existing rs274ngc interpreter. Maybe as a subroutine to start with. You want g-code, well execute that. You want arbitrary data types, external packages, advanced control flow - use Python and fall back to rs274ngc where it makes sense. Given that, one can build arbitrary other languages ontop of Python - there's a lot of tools, packages and experience out there in doing that; training the rs274ngc pony to do the same trick isnt going anywhere. IMV this is all about vehicles, not language preferences. If you have a decent vehicle, you dont have to bother somebody else with your language preferences, just go build it and be done with it, instead of having yet another round of academic discussions in which-language-looks-better-today. Yes, plugins are the stuff which makes projects successful. HAL for instance is one very sucessful plugin mechanism. Comp is another one. We dont have anything of that ontop the language and task executor, and few on the UI side of things and *within* rs274ngc. To clarify: with "plugins" I mean end-user/integrator extensible, not C/TCL-developer extensible. That's just too much of a minority issue. Yes, filters are glorified macros with all the downsides, I dont count them as plugins. - Michael Am 12.02.2012 um 14:03 schrieb Alan: > Hi everyone, > > I have followed the discussion so far with interest. I personally view > gcodes as a very low level language. I guess the addition of owords goes > some way towards improving things. My ideal would be an object based > language for describing the geometry etc of path generation. But my real > reason for commenting is to ask a question. > > Is it possible (i.e could be done reasonably quickly and fairly > simply!!) to change emc so that motion processors became a plugin (in > the same way that eclipse has plugins)? In that way emc could come with > the standard plugin to transcribe current gcode text files into motion > commands but would allow others to write (if they felt inclined) python > plugins, sophisticated Gcode parsers or APT360 parsers etc. > > I suspect the quick answer is no as it would require some very radical > changes to emc's structure, but it would to me be an interesting > development but then again I am a retired hobbyist with a computing > background. > > So my question is really about allowing extensibility in the future. I > do not think that I am talking here about filters which to my limited > understanding are something like a macro facility. Have I got that right > or are they more than that? > > My visualization of a postprocessor plugin is that it would take a file > as input and would output a sequence of low level emc-library motion > commands, so would require that these basic motion commands be made > explicit and publicly accessible. > > I dont know how this would fit in with displays such as Axis and with > kinetics modules but suspect that these could work at the lower level > motion commands. > > If adding plugins is already possible please excuse my ignorance and > point me to how that is possible. > > Thanks > > Alan > > > -- > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > __
Re: [Emc-users] question on gcode parsing
Hi everyone, I have followed the discussion so far with interest. I personally view gcodes as a very low level language. I guess the addition of owords goes some way towards improving things. My ideal would be an object based language for describing the geometry etc of path generation. But my real reason for commenting is to ask a question. Is it possible (i.e could be done reasonably quickly and fairly simply!!) to change emc so that motion processors became a plugin (in the same way that eclipse has plugins)? In that way emc could come with the standard plugin to transcribe current gcode text files into motion commands but would allow others to write (if they felt inclined) python plugins, sophisticated Gcode parsers or APT360 parsers etc. I suspect the quick answer is no as it would require some very radical changes to emc's structure, but it would to me be an interesting development but then again I am a retired hobbyist with a computing background. So my question is really about allowing extensibility in the future. I do not think that I am talking here about filters which to my limited understanding are something like a macro facility. Have I got that right or are they more than that? My visualization of a postprocessor plugin is that it would take a file as input and would output a sequence of low level emc-library motion commands, so would require that these basic motion commands be made explicit and publicly accessible. I dont know how this would fit in with displays such as Axis and with kinetics modules but suspect that these could work at the lower level motion commands. If adding plugins is already possible please excuse my ignorance and point me to how that is possible. Thanks Alan -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 03.02.12 12:49, Erik Christiansen wrote: > What I did in July does already check for some run-time conflicts which > I found in the doco, e.g. Turning on radius compensation in an illegal > plane: The snippet can pick up the conflict in a simple fall-through gcode program, but not if the axes are set in a function. Anyone doing that is on their own. Erik -- "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn -- 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
Re: [Emc-users] question on gcode parsing
On 02.02.12 09:11, John Kasunich wrote: > On Thu, Feb 2, 2012, at 08:20 PM, Erik Christiansen wrote: > > On 01.02.12 20:32, Kenneth Lerman wrote: > > > 3 -- A semantic analyzer (whether rule based or coded) will be necessary. > > > > Do you want to prove some property of the gcode program, such as whether > > it will ever reach the end? > > I've only been loosely following this thread, for example I'm > not sure of the precise distinction between lexer and parser, OK, a lexer is basically a text scanner which "tokenises" the input. It recognises e.g. any Gxxx word, and passes it to the attached parser, normally with a different token value for each gcode. In contrast, a numerical constant is passed as e.g. a CONST token, together with its numeric value in a parser helper variable, e.g. "yyval". The lexer just lets the parser deal with whole language objects, or "tokens" as the jargon goes. > etc., nor have I been keeping track of who wants to do what. > But I want to put my 2 cents in. Thanks for bringing the discussion back toward the user perspective. The more "2 cents" worth, the closer we get to something potentially useful. > I think the "property of a g-code program" that a machinist > is most interested in is "will it run on my machine". That > implies far more checking than a simple parser would do. Yep, I can see that, but as Alan Condit voiced, even a full gcode grammar (which checks only for legal syntax) is "non-trivial" to implement. (And we know that this actually means: Just because you start, doesn't mean you have the stamina to finish.) Don't we have the simulator for the purpose of checking whether our latest gcode gem "will it run on my machine"? It will take longer to add simulation-level checking to a front-end filter, originally only intended to clean up and formalise input syntax. > For example, G1 without a feedrate set is an error, and needs > a meaningful error message. Doesn't matter to the machinst > which stage in the parsing/interpreting process generates the > error. It is the responsibility of an executable grammar to flag any syntax error, in a human readable manner. Catching them all would be an incremental affair, with v0.9 being much better than v0.1. > Likewise for arcs that fail because the numbers aren't > precise enough and the endpoint doesn't line up, or an offset > toolpath that causes gouging. While technically that's not grammar, because we've now jumped into semantics, it is quite feasible to embed enough maths in the grammar leaf code for this terminal, to pick up the first error this early. What I did in July does already check for some run-time conflicts which I found in the doco, e.g. Turning on radius compensation in an illegal plane: compensation_modality: RADIUS ON LEFT { if (Plane == YZ) error("Operation illegal in the YZ plane.") ; emit(" G41") ; } | RADIUS ON RIGHT { if (Plane == YZ) error("Operation illegal in the YZ plane.") ; emit(" G42") ; } | RADIUS OFF { emit(" G40") ; } ; Note to self: Factorise that raw first cut of the grammar snippet, so the error handling code only appears once. > If you are going to invent a black box (parser, whatever) that > takes in some new dialog and spits out g-code, without doing > all the checks that the interpreter eventually will do, please > think about the machinist. When the interpreter eventually > does spit out an error that says "G3 line 125 endpoint doesn't > match", will the user be able to correlate that to the error > in his actual program? Especially if the new dialect doesn't > even use the term "G3", or if the translator doesn't preserve > line numbers (perhaps by discarding comments or blank lines). Oh. You've changed my mind about chucking out comments. Admittedly, we couldn't hoik them all out anyway, because of the incomprehensible weirdness of some comments not actually being comments, but display statements instead, IIRC. :-( Yes, line numbers must correspond, to every feasible extent. If the user has chosen to use the tool to take "Rapid" as input, in lieu of "G0", then hopefully he'll have a cheat-sheet on the wall, to cope with the lower-level machine representation. All these details are enthusing me for the task of picking up where I left off, back in July, after a much less enthusiastic on-list discussion. Erik -- Programs must be written for people to read, and only incidentally for machines to execute.- Abelson and Sussman -- 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,
Re: [Emc-users] question on gcode parsing
On Thu, Feb 2, 2012, at 09:11 AM, John Kasunich wrote: > > If you are going to invent a black box (parser, whatever) that > takes in some new dialog and spits out g-code, without doing I meant "dialect", not "dialog", sorry > all the checks that the interpreter eventually will do, please > think about the machinist. When the interpreter eventually > does spit out an error that says "G3 line 125 endpoint doesn't > match", will the user be able to correlate that to the error > in his actual program? Especially if the new dialect doesn't > even use the term "G3", or if the translator doesn't preserve > line numbers (perhaps by discarding comments or blank lines). > -- John Kasunich jmkasun...@fastmail.fm -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On Thu, Feb 2, 2012, at 08:20 PM, Erik Christiansen wrote: > On 01.02.12 20:32, Kenneth Lerman wrote: > > 3 -- A semantic analyzer (whether rule based or coded) will be necessary. > > Do you want to prove some property of the gcode program, such as whether > it will ever reach the end? I've only been loosely following this thread, for example I'm not sure of the precise distinction between lexer and parser, etc., nor have I been keeping track of who wants to do what. But I want to put my 2 cents in. I think the "property of a g-code program" that a machinist is most interested in is "will it run on my machine". That implies far more checking than a simple parser would do. For example, G1 without a feedrate set is an error, and needs a meaningful error message. Doesn't matter to the machinst which stage in the parsing/interpreting process generates the error. Likewise for arcs that fail because the numbers aren't precise enough and the endpoint doesn't line up, or an offset toolpath that causes gouging. If you are going to invent a black box (parser, whatever) that takes in some new dialog and spits out g-code, without doing all the checks that the interpreter eventually will do, please think about the machinist. When the interpreter eventually does spit out an error that says "G3 line 125 endpoint doesn't match", will the user be able to correlate that to the error in his actual program? Especially if the new dialect doesn't even use the term "G3", or if the translator doesn't preserve line numbers (perhaps by discarding comments or blank lines). -- John Kasunich jmkasun...@fastmail.fm -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 01.02.12 08:42, dave wrote: > On Wed, 1 Feb 2012 19:34:09 +1100 > Erik Christiansen wrote: > > > On 31.01.12 21:45, dave wrote: > > > > > To my uncluttered mind ... read blank ... > > > is this a good way to set the state of a machine at any given line > > > as a precursor to "restart from line no"? > > > > IIUC¹, running an interpreter through the code from line 1 to a given > > line, with all external actions suppressed, ought to "set the state > > of a machine" for that line, if the gcode takes no input, and does no > > probing. i.e. state is dependent only on the running of the gcode. > > (But that's just theory, aka a WAG. Experts may differ.) > > > > Erik > > > > ¹ I'm not sure what part of the 129 lines quoted constitute > > "this". ;-) > > > Erik, > The theory seems to work. Years ago I wrote such in C but I put in the > dropbox and is has gotten lost in my transitions of machines and the > apparent disappearance of the dropbox. > I was just wondering if there was a better way. Judging from the several posts warning us that tracking run-time values of modalities is a problem, I'd say no-one has found a way. (That doesn't mean ya can't do it with a Quantum computer, IIUC the hype which surrounds them. ;) Oh, the pain of losing the blood, sweat, and tears which went into a good hand-hewn tool. (I have 8 copies of my favourite, and my 300+ pages of software survival notes. My memory is crumbling 20 years earlier than Gene's, so I _need_ those notes to remain efficient.) Erik -- Never worry about theory as long as the machinery does what it's supposed to do. - Robert A. Heinlein -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 01.02.12 20:32, Kenneth Lerman wrote: > On 01/31/2012 11:14 PM, Erik Christiansen wrote: > > Any "need" to know the run-time state of a modality before run-time is > > illusory. That which needs to be known at run-time needs to be known at > > run time, not before. It is worth understanding that the run-time value > > of a modality is not part of the grammar. I'm not sure what you're > > basing these imaginary concerns on, but I can't relate them to reality, > > despite some effort :-) > > In the past you've implied this, When dragged off onto the topic of interpreters, I've had to discuss what happens _at_ run-time. Now let's read the above paragraph again. ;-) A language grammar specifies permissible input syntax. It knows nothing about the (changing) run-time values of variables or states (modalities). An interpreter _uses_ a grammar, not just to translate input into text output, as a translator or compiler would, but to execute the code. Now we have jumped into the run-time universe, and need to track state, just as we track the values of all the variables. My current understanding is that a modality ought be initialised at the start of a gcode program, and changes state according to the run-time path through the gcode, whether that's straight down the page or dizzy as a fly dodging the corks dangling round the brim of a swaggy's hat. That's run-time state, not grammar. > and roughly three or four posts in the future, you bemoan the fact > that Haberler's trial grammar "is devoid of any explicit gcode > grammar." My concerns were based on previous statements that you > thought this should be done. Please put those concerns to rest. There is no intrinsic connection between a grammar and run-time values. The problem with the absence of gcode grammar from a trial grammar is that we have moved no nearer to documenting the LinuxCNC dialect, because the so-called parser was only a tokeniser, blindly passing any text from G0 to G999.9 inclusive, without recognising any difference between G76 and G497.6, as you can see here: Lexer: gcode ({digit}{1,3}((\.{digit})?)) ([Gg]{opt_ws}{gcode}) {RETURN_TOKEN(token::TGCODE);} The parser, as shown upthread, does not receive a value with TGCODE, and there is only this one token for all ten thousand gcodes that it passes on like a hollow pipe. The "parser" does _not_even_know_ which gcode it is blindly letting through. Thus, for LinuxCNC gcode, it is only a tokeniser in effect, at this stage. Any handling of even one LinuxCNC gcode remains to be added. As we were warned when it was posted, it's experimental Mk. 0.1. My comments just try to clarify what it does now. > While you could put some grammar rules in place, it is my contention > that no matter how good the grammar, you will need some semantic > analysis. There are clearly different needs out there. The two I'm repeatedly running back to are; documented grammar, definitely executable, and (if we can get away with it) a more literate optional input form of the same LinuxCNC dialect we now use. (There will be some grumbling if it's mixed in with the grammar for the "kosher" current form. I'll have to look at keeping them visually separate, if possible.) ... > In short, I'm suggesting that: > 1 -- An automated lexer would be useful > 2 -- An automated parser might be useful (if it can give reasonable > error messages, etc AND be reasonably modified.) If minor changes > require digging through shift/reduce conflicts and trying to resolve > them, that might be reason to avoid such technology. :-) It might be worth remembering that shift/reduce conflicts arise from an ambiguous grammar. Their occurrence help us avoid that. Better a grammar fix, than unpredictable results in the gcode, when swarf and coolant are flying. > 3 -- A semantic analyzer (whether rule based or coded) will be necessary. Do you want to prove some property of the gcode program, such as whether it will ever reach the end? Erik -- Don't believe everything you hear, or anything you say. -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 02/01/2012 03:34 AM, Erik Christiansen wrote: > On 31.01.12 21:45, dave wrote: > >> To my uncluttered mind ... read blank ... >> is this a good way to set the state of a machine at any given line as a >> precursor to "restart from line no"? > IIUC¹, running an interpreter through the code from line 1 to a given > line, with all external actions suppressed, ought to "set the state of a > machine" for that line, if the gcode takes no input, and does no > probing. i.e. state is dependent only on the running of the gcode. > (But that's just theory, aka a WAG. Experts may differ.) > > Erik > > ¹ I'm not sure what part of the 129 lines quoted constitute "this". ;-) > Unfortunately, if you have control structures that include loops and subroutines, the statement "restart from line no" may have no real meaning for some places in the code. "Restart from the Nth execution of line no" might be more meaningful, although it might be difficult for the user to determine the appropriate value of N. A better way to get the desired functionality might be to jog backwards along the previously executed path until the desired place in the code has been reached. The display could show the runtime subroutine stack and any important variables with an ability for the user to select items of interest. Of course, the "current" line would be highlighted. Then the user could "say" run from the current position. Ken -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 01/31/2012 11:14 PM, Erik Christiansen wrote: > On 30.01.12 07:54, Kenneth Lerman wrote: >> On 01/30/2012 12:28 AM, Erik Christiansen wrote: >>> What is being missed here is that the present parser does all that you >>> fear above, just without the maintainability and documentation benefits >>> conferred by a higher level implementation, using powerful tools. >>> >>> Erik >>> >> No. I don't think so. >> >> The current implementation does it; not the current parser. If we go >> back to the compilation/execution analogy, some error conditions are >> detected at run time; not at compile time. > There is no compile time. Both the current and future parsers are > interpreters only, AIUI. > >> I don't see how the parser can require that G1 has an Fn clause >> defined on the same or some previously executed line. > Nor can I. It doesn't. AIUI, gcode executes with whatever value of that > modaility is current. It does that now, and any new interpreter easily > does the same. The grammar then _permits_ an Fn clause where we choose. > >> The parser knows nothing about execution order; only about lexical >> order. Since the Fn might be hidden away in some subroutine, the parse >> might not have seen it. I would think that knowing whether an Fn is >> active is a difficult problem when looking from the outside, but a >> simple problem from the inside of the run time environment. (Of >> course, feel free to prove me wrong.) > Any "need" to know the run-time state of a modality before run-time is > illusory. That which needs to be known at run-time needs to be known at > run time, not before. It is worth understanding that the run-time value > of a modality is not part of the grammar. I'm not sure what you're > basing these imaginary concerns on, but I can't relate them to reality, > despite some effort :-) In the past you've implied this, and roughly three or four posts in the future, you bemoan the fact that Haberler's trial grammar "is devoid of any explicit gcode grammar." My concerns were based on previous statements that you thought this should be done. While you could put some grammar rules in place, it is my contention that no matter how good the grammar, you will need some semantic analysis. Once we have that requirement, I believe that a framework that tests for appropriate semantics (including for example, that there MUST have been a previous -- in the execution sense, not the lexical sense -- Fword for G1) will be both necessary. If that exists, and I believe that it must, there is little extra benefit to having the formal grammar handle some of the cases. In short, I'm suggesting that: 1 -- An automated lexer would be useful 2 -- An automated parser might be useful (if it can give reasonable error messages, etc AND be reasonably modified.) If minor changes require digging through shift/reduce conflicts and trying to resolve them, that might be reason to avoid such technology. 3 -- A semantic analyzer (whether rule based or coded) will be necessary. Regards, Ken >> Don't get me wrong. I agree that we need a better definition of the >> grammar and a more structured implementation. In general, though, I >> prefer recursive descent parsers such as the present parser that is used >> for each line. I consider the ability to generate excellent diagnostic >> and error messages to be worth the effort of hand coding. > We usually prefer what we're good at. I'm as guilty of that as the next > bloke. The actual merits of the alternatives have been kicked about > upthread. > > I wouldn't propose replacing the current parser in the forseeable > future. Since there is interest in a more readable input syntax, > expressed several times per year by a subset of LinuxCNC users, I have > upthread already discussed implementing a filter which supplements the > existing parser, but does not replace it. That way, there is scope for > pleasing two groups. > >> I recognize that my control structure (o-word) implementation leaves a >> lot to be desired -- to say the least. About its only saving grace is >> that it enables us to do a lot of things we couldn't do before. It must >> be redone in a way that is obviously correct and maintainable. > As they say, "The perfect is the enemy of the good." An available > practical implementation is superior to any imagined "perfection" which > does not yet exist. If the limitations of the current parser have forced > clutter upon the user, just to get the parser to work, not to improve > readability, then no-one could do a better job with the current tools. > > And I sincerely want to express my thanks for the working gem that is > LinuxCNC. It is so infuriatingly easy for someone to come along, after > all the hard work of making something good out of nothing, and say "Ya > know, we could improve this bit here." But it isn't done to be a PITA. > > There is a large user base which is happy with the status quo. That is > worth infinitely more than any amount of talk about
Re: [Emc-users] question on gcode parsing
On Wed, 1 Feb 2012 19:34:09 +1100 Erik Christiansen wrote: > On 31.01.12 21:45, dave wrote: > > > To my uncluttered mind ... read blank ... > > is this a good way to set the state of a machine at any given line > > as a precursor to "restart from line no"? > > IIUC¹, running an interpreter through the code from line 1 to a given > line, with all external actions suppressed, ought to "set the state > of a machine" for that line, if the gcode takes no input, and does no > probing. i.e. state is dependent only on the running of the gcode. > (But that's just theory, aka a WAG. Experts may differ.) > > Erik > > ¹ I'm not sure what part of the 129 lines quoted constitute > "this". ;-) > Erik, The theory seems to work. Years ago I wrote such in C but I put in the dropbox and is has gotten lost in my transitions of machines and the apparent disappearance of the dropbox. I was just wondering if there was a better way. Dave -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
I have been working for sometime on a subset of RS274ngc parser. I have a program on my Mac which reads a dxf file and converts it to RS274ngc and allows you to invoke some wizards along with it. The purpose of my parser is to re-read the RS274ngc files I create an allow them to be edited and see the output on the screen in terms of generated 3d paths. Long intro but the reason for this post is to say that writing a parser that will make sense of the current state of RS274ngc code that is acceptable to linuxcnc, is non-trivial. Even the subset that I am trying to handle is not so easy. A EBNF parser should reject code (or at least flag it as error) that is not legal for linuxcnc. As long as we allow people to define gcodes and or mcodes on the fly, it is much more difficult. I am one of those people who doesn't like code written without any whitespace but I have no problem with the current linuxcnc parser/interpreter. My goal was/is to be able to generate code that I like, formatted like I want, and that is still acceptable to linuxcnc. I see no benefit to an EBNF parser that is so loose that it will pass anything that sort of resembles gcode without flagging invalid code. Alan --- Alan Condit 1085 Tierra Ct. Woodburn, OR 97071 Email -- acon...@ipns.com Home-Office (503) 982-0906 -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
Another interesting related trawling find, with a some ideas for syntax evolution: A G code precompiler which parses a language based on C control structures, and generates rs274ngc gcode for LinuxCNC (including O-word constructs etc). It's by a fellow named Lawrence Yu, and its based on PLY/(Python lex yacc), and includes some basic yacc grammar for a G-code block syntax an interesting concept I hadnt thought of: he uses whitespace and whitespace/newline combination as language tokens returned by the scanner it makes a lot of sense to do that for rs274ngc and is a way to deal with Ken's 'drop whitespace squashing' idea in a backwards-compatible/selectable way and within a single parser its very well hidden from google: http://tsemsb.blogspot.com/search/label/GCODE http://tsemsb.blogspot.com/2010/04/cgcc-gcode-with-c-constructs.html The code isnt online in a readable fashion - one need to download and unpack the zip archive: http://sites.google.com/site/cgcccompiler/CGCC_v101.zip -m ps: unfortunately, a quick check of performance of pycparsers with a PLY based scanner/parser suggests it needs serious tuning, at least a faster scanner - a dozen or so example program needs near 0.5 sec of CPU time Am 23.01.2012 um 03:16 schrieb Scott Hasse: > I understand where you are coming from. Word order is not important as >> -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 31.01.12 21:45, dave wrote: > To my uncluttered mind ... read blank ... > is this a good way to set the state of a machine at any given line as a > precursor to "restart from line no"? IIUC¹, running an interpreter through the code from line 1 to a given line, with all external actions suppressed, ought to "set the state of a machine" for that line, if the gcode takes no input, and does no probing. i.e. state is dependent only on the running of the gcode. (But that's just theory, aka a WAG. Experts may differ.) Erik ¹ I'm not sure what part of the 129 lines quoted constitute "this". ;-) -- "The difference between theory and practice is much smaller in theory than in practice..." -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On Wed, 1 Feb 2012 15:14:39 +1100 Erik Christiansen wrote: > On 30.01.12 07:54, Kenneth Lerman wrote: > > On 01/30/2012 12:28 AM, Erik Christiansen wrote: > > > What is being missed here is that the present parser does all > > > that you fear above, just without the maintainability and > > > documentation benefits conferred by a higher level > > > implementation, using powerful tools. > > > > > > Erik > > > > > No. I don't think so. > > > > The current implementation does it; not the current parser. If we > > go back to the compilation/execution analogy, some error conditions > > are detected at run time; not at compile time. > > There is no compile time. Both the current and future parsers are > interpreters only, AIUI. > > > I don't see how the parser can require that G1 has an Fn clause > > defined on the same or some previously executed line. > > Nor can I. It doesn't. AIUI, gcode executes with whatever value of > that modaility is current. It does that now, and any new interpreter > easily does the same. The grammar then _permits_ an Fn clause where > we choose. > > > The parser knows nothing about execution order; only about lexical > > order. Since the Fn might be hidden away in some subroutine, the > > parse might not have seen it. I would think that knowing whether an > > Fn is active is a difficult problem when looking from the outside, > > but a simple problem from the inside of the run time environment. > > (Of course, feel free to prove me wrong.) > > Any "need" to know the run-time state of a modality before run-time is > illusory. That which needs to be known at run-time needs to be known > at run time, not before. It is worth understanding that the run-time > value of a modality is not part of the grammar. I'm not sure what > you're basing these imaginary concerns on, but I can't relate them to > reality, despite some effort :-) > > > Don't get me wrong. I agree that we need a better definition of the > > grammar and a more structured implementation. In general, though, I > > prefer recursive descent parsers such as the present parser that is > > used for each line. I consider the ability to generate excellent > > diagnostic and error messages to be worth the effort of hand coding. > > We usually prefer what we're good at. I'm as guilty of that as the > next bloke. The actual merits of the alternatives have been kicked > about upthread. > > I wouldn't propose replacing the current parser in the forseeable > future. Since there is interest in a more readable input syntax, > expressed several times per year by a subset of LinuxCNC users, I have > upthread already discussed implementing a filter which supplements the > existing parser, but does not replace it. That way, there is scope for > pleasing two groups. > > > I recognize that my control structure (o-word) implementation > > leaves a lot to be desired -- to say the least. About its only > > saving grace is that it enables us to do a lot of things we > > couldn't do before. It must be redone in a way that is obviously > > correct and maintainable. > > As they say, "The perfect is the enemy of the good." An available > practical implementation is superior to any imagined "perfection" > which does not yet exist. If the limitations of the current parser > have forced clutter upon the user, just to get the parser to work, > not to improve readability, then no-one could do a better job with > the current tools. > > And I sincerely want to express my thanks for the working gem that is > LinuxCNC. It is so infuriatingly easy for someone to come along, after > all the hard work of making something good out of nothing, and say "Ya > know, we could improve this bit here." But it isn't done to be a PITA. > > There is a large user base which is happy with the status quo. That is > worth infinitely more than any amount of talk about making the syntax > prettier. The current implementation satisfactorily makes swarf around > the globe. > > I honestly don't think it "must be redone". If we make a filter which > pleases the "new look" enthusiasts, it'll just generate your o-word > code, for input into the current parser. Whether anyone then ever goes > so far as to merge the two, partly depends on how valuable a fully > documented interpreter grammar is. > > > I haven't looked closely at modern automated tools for doing this > > in a few decades. If they let us generate effective diagnostic > > information in a straightforward way, we should be using them. On > > the other hand, the grammar should be simple enough that a hand > > generated recursive descent parser should do fine. > > In practice, the grammar has to be the same as now for the ""old > look", just with optional "#< .>" etc., and optional "Rapid" instead > of "G0" for the new. There cannot be substantial differences, or it's > not just prettified gcode. > > And in your last sentence, s/hand generated/auto generated/. > There is no need to spend time or effort on actua
Re: [Emc-users] question on gcode parsing
On 30.01.12 07:54, Kenneth Lerman wrote: > On 01/30/2012 12:28 AM, Erik Christiansen wrote: > > What is being missed here is that the present parser does all that you > > fear above, just without the maintainability and documentation benefits > > conferred by a higher level implementation, using powerful tools. > > > > Erik > > > No. I don't think so. > > The current implementation does it; not the current parser. If we go > back to the compilation/execution analogy, some error conditions are > detected at run time; not at compile time. There is no compile time. Both the current and future parsers are interpreters only, AIUI. > I don't see how the parser can require that G1 has an Fn clause > defined on the same or some previously executed line. Nor can I. It doesn't. AIUI, gcode executes with whatever value of that modaility is current. It does that now, and any new interpreter easily does the same. The grammar then _permits_ an Fn clause where we choose. > The parser knows nothing about execution order; only about lexical > order. Since the Fn might be hidden away in some subroutine, the parse > might not have seen it. I would think that knowing whether an Fn is > active is a difficult problem when looking from the outside, but a > simple problem from the inside of the run time environment. (Of > course, feel free to prove me wrong.) Any "need" to know the run-time state of a modality before run-time is illusory. That which needs to be known at run-time needs to be known at run time, not before. It is worth understanding that the run-time value of a modality is not part of the grammar. I'm not sure what you're basing these imaginary concerns on, but I can't relate them to reality, despite some effort :-) > Don't get me wrong. I agree that we need a better definition of the > grammar and a more structured implementation. In general, though, I > prefer recursive descent parsers such as the present parser that is used > for each line. I consider the ability to generate excellent diagnostic > and error messages to be worth the effort of hand coding. We usually prefer what we're good at. I'm as guilty of that as the next bloke. The actual merits of the alternatives have been kicked about upthread. I wouldn't propose replacing the current parser in the forseeable future. Since there is interest in a more readable input syntax, expressed several times per year by a subset of LinuxCNC users, I have upthread already discussed implementing a filter which supplements the existing parser, but does not replace it. That way, there is scope for pleasing two groups. > I recognize that my control structure (o-word) implementation leaves a > lot to be desired -- to say the least. About its only saving grace is > that it enables us to do a lot of things we couldn't do before. It must > be redone in a way that is obviously correct and maintainable. As they say, "The perfect is the enemy of the good." An available practical implementation is superior to any imagined "perfection" which does not yet exist. If the limitations of the current parser have forced clutter upon the user, just to get the parser to work, not to improve readability, then no-one could do a better job with the current tools. And I sincerely want to express my thanks for the working gem that is LinuxCNC. It is so infuriatingly easy for someone to come along, after all the hard work of making something good out of nothing, and say "Ya know, we could improve this bit here." But it isn't done to be a PITA. There is a large user base which is happy with the status quo. That is worth infinitely more than any amount of talk about making the syntax prettier. The current implementation satisfactorily makes swarf around the globe. I honestly don't think it "must be redone". If we make a filter which pleases the "new look" enthusiasts, it'll just generate your o-word code, for input into the current parser. Whether anyone then ever goes so far as to merge the two, partly depends on how valuable a fully documented interpreter grammar is. > I haven't looked closely at modern automated tools for doing this in a > few decades. If they let us generate effective diagnostic information in > a straightforward way, we should be using them. On the other hand, the > grammar should be simple enough that a hand generated recursive descent > parser should do fine. In practice, the grammar has to be the same as now for the ""old look", just with optional "#< .>" etc., and optional "Rapid" instead of "G0" for the new. There cannot be substantial differences, or it's not just prettified gcode. And in your last sentence, s/hand generated/auto generated/. There is no need to spend time or effort on actually writing code for the parser. Only code snippets to implement the actions of each leaf, i.e to spit out what we want after interpretation. The O'Reily "Lex & Yacc" book is an easy introduction to using tools to generate lexers and parsers with minima
Re: [Emc-users] question on gcode parsing
On 1/31/2012 1:48 AM, Erik Christiansen wrote: >> > 3) tools that allow one to treat the grammar as an engineering object, >> > e.g., view it, analyze it, manipulate it (refactor, group, etc), and >> > extend it. This area was an arid desert the last time I did any related >> > technical work. > Well, BNF does that, and being more lexically inclined than visually, > I'll admit to doing that sort of stuff for fun. I'm uncertain about your phrase "BNF does that". Are you "doing that sort of stuff" by hand (the way, I'm sure, that Tom Kramer created and checked his production rules for RS274/NGC) or using software tools that can track your work, keep versions, do the sorts of things I mentioned? I don't mean with something like CVS or git, which can track anything because they know nothing, but with a tool that knows the elements of BNF notation. These were totally lacking---my so-called arid desert---when I was working in data-exchange standardization. I'm strongly lexically inclined as well (my wife says it's because I'm strongly left handed; my dad, in turn, used to joke I'm left handed because I was dropped on my head as a baby). Still, it's a bore doing all that "bookkeeping" in text, even if the text is maintained on a computer. If your are using software tools, what tools are they? > If you do it right, often with tools you've written yourself, then tools > are the jet fighter of software development. I totally agree. We used them all the time in the development of software driven by information modeling. The STEP activity created its own cottage industry for tools supporting the EXPRESS modeling language, as has also happened on a much larger scale in the UML world. It's just that when it came to parser generation we had only the downstream tools like lex/yacc. We had to code the grammars by hand in a form acceptable* to the tools. Debugging the grammars was a painful process. > Yes. It's just the length of the journey, the path to be taken, and just > precisely where we stop, that's subject to clarification. Ah, yes, the famous stopping problem. Regards, Kent *sidebar rant: I noticed in a Google search that unnecessary diversity of BNF notations apparently continues. If the grammar of any size is maintained by hand then there is great reluctance to change downstream toolsets if doing so means restating the grammar. I came across a nice paper published last year by Vadim Zaytsev "BNF WAS HERE..." describing the development of a meta notation based on the analysis of 77 published grammars (contained in language standards, etc.). He concludes that their notation allows them to define most of the 42 variant syntactic notations. The result supports their development of automatic grammar recovery tools. -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 30.01.12 12:37, Kent A. Reed wrote: > On 1/30/2012 7:54 AM, Kenneth Lerman wrote: > I would hope for > > 1) a formal description of the grammar we already have. As Erik points > out, the LinuxCNC interpreter implicitly defines a grammar. It's just > hard to tell what the grammar is. It's hard to talk about the language > without a description of it, and as some of Erik's requests have > illustrated, the current description is cryptic. If the only outcome of > the current activity is to come to agreement on this description, I will > consider it a step forward. If others will instruct me in what's legal syntax for any command, then I'll formalise that in a BNF grammar. (We could look at the sample gcode grammars on the web, but they're not ours. (And I have to get ready to go out to dinner tonight, so can't look just now.)) Over a couple of months, we should be able to work out what we believe the LinuxCNC parser wants to see. > 2) a means to express and maintain the grammar in machine-processable > form. Looking at and maintaining text is a bore. BNF is the most universally comprehended, easy to read, and tools can generate code from it. > 3) tools that allow one to treat the grammar as an engineering object, > e.g., view it, analyze it, manipulate it (refactor, group, etc), and > extend it. This area was an arid desert the last time I did any related > technical work. Well, BNF does that, and being more lexically inclined than visually, I'll admit to doing that sort of stuff for fun. > 4) tools like lex/yacc (flex/bison), antlr, etc., that can take this > same machine-processable form and generate all the software goodness > we've talked about. ... > Note that all of this is just ground work that I would hope gets done in > advance of all the other topics that have been mixed into this thread > such as simplified syntax, conversational coding, etc. Yes, that's a wise goal. But it is easy for a parser to make the "#< >" stuff optional, so that users can put it in or omit it, according to taste. That might help keep us motivated, because we can then use it as a filter which provides a benefit beyond documentation. > Note also that it can became an endless academic exercise if not kept > in leash (I came across a 2011 presentation entitled "Why program by > hand in five days what you could spend five years of your life > automating?") In 30 years of software development, I often had team members developing custom tools (including custom compilers for our own state-machine languages), and they always allowed us to finish projects faster, and well within schedule. The very first one blew the socks off colleagues in Munich, when they gave me telecommunications call-control protocol changes daily at 9 a.m., and I had the software rejigged by lunch time, every day. They could then test it in the afternoon. (It was a tiny compiler which understood the problem-domain language used by the protocol designers which did most of my work for me. After I'd written it.) If you do it right, often with tools you've written yourself, then tools are the jet fighter of software development. > And, finally, much of this has already been said by you and others. > Let's just say we're in violent agreement. Yes. It's just the length of the journey, the path to be taken, and just precisely where we stop, that's subject to clarification. ;-) Erik -- "What is wanted is not the will to believe, but the will to find out, which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_, 1928 -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 1/30/2012 7:54 AM, Kenneth Lerman wrote: > On 01/30/2012 12:28 AM, Erik Christiansen wrote: >> On 29.01.12 23:05, Kenneth Lerman wrote: >>> <...> >> <...> >> It is worth understanding that the current parser _does_ have a fixed >> grammar, just like the proposed alternative. The significant difference >> is that in the current parser, it is not revealed in a concise >> human-readable form. >> >> As far as grammars go, the only structural change is transition from an >> amorphous hand-coded parser to a structured auto-generated parser, using >> a formal BNF grammar specification, instead of an undocumented one. >> >> <..> >> As with the rest of the grammar, the code to implement our wishes is >> auto-generated. We just have to get the grammar right. ;-) >> >> <...> >> >> >> What is being missed here is that the present parser does all that you >> fear above, just without the maintainability and documentation benefits >> conferred by a higher level implementation, using powerful tools. >> >> Erik >> > No. I don't think so. > > <...> > Don't get me wrong. I agree that we need a better definition of the > grammar and a more structured implementation. In general, though, I > prefer recursive descent parsers such as the present parser that is used > for each line. I consider the ability to generate excellent diagnostic > and error messages to be worth the effort of hand coding. > > <...> > I haven't looked closely at modern automated tools for doing this in a > few decades. If they let us generate effective diagnostic information in > a straightforward way, we should be using them. On the other hand, the > grammar should be simple enough that a hand generated recursive descent > parser should do fine. > > Regards, > > Ken > > Like Ken, I haven't looked closely either. I would hope for an integrated approach but my google-sense tells me the current situation is still one of disconnected islands of automation (not counting various student exercises; the work described in some recent theses looks quite enticing.) I would hope for 1) a formal description of the grammar we already have. As Erik points out, the LinuxCNC interpreter implicitly defines a grammar. It's just hard to tell what the grammar is. It's hard to talk about the language without a description of it, and as some of Erik's requests have illustrated, the current description is cryptic. If the only outcome of the current activity is to come to agreement on this description, I will consider it a step forward. 2) a means to express and maintain the grammar in machine-processable form. Looking at and maintaining text is a bore. 3) tools that allow one to treat the grammar as an engineering object, e.g., view it, analyze it, manipulate it (refactor, group, etc), and extend it. This area was an arid desert the last time I did any related technical work. 4) tools like lex/yacc (flex/bison), antlr, etc., that can take this same machine-processable form and generate all the software goodness we've talked about. My personal interest lies in the first three. I don't know if there is a commonly accepted phrase---I saw "model-driven engineering" in one student's thesis---but I became a believer when it came time for us to develop a next-generation IGES and discovered that despite the hundreds of pages of documentation we didn't have a formal model we could work from when it came time to talk about what we wanted. (In the end, we simply dumped IGES and created PDES which became STEP. Opinions differ on the appropriateness of that decision.) Note that all of this is just ground work that I would hope gets done in advance of all the other topics that have been mixed into this thread such as simplified syntax, conversational coding, etc. Note also that it can became an endless academic exercise if not kept in leash (I came across a 2011 presentation entitled "Why program by hand in five days what you could spend five years of your life automating?") And, finally, much of this has already been said by you and others. Let's just say we're in violent agreement. Regards, Kent -- 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
Re: [Emc-users] question on gcode parsing
On 01/30/2012 12:28 AM, Erik Christiansen wrote: > On 29.01.12 23:05, Kenneth Lerman wrote: >> Are you suggesting that a three axis machine where there is >> no A axis should have a different grammar than a four axis machine that >> does have an A axis. > No, there is no such constraint in the current parser, and there is no > reason to imagine that there might be in the new. A language like C does > not constrain whether the user can count by twos or threes, and nor is > there any connection between a gcode grammar and the peculiarities of a > specific machine. One grammar handles them all. I think most users > understand that the machine specifics are entirely dealt with by > run-time configuration and the gcode input. > > It is worth understanding that the current parser _does_ have a fixed > grammar, just like the proposed alternative. The significant difference > is that in the current parser, it is not revealed in a concise > human-readable form. > > As far as grammars go, the only structural change is transition from an > amorphous hand-coded parser to a structured auto-generated parser, using > a formal BNF grammar specification, instead of an undocumented one. > >> How would you specify that G1 can have X Y Z values in any order, but >> only one of each? And that in some cases the X Y or Z values are >> optional if they use the same value as a previous line? > That is trivial, and is achieved without writing any program code to do > it. Multiple alternatives, independent of order, and optional > parameters, are the most basic meat of writing a BNF grammar. > > A prior post today shows how a BNF grammar allows alternatives, in any > order. Here is an example of how to allow an optional parameter: > > tool_options: /* Empty */ > | ',' spindle_directive > > As with the rest of the grammar, the code to implement our wishes is > auto-generated. We just have to get the grammar right. ;-) > > If you read the early chapters in O'Reilly's "Lex& Yacc" book, you'll > see how completely straightforward these simple cases are. :-) > >> Remember, of course, that when we have subroutines, a previous >> line means a previously executed line. > An interpreter must retain the state of any modal directive. That's > rather simple. A translator benefits from doing the same, since it can > then generate better error messages. The grammar example posted earlier > today includes an example of this. It's also pretty simple. > > What is being missed here is that the present parser does all that you > fear above, just without the maintainability and documentation benefits > conferred by a higher level implementation, using powerful tools. > > Erik > No. I don't think so. The current implementation does it; not the current parser. If we go back to the compilation/execution analogy, some error conditions are detected at run time; not at compile time. I don't see how the parser can require that G1 has an Fn clause defined on the same or some previously executed line. The parser knows nothing about execution order; only about lexical order. Since the Fn might be hidden away in some subroutine, the parse might not have seen it. I would think that knowing whether an Fn is active is a difficult problem when looking from the outside, but a simple problem from the inside of the run time environment. (Of course, feel free to prove me wrong.) Don't get me wrong. I agree that we need a better definition of the grammar and a more structured implementation. In general, though, I prefer recursive descent parsers such as the present parser that is used for each line. I consider the ability to generate excellent diagnostic and error messages to be worth the effort of hand coding. I recognize that my control structure (o-word) implementation leaves a lot to be desired -- to say the least. About its only saving grace is that it enables us to do a lot of things we couldn't do before. It must be redone in a way that is obviously correct and maintainable. I haven't looked closely at modern automated tools for doing this in a few decades. If they let us generate effective diagnostic information in a straightforward way, we should be using them. On the other hand, the grammar should be simple enough that a hand generated recursive descent parser should do fine. Regards, Ken Ken -- 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
Re: [Emc-users] question on gcode parsing
On 01/30/2012 01:14 AM, Erik Christiansen wrote: > 1) Be mnemonic. i.e. give some farnarckling clue as to what the command > does. (Even "MOV" is orders of magnitude superior to "0x01" or "g01".) > Erik, is this what you meant by "farnarkling": http://mirror.uncyc.org/wiki/Farnarkling ;-) I haven't heard that term in years. > Erik > Mark -- 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
Re: [Emc-users] question on gcode parsing
On 30.01.12 02:33, Steve Blackmore wrote: > On Sun, 29 Jan 2012 10:43:18 -0800, [Kirk] wrote: > > >Regarding messing with the g-code interpreter, my vote is that g-code > >should describe axis position, feedrate; and spindle speed and > >direction, and little more. Everything else should be handled with CAM, > >including canned cycles and such. Less is more. +1 Despite being keen to work towards an optional human readable syntax, it should perform _identically_ to the current one. (All I have implemented so far is the beginnings of a filter, so it _can't_ do anything the current one doesn't.) > >If one insists on "improving" g-code, I would start over with a language > >using keywords rather than letters. The need to to extract the most > >context from single symbols is a throwback from when teletypes ran at > >300 Baud. That is what I have begun to do. The syntax might need to be whacked with a 4lb hammer to displease the least number of users, but it has a number of goals: 1) Be mnemonic. i.e. give some farnarckling clue as to what the command does. (Even "MOV" is orders of magnitude superior to "0x01" or "g01".) 2) Compress the learning curve, by making more explicit what the program does. In industry, the benefit is measurable in dollars. It accrues from 1). 3) Reduce the number of ruined $2000 workpieces. It is infinitely easier to mistype "G0" instead of "G01", than it is make "Rapid" out of "Move". No amount of error checking will pick up a destructive misprogramming in legal syntax. Someone else posted that redundancy can be useful. When it not only gives the commands explicit meaning, but also helps catch typos, then the extra keystrokes can be worth a great deal. > >Just my opinion based on very limited experience. > > Your limited experience is good, IMO. > > My experience comes from working in the commercial world for 40 yrs. > > The simpler the code, the better. It doesn't matter these days how long > the code is, but it has to be simple. The guys running CNC machines in > factories are not rocket scientists. They don't have to be. In a production environment I imagine that there is not always time to cross-check a program edit with another employee. Does it ever happen that "G0" instead of "G01" (or something even more exciting) goes in, due to a momentary lapse in mentally converting what-should-happen to those cryptic codes? > Subroutines are a big NO. They are rarely understandable to anyone else > other than the geek who wrote them, and they are impossible to recover > from if anything goes wrong. Canned cycles aren't much better! If we all had CAM, I don't think we'd labour over hand written subroutines either. It's to cope with work which would otherwise need CAM, that subroutines are a godsend to the amateur user. Erik -- Programs must be written for people to read, and only incidentally for machines to execute.- Abelson and Sussman -- 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
Re: [Emc-users] question on gcode parsing
On 29.01.12 23:05, Kenneth Lerman wrote: > Are you suggesting that a three axis machine where there is > no A axis should have a different grammar than a four axis machine that > does have an A axis. No, there is no such constraint in the current parser, and there is no reason to imagine that there might be in the new. A language like C does not constrain whether the user can count by twos or threes, and nor is there any connection between a gcode grammar and the peculiarities of a specific machine. One grammar handles them all. I think most users understand that the machine specifics are entirely dealt with by run-time configuration and the gcode input. It is worth understanding that the current parser _does_ have a fixed grammar, just like the proposed alternative. The significant difference is that in the current parser, it is not revealed in a concise human-readable form. As far as grammars go, the only structural change is transition from an amorphous hand-coded parser to a structured auto-generated parser, using a formal BNF grammar specification, instead of an undocumented one. > How would you specify that G1 can have X Y Z values in any order, but > only one of each? And that in some cases the X Y or Z values are > optional if they use the same value as a previous line? That is trivial, and is achieved without writing any program code to do it. Multiple alternatives, independent of order, and optional parameters, are the most basic meat of writing a BNF grammar. A prior post today shows how a BNF grammar allows alternatives, in any order. Here is an example of how to allow an optional parameter: tool_options: /* Empty */ | ',' spindle_directive As with the rest of the grammar, the code to implement our wishes is auto-generated. We just have to get the grammar right. ;-) If you read the early chapters in O'Reilly's "Lex & Yacc" book, you'll see how completely straightforward these simple cases are. :-) > Remember, of course, that when we have subroutines, a previous > line means a previously executed line. An interpreter must retain the state of any modal directive. That's rather simple. A translator benefits from doing the same, since it can then generate better error messages. The grammar example posted earlier today includes an example of this. It's also pretty simple. What is being missed here is that the present parser does all that you fear above, just without the maintainability and documentation benefits conferred by a higher level implementation, using powerful tools. Erik -- In general, they do what you want, unless you want consistency. - Larry Wall in the perl man page -- 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
Re: [Emc-users] question on gcode parsing
On 29.01.12 19:31, Michael Haberler wrote: > > Am 29.01.2012 um 16:55 schrieb Erik Christiansen: > > > > What further simplifies the task is that we can, for example, group the > > clauses which are common to G0, G1, etc., and give them a name. The part > > By 'grouping common clauses' do you mean testing for required or > permitted 'words' pertaining to a particular code? Not writing any testing code, no. It's just extracting and re-using some BNF grammar clauses. You'll get that straight off, I'm sure, but for casual readers, an example might help. Back in July, I only got as far as handling a bunch of modal commands, and don't have the G0, G1 example implemented at this instant, so hopefully some of what is already there will serve to illustrate the principle of hiving off a group of leaf clauses into a grammar clause which can be used repeatedly. (Even if the example clause isn't one which we would re-use, it's probably clear enough how easy it is to do the same with one we would.) The following BNF defines a parser-internal "modal_directive", for which it will accept six alternative input clauses: modal_directive: compensation_directive | motion_directive | plane_directive | spindle_directive | tool_directive | workspace_directive ; None of the six are raw input, so they all need to be defined by lower level grammar clauses. Let's take "plane_directive": plane_directive: PLANE XY{ plane = XY ; emit(" G17") ; } | PLANE ZX{ plane = ZX ; emit(" G18") ; } | PLANE YZ{ plane = YZ ; emit(" G19") ; } | PLANE UV{ plane = UV ; emit(" G17.1") ; } | PLANE WU{ plane = WU ; emit(" G18.1") ; } | PLANE VW{ plane = VW ; emit(" G19.1") ; } ; Here, "PLANE" and the following word are both tokens passed by the lexer as it recognises input keywords. The C code in {} is the leaf action needed to complete processing.¹ I'll try to put some time aside to implement G0 and G1 translation, but if we accept that "plane_directive:" can be mimicked by e.g. "common_options:", then there could be a common set for G0 and G1. The parameter clauses for G0 and G1 could then look something like: g0_options: common_options ; g1_options: common_options | feedrate_option | another_option_not_for_g0 | yet_another_option_not_for_g0 ; In practice, common_options may be just "axes" words. Any input on what G1 can take, and G0 can't, is gratefully accepted. (I'm not finding http://www.linuxcnc.org/docs/html/gcode_main.html particularly definitive. ;) I'll take a look at the grammars mentioned upthread, to see if they contain such information. If we have it, I don't know where. Another way to proceed is for anyone interested in a decluttered syntax to pass on what they know about the legal options for one command. After that's implemented, we'll soon find out if any subsequent user disagrees. ¹ Being only a translator from a human-readable input form to gcode, the actions are only translation and remembering the active modality, not least for generating meaningful error messages, such as in this other clause: compensation_modality: RADIUS ON LEFT { if (plane == YZ) error("Illegal plane selected.") emit(" G41") } | RADIUS ON RIGHT { if (plane == YZ) error("Illegal plane selected.") emit(" G42") } | RADIUS OFF { emit(" G40") ; } ; Please don't panic about the input syntax. That is easily made more cryptic and similar to gcode. ;-) Erik -- [Perl is] more like a tank than a mine field. It may be ugly, but it shoots straight and gets you where you're going, if you don't mind a few squashed daisies.- Larry Wall But how much more? -- 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
Re: [Emc-users] question on gcode parsing
On 01/29/2012 10:40 PM, Erik Christiansen wrote: > On 29.01.12 13:30, Kenneth Lerman wrote: >> On 1/29/2012 10:55 AM, Erik Christiansen wrote: >>> What further simplifies the task is that we can, for example, group the >>> clauses which are common to G0, G1, etc., and give them a name. The part >>> of the grammar tree for G1 then gets the handling of the common clauses >>> for free, and we only need to tack on the stuff that G0 doesn't have. >>> Not only does this reduce coding and testing effort, but it ensures >>> consistency across commands, where it should exist. i.e. Anything which >>> is even moderately common in gcode should be specified only once in the >>> grammar. >> I'd rather NOT have the details of what is mandatory and what is >> optional for various g-codes be part of the grammar. Right now, it is >> pretty straightforward to add a new g-code. I don't think we should >> require modifying the grammar to be necessary to add (or change) a g-code. > Oh Deeearr, that's a bit of a problem. > You see, having a BNF grammar specification to eliminate any confusion > over what is legal syntax, is a major purpose of the improvement. > (I believe it is broadly considered a defect in the current parser.) I would put the details of what letter codes are valid for which gcodes in the semantics of the implementation of the particular code (the way it is now). Are you suggesting that a three axis machine where there is no A axis should have a different grammar than a four axis machine that does have an A axis. I don't believe it would be reasonable to specify the total grammar the way you suggest using BNF. How would you specify that G1 can have X Y Z values in any order, but only one of each? And that in some cases the X Y or Z values are optional if they use the same value as a previous line? Remember, of course, that when we have subroutines, a previous line means a previously executed line. Ken > It is worth understanding that it is not possible to intelligently > generate error messages if the grammar fails to specify "what is > mandatory and what is optional for various g-codes". Clearly, that is > the explicit _purpose_ of the grammar. > > Having that BNF grammar specification embedded in the new parser means > that it abides by the language specification. A coder cannot diddle the > parsing significantly in a corner of the code. > > Changing the BNF specification, and filling in the blanks in the leaf > code, _is_ adding or changing the legal gcode. Nothing else needs to be > done, other than update the documentation, since the parser is > auto-generated from the few keystrokes we have added. > > The process is disciplined, highly structured, and minimises hand coding > to the nth degree. There's not a lot of code to wade through. > (Some people will hate it. ;-) > ... > >>> The purpose of the proposed changes is expressly to eliminate such >>> useless visual clutter. My expectation is that if we proceed to >>> implementation, then users will choose to use one syntax or the other. >>> The two need to be equivalent in function, but the old clutter need not >>> adhere to the more readable alternative syntax. >> I find it interesting that you consider removing (what you refer to as) >> the clutter makes the code more readable. I consider having the clutter >> more readable. Removing the clutter makes it easier to write (there are >> fewer keystrokes). > The "change nothing" preference is admirably handled by the existing > parser. The alternative syntax can be expected to be alternative. ;-) > > My interest in this was reawakened by others expressing distaste at the > obfuscating clutter in the current gcode syntax, yet again. When there's > enough interest, we'll do something about it. > >> A typography analogy might be useful. My understanding is that fonts >> with serifs are easier to read than san-serif fonts. I'm sure that it >> has been suggested that serifs be removed to eliminate clutter. > I prefer to avoid that clutter too, and don't use serif fonts. > > If syntax highlighting is used to impose different colours on different > parts of some code within a line, then I have trouble reading it. > >> Redundundancy is sometimes useful. :-) > Hmmm, I don't think it exists in mathematical or programming > expressions, and I abhor it in gcode. To my mind, it only introduces > potential conflict between the parts of the unnecessary duplication. > However, what we have in gcode is not redundancy, but clutter lacking in > any information content of any kind. The variable and function names, as > well as keywords, contain _all_ of the information in their alphanum > names. The surrounding crutches for low capability parsers give nothing to > the user. > > Erik > -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is
Re: [Emc-users] question on gcode parsing
On 29.01.12 13:30, Kenneth Lerman wrote: > On 1/29/2012 10:55 AM, Erik Christiansen wrote: > > What further simplifies the task is that we can, for example, group the > > clauses which are common to G0, G1, etc., and give them a name. The part > > of the grammar tree for G1 then gets the handling of the common clauses > > for free, and we only need to tack on the stuff that G0 doesn't have. > > Not only does this reduce coding and testing effort, but it ensures > > consistency across commands, where it should exist. i.e. Anything which > > is even moderately common in gcode should be specified only once in the > > grammar. > I'd rather NOT have the details of what is mandatory and what is > optional for various g-codes be part of the grammar. Right now, it is > pretty straightforward to add a new g-code. I don't think we should > require modifying the grammar to be necessary to add (or change) a g-code. Oh Deeearr, that's a bit of a problem. You see, having a BNF grammar specification to eliminate any confusion over what is legal syntax, is a major purpose of the improvement. (I believe it is broadly considered a defect in the current parser.) It is worth understanding that it is not possible to intelligently generate error messages if the grammar fails to specify "what is mandatory and what is optional for various g-codes". Clearly, that is the explicit _purpose_ of the grammar. Having that BNF grammar specification embedded in the new parser means that it abides by the language specification. A coder cannot diddle the parsing significantly in a corner of the code. Changing the BNF specification, and filling in the blanks in the leaf code, _is_ adding or changing the legal gcode. Nothing else needs to be done, other than update the documentation, since the parser is auto-generated from the few keystrokes we have added. The process is disciplined, highly structured, and minimises hand coding to the nth degree. There's not a lot of code to wade through. (Some people will hate it. ;-) ... > > The purpose of the proposed changes is expressly to eliminate such > > useless visual clutter. My expectation is that if we proceed to > > implementation, then users will choose to use one syntax or the other. > > The two need to be equivalent in function, but the old clutter need not > > adhere to the more readable alternative syntax. > > I find it interesting that you consider removing (what you refer to as) > the clutter makes the code more readable. I consider having the clutter > more readable. Removing the clutter makes it easier to write (there are > fewer keystrokes). The "change nothing" preference is admirably handled by the existing parser. The alternative syntax can be expected to be alternative. ;-) My interest in this was reawakened by others expressing distaste at the obfuscating clutter in the current gcode syntax, yet again. When there's enough interest, we'll do something about it. > A typography analogy might be useful. My understanding is that fonts > with serifs are easier to read than san-serif fonts. I'm sure that it > has been suggested that serifs be removed to eliminate clutter. I prefer to avoid that clutter too, and don't use serif fonts. If syntax highlighting is used to impose different colours on different parts of some code within a line, then I have trouble reading it. > Redundundancy is sometimes useful. :-) Hmmm, I don't think it exists in mathematical or programming expressions, and I abhor it in gcode. To my mind, it only introduces potential conflict between the parts of the unnecessary duplication. However, what we have in gcode is not redundancy, but clutter lacking in any information content of any kind. The variable and function names, as well as keywords, contain _all_ of the information in their alphanum names. The surrounding crutches for low capability parsers give nothing to the user. Erik -- > Am I correct that perl5-porters is the proper forum for submitting > my ideas? I think you didn't get a reply because you used the terms "correct" and "proper", neither of which has much meaning in Perl culture. :-) -Larry Wall -- 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
Re: [Emc-users] question on gcode parsing
On 29.01.12 11:14, Kent A. Reed wrote: > On 1/29/2012 10:55 AM, Erik Christiansen wrote: > > > <...> > > > > What further simplifies the task is that we can, for example, group the > > clauses which are common to G0, G1, etc., and give them a name. The part > > of the grammar tree for G1 then gets the handling of the common clauses > > for free, and we only need to tack on the stuff that G0 doesn't have. > > Not only does this reduce coding and testing effort, but it ensures > > consistency across commands, where it should exist. i.e. Anything which > > is even moderately common in gcode should be specified only once in the > > grammar. > > Whatever qualms I may have about the difficulty of interjecting > meaningful error messages into an interpreter based on lex'ing and > parsing is overcome by the benefits you point out here. It's good to talk this stuff over then, because we then all have a better understanding of where we can get to from here, with manageable effort and useful improvement. (I.e. "The perfect is the enemy of the good.") I just don't know how to generate enthusiasm for a decluttered amateur-readable syntax which helps us dilettantes up the gcode learning curve. (As a 30-year programming veteran, I can't hack going back to the days when we didn't even have an assembler to convert human-readable mnemonics to the meaningless machine code. There's no difference between "0x01" and "G01" in terms of human-readability.) Error messages can be made meaningful to an experienced user of a tool. They cannot remove the learning curve which a newcomer to the discipline must climb, I find. I've seen some unreasonable expectations expressed by new users, when the primary problem was that they did not understand that they need to understand the language they're using, and make some inferences from the hints provided by a translation tool which is not a tutor. (Well, especially not when it's in beta.) When developing language translators, I usually have implemented basic translation, followed by low-hanging (i.e. easy to implement) error messages, then trickier translation, and finally less obvious error messages. The latter may continue to be added throughout the life of the product. Erik -- Note that this is Perl code and I'm well-aware of the general "unparseable" nature of Perl. A "most works" solution would be fine. - Ovid, on Vim Users ML. -- 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
Re: [Emc-users] question on gcode parsing
On Sun, 29 Jan 2012 10:43:18 -0800, you wrote: >Regarding messing with the g-code interpreter, my vote is that g-code >should describe axis position, feedrate; and spindle speed and >direction, and little more. Everything else should be handled with CAM, >including canned cycles and such. Less is more. > >If one insists on "improving" g-code, I would start over with a language >using keywords rather than letters. The need to to extract the most >context from single symbols is a throwback from when teletypes ran at >300 Baud. > >Just my opinion based on very limited experience. Your limited experience is good, IMO. My experience comes from working in the commercial world for 40 yrs. The simpler the code, the better. It doesn't matter these days how long the code is, but it has to be simple. The guys running CNC machines in factories are not rocket scientists. They don't have to be. Subroutines are a big NO. They are rarely understandable to anyone else other than the geek who wrote them, and they are impossible to recover from if anything goes wrong. Canned cycles aren't much better! None of the modern commercial code I see contains either. Fanuc controls, in the main, can't feed hold in a canned cycle or subroutine and recover. They can with plain Gcode. One of the companies I do a bit for make hydraulic manifolds. They start with a steel forging. It has over 40 holes drilled and reamed in it and ALL are threaded for plugs or hose connectors. The rough forgings are over £1000 each. There are four of these in each machine on a tombstone mount, one of the risky actions is drilling through end to end, (600mm) then reaming with a scissor action floating reamer. The whole process is done with G1 and G0 moves. Not a peck or deep hole cycle in sight. Simple reason is the ops can hear if it goes wrong, stop the machine, jog out, rewind a few lines, change tools and carry on. Some may think it's clever writing fancy subs and others may marvel at how clever you are reducing 100 to 4 lines of code. Those who actually work in the real Engineering world often laugh/curse and think - what a Steve Blackmore -- -- 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
Re: [Emc-users] question on gcode parsing
On 29.01.12 13:12, Kenneth Lerman wrote: > On 1/29/2012 9:02 AM, Erik Christiansen wrote: > > But I haven't seen a troublesome gcode example yet. :-) > Remember that just because a computer can understand a grammar does not > mean that a person can. (Consider the C++ grammar.) Point taken. (And perl is C++ cubed, with even authors of perl books admitting in print that it is execrable. See sig.) Andy's example with "foo" and "oo" is also a prime example. I had no idea what the example was supposed to mean, but a grammar of your choice would parse it according to the specified rules even if neither of us correctly anticipated the outcome. Gcode should be explicit, and therefore readily understood. Obfuscated examples, such as Andy's are demonstrably not human readable, but a parser should not be confused by them, even if we are. My point is that I believe that all legal gcode is eminently parsable, and I have yet to see any supposedly pathological gcode example which is very difficult to parse. > Also, I'd like to add a requirement to have variables with "string" > values (together with some added functions). That's so someone could > write code that does engraving. That sounds like fun, but I'm not sure how you'd get from ascii to the G1 moves to produce any font at all. Isn't ascii to gcode a cam function? "The interpreter doesn't generate gcode." is more or less our primary maxim, AIUI. > Someone commented about the comment syntax -- using parens to delimit > comments -- in a somewhat deprecating manner. I'd suggest that it is > certainly no worse than the /* */ comments in my favorite language. I do > find it useful to be able to embed a comment in the middle of a line; > not just at the end. Ah, yes, shouldn't exclude embedded comments I suppose. How about [This is a comment], or "This comment style frees up () too." It's the conflict with the greater utility of () in functions and expressions, which complicates a parser. Replacing the square brackets with the more conventional parentheses reduces gcode,s weirdness, making it human readable with less mind-twisting when moving from all the other scripting languages an integrator is exposed to. The embryonic human_readable_syntax to gcode translator which I started in july last year, using lex/bison, does use the # as comment delimiter, but I could easily add "This comment style" as well, allowing use of either. It's not an attempt at an alternative interpreter, but would simply be run as a filter. It would need quite some work before being ready for prime time, since the current input syntax is made highly readable by using English words which state what is to happen, rather than cryptic gcode non-mnemonic cryptic numbers. Gcode veterans would hate it with a vengeance. For any chance of broader appeal, I'd have to make it also accept conventional gcode with only decluttering added, I see. I'll have a look at what it'll take to do that. (Just a suite of alternative grammar clauses, one up from the leaf level, I expect.) Erik -- Yes, sometimes Perl looks like line-noise to the uninitiated, but to the seasoned Perl programmer, it looks like checksummed line-noise with a mission in life. - The Llama Book -- 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
Re: [Emc-users] question on gcode parsing
On Sun, 2012-01-29 at 19:08 +, andy pugh wrote: > On 29 January 2012 18:43, Kirk Wallace wrote: > > Regarding messing with the g-code interpreter, my vote is that g-code > > should describe axis position, feedrate; and spindle speed and > > direction, and little more. Everything else should be handled with CAM, > > including canned cycles and such. Less is more. > > Which FOSS, Linux, CAM system would you suggest? > What little code I've created so far is done by hand, Qcad/dxf2gcode or Synergy, but it's not LinuxCNC's fault that there aren't more choices. In my opinion, g-code should be a script for telling the machine how to operate, not a utility for creating or bypassing code. I just want to float the Spartan ideal to try to help keep the interpreter and LinuxCNC from getting bloated. Over the years I've seen good enough software become bloated to the point of needing other programs to make them usable again. I like jumpers instead of Plug-N-Play. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- 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
Re: [Emc-users] question on gcode parsing
On Sun, Jan 29, 2012 at 6:43 PM, Kirk Wallace wrote: > Regarding messing with the g-code interpreter, my vote is that g-code > should describe axis position, feedrate; and spindle speed and > direction, and little more. Everything else should be handled with CAM, > including canned cycles and such. Less is more. > > If one insists on "improving" g-code, I would start over with a language > using keywords rather than letters. The need to to extract the most > context from single symbols is a throwback from when teletypes ran at > 300 Baud. There is no open source cam for 5 axis I know of no other way than hand coding for my machine I NEED better syntax not less syntax Dave Caroline -- 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
Re: [Emc-users] question on gcode parsing
On Jan 29, 2012 12:44 PM, "Kirk Wallace" wrote: > > Regarding messing with the g-code interpreter, my vote is that g-code > should describe axis position, feedrate; and spindle speed and > direction, and little more. Everything else should be handled with CAM, > including canned cycles and such. Less is more. > I would agree if there were an open source CAM that was good. I tried pycam but it is lacking. Given that I can't afford an expensive package I find it pretty easy to just write gcode. Especially for simple things. -- 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
Re: [Emc-users] question on gcode parsing
On 29 January 2012 18:43, Kirk Wallace wrote: > Regarding messing with the g-code interpreter, my vote is that g-code > should describe axis position, feedrate; and spindle speed and > direction, and little more. Everything else should be handled with CAM, > including canned cycles and such. Less is more. Which FOSS, Linux, CAM system would you suggest? -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- 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
Re: [Emc-users] question on gcode parsing
Regarding messing with the g-code interpreter, my vote is that g-code should describe axis position, feedrate; and spindle speed and direction, and little more. Everything else should be handled with CAM, including canned cycles and such. Less is more. If one insists on "improving" g-code, I would start over with a language using keywords rather than letters. The need to to extract the most context from single symbols is a throwback from when teletypes ran at 300 Baud. Just my opinion based on very limited experience. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- 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
Re: [Emc-users] question on gcode parsing
Am 29.01.2012 um 16:55 schrieb Erik Christiansen: > > What further simplifies the task is that we can, for example, group the > clauses which are common to G0, G1, etc., and give them a name. The part By 'grouping common clauses' do you mean testing for required or permitted 'words' pertaining to a particular code? - Michael -- 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
Re: [Emc-users] question on gcode parsing
On 1/29/2012 10:55 AM, Erik Christiansen wrote: > On 29.01.12 14:20, andy pugh wrote: >> On 29 January 2012 14:02, Erik Christiansen wrote: >> oo = 1 >>> OK, "O Codes". They'll all go in a declutter, replaced by their naked >>> keywords, >> No, that is creating a second named parameter in order to be more >> ambiguous later: > Yes, the variable assignment is unmistakable, but the sneaky intent > wasn't. :-) > g1fooZ100 >>> Is there an axis identifier missing here? If it's supposed to be: >>> >>> g1YfooZ100 >> And here is the question? What did I mean? >> >> I was actually meaning feed at the rate defined by the parameter oo, >> but how is the parser to know that is what I wanted rather than there >> being a missing S (for example) in G1 Sfoo Z100 (not a totally random >> case, my machine has a very reluctant S key, I very often type M31000 >> in MDI) > As it should, a parser slavishly applies its grammar to the input which > we _do_ provide, not what we didn't. In the BNF grammar, we need to > specify that a feedrate_clause may appear after a g1, as an alternative > to an axis_motion. That causes the 'f' to be recognised as a keyword, > which in turn causes "oo" to be detected as a variable name. It is > equally straightforward to allow and optional 'S' clause to this part of > the grammar. > > What further simplifies the task is that we can, for example, group the > clauses which are common to G0, G1, etc., and give them a name. The part > of the grammar tree for G1 then gets the handling of the common clauses > for free, and we only need to tack on the stuff that G0 doesn't have. > Not only does this reduce coding and testing effort, but it ensures > consistency across commands, where it should exist. i.e. Anything which > is even moderately common in gcode should be specified only once in the > grammar. I'd rather NOT have the details of what is mandatory and what is optional for various g-codes be part of the grammar. Right now, it is pretty straightforward to add a new g-code. I don't think we should require modifying the grammar to be necessary to add (or change) a g-code. > > To allow removal of the square brackets currently containing an > axis_motion clause, we need alternative clause termination. Upthread I > suggested ';', as is used between elements of a for loop in most > languages. Your line then becomes: > > g1foo;Z100 > > Or if we are in industry, and someone else might need to read it: > > g1 foo; z100 # Either G&F&Z or g&f&z is easier on humans. > > Now a LALR(1) parser can deal not only with that, but also with a > variable named "foo" or "Foo", so long as we configure a stateful lexer, > which is able to look for only a keyword immediately after the G1, and > resume seeing a variable name after the "f" keyword is consumed. > >> I think we should keep the # for all variables. It is what humans >> reading G-code expect to see. > That is admirably achieved by changing nothing, fully maintaining > historical authenticity. I respect such a preference. > > The purpose of the proposed changes is expressly to eliminate such > useless visual clutter. My expectation is that if we proceed to > implementation, then users will choose to use one syntax or the other. > The two need to be equivalent in function, but the old clutter need not > adhere to the more readable alternative syntax. I find it interesting that you consider removing (what you refer to as) the clutter makes the code more readable. I consider having the clutter more readable. Removing the clutter makes it easier to write (there are fewer keystrokes). A typography analogy might be useful. My understanding is that fonts with serifs are easier to read than san-serif fonts. I'm sure that it has been suggested that serifs be removed to eliminate clutter. Redundundancy is sometimes useful. :-) > >> A linked point is that we seem to be discussing mainly human-generated >> G-code, whereas a large proportion of G-code executed by EMC2 machines >> is machine-generated. As well as discussing machine-parsing we also >> might need to consider machine-generation. > Yes, it needs to be considered, but I don't quite see an impact. > Compatible machine-generated gcode is currently in the historical > format, and it is adequately handled by the existing parser. > > The purpose of the decluttered parser is to allow human-generated gcode > to become human readable. If, in time, some machine-generated gcode should > transition to the more readable format, then that's OK too. > > One thing with a lex/bison based interpreter is that the implementation > itself contains a BNF specification of the legal grammar. Whether input > is legit or not is easily looked up in one place. And if error messages > are not sufficiently explicit, then it's fairly easy to see if steps can > easily be taken to fix it. > > Erik > Regards, Ken -- Try before you buy = See
Re: [Emc-users] question on gcode parsing
On 1/29/2012 9:20 AM, andy pugh wrote: > On 29 January 2012 14:02, Erik Christiansen wrote: > >>> oo = 1 >> OK, "O Codes". They'll all go in a declutter, replaced by their naked >> keywords, > No, that is creating a second named parameter in order to be more > ambiguous later: > >>> g1fooZ100 >> Is there an axis identifier missing here? If it's supposed to be: >> >> g1YfooZ100 > And here is the question? What did I mean? > > I was actually meaning feed at the rate defined by the parameter oo, > but how is the parser to know that is what I wanted rather than there > being a missing S (for example) in G1 Sfoo Z100 (not a totally random > case, my machine has a very reluctant S key, I very often type M31000 > in MDI) > > I think we should keep the # for all variables. It is what humans > reading G-code expect to see. > > A linked point is that we seem to be discussing mainly human-generated > G-code, whereas a large proportion of G-code executed by EMC2 machines > is machine-generated. As well as discussing machine-parsing we also > might need to consider machine-generation. > I like the point that you bring out. Not only does this have to be ambiguous, it has to be robust in the case of common errors. One could imagine a language where every utterance was grammatically legal. That would mean that you could never write an illegal program. I don't think I would like that. Redundancy in language can be very useful. Ken -- 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
Re: [Emc-users] question on gcode parsing
Am 29.01.2012 um 15:20 schrieb andy pugh: >> >> g1YfooZ100 > > And here is the question? What did I mean? > > I was actually meaning feed at the rate defined by the parameter oo, > but how is the parser to know that is what I wanted rather than there > being a missing S (for example) in G1 Sfoo Z100 (not a totally random > case, my machine has a very reluctant S key, I very often type M31000 > in MDI) that is what I mean with 'either retain bracketing letters' or go the 'make whitespace significant' route g1YfooZ100 is ambiguous as to the end of the feed variable g1Y Foo Z100 would mean G1Y f# Z100 under the 'make whitespace significant' rule > I think we should keep the # for all variables. It is what humans > reading G-code expect to see. Fine - that's a decision item. - Michael. -- 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
Re: [Emc-users] question on gcode parsing
On 1/29/2012 9:02 AM, Erik Christiansen wrote: > On 29.01.12 12:59, andy pugh wrote: >> On 29 January 2012 12:29, Erik Christiansen wrote: >> >>> While that could be 'de-hashed' without an alternative numbered >>> parameter identifier, I don't see how you'd propose to handle: >>> >>> #43 = foo / #44 >> I am puzzled how you would handle >> foo = 10 > If the concern is that it could be confused with "F 10", then I'll > cheerfully admit that "F" should be a keyword in the grammar, as it is > to us, and so no variable may be named "F". Thus, there is no problem. > > If we imagine a case where disambiguation were not so simple, then a > quick way out is manually coded lookahead. That's not needed here. > >> oo = 1 > OK, "O Codes". They'll all go in a declutter, replaced by their naked > keywords, "sub", "call", "endsub", etc. Each is easily recognised by the > lexer, and a unique token ID passed to the parser, so that it > immediately knows which grammar subclauses apply. > > We won't be able to have a variable called "call", or a function called > "endsub", but "oo" isn't a keyword, so here it's unambiguously a > variable name, since it is preceded by neither "sub" nor "call". > >> g1fooZ100 > Is there an axis identifier missing here? If it's supposed to be: > > g1YfooZ100 > > Then the gcode ends at the numeric - alpha transition. The grammar then > demands some {axis_identifier,magnitude} pairs, optionally with embedded > stuff like feedrate. Thus "Y foo" and "Z 100" are easily picked out, > whether spaced or not. Since there is no '#' in front of "100", it is a > literal numeric. > > There is no parsing complexity in any of these cases. > >> Is it not a significant problem that every single letter of the >> alphabet is already a G-code command? > No, not of itself. So long as we have an unambiguous grammar, then the > parser has no trouble. The grammar tells the parser when a > [xXyYZzUuVvWw] is to be interpreted as an axis ID, rather than the first > letter of a name. To avoid the constraint that a name could not begin > with one of those letters, I would need to employ a stateful lexer, but > that is easy. The parser then fine tunes the lexer's eyesight, token by > token, as it walks along a line of gcode. > > Incidentally, spaces in the input are usually eliminated by one line in > the lexer. The parser never sees spaces, so that one line is all the > space handling there is. (Well, that's how I do it, 'cos it's easier.) > > The parser is automatically generated from the BNF grammar and its > embedded output actions (coded in C), so it's only necessary to write > the lexer, the grammar, and the leaf actions. The fun begins if the > grammar is ambiguous, resulting in conflicts. Debugging that adds to the > entertainment value. > > But I haven't seen a troublesome gcode example yet. :-) > > Erik > Remember that just because a computer can understand a grammar does not mean that a person can. (Consider the C++ grammar.) Also, I'd like to add a requirement to have variables with "string" values (together with some added functions). That's so someone could write code that does engraving. Someone commented about the comment syntax -- using parens to delimit comments -- in a somewhat deprecating manner. I'd suggest that it is certainly no worse than the /* */ comments in my favorite language. I do find it useful to be able to embed a comment in the middle of a line; not just at the end. Ken -- 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
Re: [Emc-users] question on gcode parsing
Am 29.01.2012 um 13:59 schrieb andy pugh: > On 29 January 2012 12:29, Erik Christiansen wrote: > >> While that could be 'de-hashed' without an alternative numbered >> parameter identifier, I don't see how you'd propose to handle: >> >> #43 = foo / #44 > > I am puzzled how you would handle > foo = 10 > oo = 1 > g1fooZ100 > > Is it not a significant problem that every single letter of the > alphabet is already a G-code command? those can be disambiguated through the '=' which makes it an assignment statement wheres the last one is a block the meaning of 'oo' or 'foo' need not be resolved until its clear whether the line is a block or an assignment statement (I *think* ;) -m -- 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
Re: [Emc-users] question on gcode parsing
On 1/29/2012 10:55 AM, Erik Christiansen wrote: > <...> > > What further simplifies the task is that we can, for example, group the > clauses which are common to G0, G1, etc., and give them a name. The part > of the grammar tree for G1 then gets the handling of the common clauses > for free, and we only need to tack on the stuff that G0 doesn't have. > Not only does this reduce coding and testing effort, but it ensures > consistency across commands, where it should exist. i.e. Anything which > is even moderately common in gcode should be specified only once in the > grammar. Whatever qualms I may have about the difficulty of interjecting meaningful error messages into an interpreter based on lex'ing and parsing is overcome by the benefits you point out here. Regards, Kent -- 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
Re: [Emc-users] question on gcode parsing
On 29.01.12 14:20, andy pugh wrote: > On 29 January 2012 14:02, Erik Christiansen wrote: > > >> oo = 1 > > > > OK, "O Codes". They'll all go in a declutter, replaced by their naked > > keywords, > > No, that is creating a second named parameter in order to be more > ambiguous later: Yes, the variable assignment is unmistakable, but the sneaky intent wasn't. :-) > >> g1fooZ100 > > > > Is there an axis identifier missing here? If it's supposed to be: > > > > g1YfooZ100 > > And here is the question? What did I mean? > > I was actually meaning feed at the rate defined by the parameter oo, > but how is the parser to know that is what I wanted rather than there > being a missing S (for example) in G1 Sfoo Z100 (not a totally random > case, my machine has a very reluctant S key, I very often type M31000 > in MDI) As it should, a parser slavishly applies its grammar to the input which we _do_ provide, not what we didn't. In the BNF grammar, we need to specify that a feedrate_clause may appear after a g1, as an alternative to an axis_motion. That causes the 'f' to be recognised as a keyword, which in turn causes "oo" to be detected as a variable name. It is equally straightforward to allow and optional 'S' clause to this part of the grammar. What further simplifies the task is that we can, for example, group the clauses which are common to G0, G1, etc., and give them a name. The part of the grammar tree for G1 then gets the handling of the common clauses for free, and we only need to tack on the stuff that G0 doesn't have. Not only does this reduce coding and testing effort, but it ensures consistency across commands, where it should exist. i.e. Anything which is even moderately common in gcode should be specified only once in the grammar. To allow removal of the square brackets currently containing an axis_motion clause, we need alternative clause termination. Upthread I suggested ';', as is used between elements of a for loop in most languages. Your line then becomes: g1foo;Z100 Or if we are in industry, and someone else might need to read it: g1 foo; z100 # Either G&F&Z or g&f&z is easier on humans. Now a LALR(1) parser can deal not only with that, but also with a variable named "foo" or "Foo", so long as we configure a stateful lexer, which is able to look for only a keyword immediately after the G1, and resume seeing a variable name after the "f" keyword is consumed. > I think we should keep the # for all variables. It is what humans > reading G-code expect to see. That is admirably achieved by changing nothing, fully maintaining historical authenticity. I respect such a preference. The purpose of the proposed changes is expressly to eliminate such useless visual clutter. My expectation is that if we proceed to implementation, then users will choose to use one syntax or the other. The two need to be equivalent in function, but the old clutter need not adhere to the more readable alternative syntax. > A linked point is that we seem to be discussing mainly human-generated > G-code, whereas a large proportion of G-code executed by EMC2 machines > is machine-generated. As well as discussing machine-parsing we also > might need to consider machine-generation. Yes, it needs to be considered, but I don't quite see an impact. Compatible machine-generated gcode is currently in the historical format, and it is adequately handled by the existing parser. The purpose of the decluttered parser is to allow human-generated gcode to become human readable. If, in time, some machine-generated gcode should transition to the more readable format, then that's OK too. One thing with a lex/bison based interpreter is that the implementation itself contains a BNF specification of the legal grammar. Whether input is legit or not is easily looked up in one place. And if error messages are not sufficiently explicit, then it's fairly easy to see if steps can easily be taken to fix it. Erik -- Habit is habit, and not to be flung out of the window by any man, but coaxed down-stairs a step at a time. - Mark Twain, "Pudd'nhead Wilson's Calendar -- 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
Re: [Emc-users] question on gcode parsing
On 29 January 2012 14:02, Erik Christiansen wrote: >> oo = 1 > > OK, "O Codes". They'll all go in a declutter, replaced by their naked > keywords, No, that is creating a second named parameter in order to be more ambiguous later: >> g1fooZ100 > > Is there an axis identifier missing here? If it's supposed to be: > > g1YfooZ100 And here is the question? What did I mean? I was actually meaning feed at the rate defined by the parameter oo, but how is the parser to know that is what I wanted rather than there being a missing S (for example) in G1 Sfoo Z100 (not a totally random case, my machine has a very reluctant S key, I very often type M31000 in MDI) I think we should keep the # for all variables. It is what humans reading G-code expect to see. A linked point is that we seem to be discussing mainly human-generated G-code, whereas a large proportion of G-code executed by EMC2 machines is machine-generated. As well as discussing machine-parsing we also might need to consider machine-generation. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- 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
Re: [Emc-users] question on gcode parsing
On 29.01.12 12:59, andy pugh wrote: > On 29 January 2012 12:29, Erik Christiansen wrote: > > > While that could be 'de-hashed' without an alternative numbered > > parameter identifier, I don't see how you'd propose to handle: > > > > #43 = foo / #44 > > I am puzzled how you would handle > foo = 10 If the concern is that it could be confused with "F 10", then I'll cheerfully admit that "F" should be a keyword in the grammar, as it is to us, and so no variable may be named "F". Thus, there is no problem. If we imagine a case where disambiguation were not so simple, then a quick way out is manually coded lookahead. That's not needed here. > oo = 1 OK, "O Codes". They'll all go in a declutter, replaced by their naked keywords, "sub", "call", "endsub", etc. Each is easily recognised by the lexer, and a unique token ID passed to the parser, so that it immediately knows which grammar subclauses apply. We won't be able to have a variable called "call", or a function called "endsub", but "oo" isn't a keyword, so here it's unambiguously a variable name, since it is preceded by neither "sub" nor "call". > g1fooZ100 Is there an axis identifier missing here? If it's supposed to be: g1YfooZ100 Then the gcode ends at the numeric - alpha transition. The grammar then demands some {axis_identifier,magnitude} pairs, optionally with embedded stuff like feedrate. Thus "Y foo" and "Z 100" are easily picked out, whether spaced or not. Since there is no '#' in front of "100", it is a literal numeric. There is no parsing complexity in any of these cases. > Is it not a significant problem that every single letter of the > alphabet is already a G-code command? No, not of itself. So long as we have an unambiguous grammar, then the parser has no trouble. The grammar tells the parser when a [xXyYZzUuVvWw] is to be interpreted as an axis ID, rather than the first letter of a name. To avoid the constraint that a name could not begin with one of those letters, I would need to employ a stateful lexer, but that is easy. The parser then fine tunes the lexer's eyesight, token by token, as it walks along a line of gcode. Incidentally, spaces in the input are usually eliminated by one line in the lexer. The parser never sees spaces, so that one line is all the space handling there is. (Well, that's how I do it, 'cos it's easier.) The parser is automatically generated from the BNF grammar and its embedded output actions (coded in C), so it's only necessary to write the lexer, the grammar, and the leaf actions. The fun begins if the grammar is ambiguous, resulting in conflicts. Debugging that adds to the entertainment value. But I haven't seen a troublesome gcode example yet. :-) Erik -- ... with proper design, the features come cheaply. This approach is arduous, but continues to succeed.-Dennis Ritchie -- 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
Re: [Emc-users] question on gcode parsing
On 1/29/2012 12:37 AM, Erik Christiansen wrote: > On 25.01.12 21:22, Michael Haberler wrote: >> [this should move to emc-developers, which is why I'm cc'ing there] > It would be a pity if the rest of us were to be excluded. It is a very > interesting discussion, and the "EMC" issue was secretive enough. Doing > the same with possible user syntax improvements seems very unhelpful. > Erik: There's nothing secretive about "emc-developers". Anyone can subscribe to the list and anyone can peruse its archive of messages. (see the Wiki) Perhaps they would feel less like exclusionary clubs had the two lists been named, say, "emc-usage" and "emc-technical" or "emc-internals" to reflect their topical themes rather than their target audiences. I try to judge which list is more appropriate for any new message I compose. On the other hand, I read and respond to messages regardless of where they show up. The record shows the same to be true for Michael and many others. Hence, deeply technical discussions can break out on the emc-users list as the result of an initial question. Less frequently, questions and ensuing discussions typical of new-user problems pop up on "emc-developers". No harm. No foul. For me a bigger problem is the nature of email. We click "reply" and the subject line is copied over directly. This makes clear what message we are responding to but not what part of the message we are responding to. By the second reply, it isn't even clear which message, the original or one of its replies, is being responded to. Case in point: I am talking about administrative functioning of the email lists in response to a point you raised in your message about "question of gcode parsing." This kind of cloaking happens daily, where the content of a series of replies may wander all over the map while the subject line stays distressingly constant. The real world of information and its classification is considerably messier than the theoretical one. Sigh. Regards, Kent -- 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
Re: [Emc-users] question on gcode parsing
On 29 January 2012 12:29, Erik Christiansen wrote: > While that could be 'de-hashed' without an alternative numbered > parameter identifier, I don't see how you'd propose to handle: > > #43 = foo / #44 I am puzzled how you would handle foo = 10 oo = 1 g1fooZ100 Is it not a significant problem that every single letter of the alphabet is already a G-code command? -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- 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
Re: [Emc-users] question on gcode parsing
On 29.01.12 09:31, Michael Haberler wrote: > Am 29.01.2012 um 06:37 schrieb Erik Christiansen: > >> -- > >> $var1 = $foo + 1 > >> $var2 = 10 > >> > >> if $var1 < $var 2 > >>... > >> else > >>... > >> endif > >> -- > > > > Indeedy, but even the '$' is unnecessary. > > I'm not sure whether thats possible in all cases. > > There are several syntactic constructs - blocks, expressions, > assignments and control structures. > The noise in expressions really is only needed within blocks; in > assignments, and expressions within control structure probably can be > completely 'de-noised' and probably 'de-dollared' and partially > 'de-hashed' too;). To 'de-hash' our cleaner gcode, an alternative means of identifying numbered parameters would be required. Otherwise they'd be indistinguishable from simple integers. My personal preference would be to use the '$' freed up from variable names to identify numbered parameters, freeing '#' for the comment delimiter, thus completely disambiguating func (foo + $100) # Comment. > as Ken laid out, the tough decision is disambiguating within blocks by > re-introducing whitespace as delimiter; or stay with using brackets to > delimit expressions. Perhaps I'm failing to imagine sufficiently pathological syntax cases, but the only inescapable need for whitespace floating before my eyes is two consecutive names, and I don't think that occurs in gcode. There will always be either a parenthesis or operator in between, I suspect. > I think its possible to: > - make the bracketing requirement for expressions and assignments in > control structure tests optional; > - drop the #<> requirement for named variables references and > assignments in above; an introducer for numbered params is still > needed > - make the bracketing requirement *within* expressions optional. > - introduce more natural aliases for the EQ/NE/LT etc operators +1 > I'm unsure whether the () comment syntax can be disambiguated from > normal function parameter lists like atan(param); this might need a > backtracking parser or stay with brackets and there isnt much that > gain. I know of no other laguage which has a similar comment kludge. We can also move up to the standard of having an unambiguous comment delimiter. One way is described above. It has the merit of increased consistency with scripting languages encountered by LinuxCNC integrators, reducing language whiplash when we go from one to another. > This is untested conjecture, but I think one could come up with a > grammar which would still parse the current language and be able to > write: > sub func > ;blablah > endsub > > baz = 0.45 > foo = atan[bar * 47.11] ; possible > foo = atan(bar * 47.11) ; unsure - guess not; no much gain either Language insularity does have an ongoing cost. I'd be interested to hear whether the broad user base thinks the last line above looks more like a function, than the preceding one. Running with parallel distinct parsers, and a switch word in the input, has the major advantage that there will be no regression in the old parser due to the new, and grammar conflicts which might arise in a combined parser are effortlessly avoided. Trying to be both Arthur and Martha, at the one time, is usually much more difficult than settling for alternation. > #43 = foo / 10 While that could be 'de-hashed' without an alternative numbered parameter identifier, I don't see how you'd propose to handle: #43 = foo / #44 > if foo > bar >g10 x[foo * baz] > else >g0 y[baz] z#43 x[func[10]] ; likely possible >g0 y[baz] z#43 x[func(10)] ; I guess not > endif > > that's less filling, but in effect requires bracketing expressions ins > block, without requiring it elsewhere, which is a bit confusing. With the minor grammar change outlined above, we could have: g0 y[baz] z$43 x[func(10)] # I guess so. To declutter further, this is readily parsable with a simple grammar: g0 y baz; z $43; x func(10); # Jeez, readable or wot? would not necessitate a ' ' delimiter. And it would be just as parsable if written: g0 ybaz; z$43; xfunc(10); # Not as readable, is it? I might need a stateful lexer to do that easily, but they're simple enough in lex. (So I often use them straight off.) Oh, even the latter form would allow names which start with an axis letter, e.g.: g0 yyaz; z$43; xzunc(10); # Not as readable, is it? > It's one possible route. The other is the 'dont squash whitespace' > route. That is a big decision since the latter isnt backwards > compatible. Still haven't seen a case which needs space delimiters. (While I like whitespace for readability, I don't favour dependence on it in the grammar, because humans can't always find the space bar. "Be demanding in your output, but tolerant of your input." is a good mantra for both a coder and (to a lesser extent) a grammar designer.) ... > > Or mandate a "gcode+" keyword on the first line of input, to > > all
Re: [Emc-users] question on gcode parsing
Am 29.01.2012 um 06:37 schrieb Erik Christiansen: > > >> - wouldnt it be more readable to write: >> >> -- >> $var1 = $foo + 1 >> $var2 = 10 >> >> if $var1 < $var 2 >> ... >> else >>... >> endif >> -- > > Indeedy, but even the '$' is unnecessary. I'm not sure whether thats possible in all cases. There are several syntactic constructs - blocks, expressions, assignments and control structures. The noise in expressions really is only needed within blocks; in assignments, and expressions within control structure probably can be completely 'de-noised' and probably 'de-dollared' and partially 'de-hashed' too;). as Ken laid out, the tough decision is disambiguating within blocks by re-introducing whitespace as delimiter; or stay with using brackets to delimit expressions. I think its possible to: - make the bracketing requirement for expressions and assignments in control structure tests optional; - drop the #<> requirement for named variables references and assignments in above; an introducer for numbered params is still needed - make the bracketing requirement *within* expressions optional. - introduce more natural aliases for the EQ/NE/LT etc operators I'm unsure whether the () comment syntax can be disambiguated from normal function parameter lists like atan(param); this might need a backtracking parser or stay with brackets and there isnt much that gain. This is untested conjecture, but I think one could come up with a grammar which would still parse the current language and be able to write: sub func ;blablah endsub baz = 0.45 foo = atan[bar * 47.11] ; possible foo = atan(bar * 47.11) ; unsure - guess not; no much gain either #43 = foo / 10 if foo > bar g10 x[foo * baz] else g0 y[baz] z#43 x[func[10]] ; likely possible g0 y[baz] z#43 x[func(10)] ; I guess not endif that's less filling, but in effect requires bracketing expressions ins block, without requiring it elsewhere, which is a bit confusing. It's one possible route. The other is the 'dont squash whitespace' route. That is a big decision since the latter isnt backwards compatible. What I could think of is use Scott's idea of a pretty printer for the current language, which could introduce whitespace in blocks as needed. The output would likely be compatible with a 'dont squash whitespace' parser. To stay with Ken's example, it could rewrite: 'X#Y#' into 'X# Y#' after which it is possible to drop the #<> variable delimiters and rewrite again into new syntax: 'XA YB' which would be equivalent to 'X# Y#' in the old syntax (or 'X$A Y$A' - whatever the ensuing inspired discussion diligently shepherded by the EMC board will arrive at ;) that would mean that despite the non-backwards compatible language change automatic upgrade is possible > Both in the code, selected in the config file or on the command line, > perhaps? Or mandate a "gcode+" keyword on the first line of input, to > allow either type at run-time? the latter would break backwards compatibility - that keyword and the rest of the file in 'old rs274ngc' syntax wouldnt parse, at least not now and with old versions of linuxcnc. > Manually, a custom regression testing framework, or move to DejaGnu? IMO the next person to introduce another piece of TCL to linuxcnc should be damned to use Forth exclusively for the rest of her life. The primary benefit of TCL was to get John Ousterhout tenure at Berkeley, but then LSD and BSD came from there too, no coincidence IMO ;) That shouldnt prevent us to look for a more comprehensive regression testing framework. Testing GUI applications 'end to end' is lacking sorely, btw. > If we could move to a BNF specification of our permissible grammar, then > the problem would diminish, I think. An example of a flex/bison parser for something which might eventually resemble rs274ngc, in c++, plumbed into the linuxcnc build system (Submakefile) is in http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/parser-v2-dev Its fairly useless and defunct right now but if somebody wants to play based on an example which builds its a start. The grammar in the fennic.net parser needs a lot of work, and the EBNF from the Tom Kramer paper too. -m -- 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
Re: [Emc-users] question on gcode parsing
On 25.01.12 21:22, Michael Haberler wrote: > [this should move to emc-developers, which is why I'm cc'ing there] It would be a pity if the rest of us were to be excluded. It is a very interesting discussion, and the "EMC" issue was secretive enough. Doing the same with possible user syntax improvements seems very unhelpful. > it just occured to me that a decent parser would give us the > opportunity for a significant language simplification while retaining > backwards compatibility. > An example for the current RS274NGC language with variable references, > expressions and control structures: > -- > # = [# + 1] > # = 10 > > o# if [# lt #] > > o# else > > o# endif > -- > > Note the pathetic amount of syntactic noise Yes, it is ridiculously primitive, presumably to keep parser code small, back when memory cost money. A greater weirdness is that it obstructs our ability to write readable gcode, in the 21st century. > - wouldnt it be more readable to write: > > -- > $var1 = $foo + 1 > $var2 = 10 > > if $var1 < $var 2 > ... > else > ... > endif > -- Indeedy, but even the '$' is unnecessary. My experience is also with lex/bison, and ditching the '$' would not challenge the parser. (Keywords such as "lt", "else", etc. would be identified in the lexer, obviating the need for a variable identifier. Various keyword classes would issue individual tokens, simplifying the parser.) > We have several noise chars per variable (#<>), useless labels > including noise (o#) which do not help in disambiguating, and > useless brackets around expressions, plus, well, fortranesque > operators +1 > now the major reason why this is so is that the current scanner only > does lookahead 1 character, and the parser is inadeaquate; if even > Perl can do it, so should RS274NGC Natively, yacc/bison is also limited to single character lookahead. If more is required, then I have found it necessary to do that manually, in explicit code. With the right amount of work done in the lexer, resulting in a useful set of tokens accompanying the values sent to the parser, virtually all practical problems are fairly easily soluble with a LALR(1) parser. It's not just my experience and O'Reilly's "Lex & Yacc" book, also Wikipedia seems to agree: » Real computer languages can often be expressed as LALR(1) grammars, and in cases where a LALR(1) grammar is insufficient, usually an LALR(2) grammar is adequate. If the parser generator handles only LALR(1) grammars, then the LALR parser will have to interface with some hand-written code when it encounters the special LALR(2) situation in the input language. « It would be interesting to go up against the knottiest "improved gcode" example that we can think of. > A combination of a say flex scanner, bison parser should be able to > parse both examples unambiguously. Moreover, it should tell during the > bison run wether there are any ambiguities or conflicts when such a > language simplification is introduced - it would give a reduce/reduce > message. For instance, one could experiment wether the '$' as variable > introducer is actually necessary (it probably is due to ambiguities > with words in a block). Betcha it's not. ;-) > I understand this is quite different from you pretty printer/lint goal > > If we were to go about this, I think the way to do this is: > > - have both parsers as alternatives Both in the code, selected in the config file or on the command line, perhaps? Or mandate a "gcode+" keyword on the first line of input, to allow either type at run-time? > - add a flag to sai/rs274 to parse a file with old and new parser That's perhaps what is meant here? > - compare outputs for regression tests Manually, a custom regression testing framework, or move to DejaGnu? If we could move to a BNF specification of our permissible grammar, then the problem would diminish, I think. > - when it is clear that no ambiguities are left, move it to mainline as the > default parser A journey of many steps. But interesting. (Perhaps more interesting than making swarf, but please don't tell anyone. ;) Erik -- Programs must be written for people to read, and only incidentally for machines to execute.- Abelson and Sussman -- 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
Re: [Emc-users] question on gcode parsing
Am 28.01.2012 um 16:20 schrieb Kent A. Reed: > On 1/28/2012 9:20 AM, Michael Haberler wrote: >> >> http://fennetic.net/irc/emc3/src/emc/interpreter/ >> > > I suppose a first item of business with the rs274ngc parser code would > be to examine the grammar. As a start, I just looked at the Parser and > rs274ngcTokenTypes files. I don't see a case statement or token for the > "O" word, so some work has been left to the interested student with > regard to the flow-control codes. I don't have time to dig deeper. I'm having a look at bison parser, I'm more familiar with that. The syntax clearly predates O-word control structure; UV missing too. It's pretty much from the EBNF in the RS274NGC_3 paper. This obviously never reached production stage - there are numerous typos although it compiles. Looks ok to shorten the way though. .m -- 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
Re: [Emc-users] question on gcode parsing
On 1/28/2012 9:20 AM, Michael Haberler wrote: > a bit of trawling yielded this: > > http://fennetic.net/irc/emc3/src/emc/interpreter/ > > this has rs274 parsers done with ANTLR, and bison/flex > > I have no idea what the status is > > -m > > Michael: Interesting...the directory bits "irc/emc3" certainly suggests irc conversations on the subject took place some five years ago. Did you look at the stuff in the irc/emc3/docs directory? The file EMC3_Architecture.doc reads like the conversations on this list the past few days. I suppose a first item of business with the rs274ngc parser code would be to examine the grammar. As a start, I just looked at the Parser and rs274ngcTokenTypes files. I don't see a case statement or token for the "O" word, so some work has been left to the interested student with regard to the flow-control codes. I don't have time to dig deeper. That this parser work already exists is another proof of something my thesis adviser told me long ago: there are rarely new ideas, just new attempts to implement them. Regards, Kent -- 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
Re: [Emc-users] question on gcode parsing
a bit of trawling yielded this: http://fennetic.net/irc/emc3/src/emc/interpreter/ this has rs274 parsers done with ANTLR, and bison/flex I have no idea what the status is -m Am 21.01.2012 um 16:31 schrieb Scott Hasse: > All- > > I'm thinking about writing some gcode filters for EMC2 in python, and want > to make these as robust and flexible as possible. To that end, I'm > wondering if there is a typical approach to parsing and validating > arbitrary-format gcode into some sort of canonical form so that a > text-based approach to transformation could be more generically written. I > see there is rs274 python bindings, but the API for that is not clear to > me. It seems it is for parsing gcode, but I don't see how I would use it > to "pretty print" or normalize a gcode file for subsequent processing. > > In particular my first goal is a filter that would take XYZ input and with > some parameters (radius, etc.) wrap the Y axis around an A axis. Any > advice on that particular problem or alternate approaches is certainly > welcome. > > I've very much enjoying EMC2 and am working on my second machine conversion > (an Anilam 3300) using Mesa 5i23 after finishing building and integrating a > stepper-based rotary table: > > http://code.google.com/p/sector67-sandbox/wiki/FourthStepperAxis > > Thus my need for some software to generate A axis gcode :-) > > Thanks much! > > Scott > -- > 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 -- 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
Re: [Emc-users] question on gcode parsing
[this should move to emc-developers, which is why I'm cc'ing there] it just occured to me that a decent parser would give us the opportunity for a significant language simplification while retaining backwards compatibility. An example for the current RS274NGC language with variable references, expressions and control structures: -- # = [# + 1] # = 10 o# if [# lt #] o# else o# endif -- Note the pathetic amount of syntactic noise - wouldnt it be more readable to write: -- $var1 = $foo + 1 $var2 = 10 if $var1 < $var 2 ... else ... endif -- We have several noise chars per variable (#<>), useless labels including noise (o#) which do not help in disambiguating, and useless brackets around expressions, plus, well, fortranesque operators now the major reason why this is so is that the current scanner only does lookahead 1 character, and the parser is inadeaquate; if even Perl can do it, so should RS274NGC A combination of a say flex scanner, bison parser should be able to parse both examples unambiguously. Moreover, it should tell during the bison run wether there are any ambiguities or conflicts when such a language simplification is introduced - it would give a reduce/reduce message. For instance, one could experiment wether the '$' as variable introducer is actually necessary (it probably is due to ambiguities with words in a block). I understand this is quite different from you pretty printer/lint goal If we were to go about this, I think the way to do this is: - have both parsers as alternatives - add a flag to sai/rs274 to parse a file with old and new parser - compare outputs for regression tests - when it is clear that no ambiguities are left, move it to mainline as the default parser - Michael -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On Jan 23, 2012, at 2:17 AM, andy pugh wrote: > Does anyone else indent their loops and subs in G-code? me --- Alan Condit 1085 Tierra Ct. Woodburn, OR 97071 Email -- acon...@ipns.com Home-Office (503) 982-0906 -- 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
Re: [Emc-users] question on gcode parsing
Yes, C style. On Mon, Jan 23, 2012 at 9:47 AM, Martin Dobbins wrote: > > Yes > > Martin > > > Does anyone else indent their loops and subs in G-code? > > > atp > The idea that there is no such thing as objective truth is, quite simply, > wrong. > > > > -- > 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 > -- 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
Re: [Emc-users] question on gcode parsing
Yes Martin Does anyone else indent their loops and subs in G-code? atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- 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
Re: [Emc-users] question on gcode parsing
me On 1/23/2012 4:17 AM, andy pugh wrote: > On 23 January 2012 06:03, Michael Haberler wrote: > >> A prettyprinter might use whitespace to improve output readability, that's >> all > Does anyone else indent their loops and subs in G-code? > -- 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
Re: [Emc-users] question on gcode parsing
Am 23.01.2012 um 11:17 schrieb andy pugh: > On 23 January 2012 06:03, Michael Haberler wrote: > >> A prettyprinter might use whitespace to improve output readability, that's >> all > > Does anyone else indent their loops and subs in G-code? me -- 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
Re: [Emc-users] question on gcode parsing
Am 23.01.2012 um 03:16 schrieb Scott Hasse: > I understand where you are coming from. Word order is not important as > long as you understand how things will be interpreted, and that > understanding matches what actually happens. I think that point alone would make a pretty printer useful. During work on the interpreter I added about half a dozen of distinct execution phases to http://www.linuxcnc.org/docs/devel/html/gcode/overview.html#sec:Order-of-Execution by reading the code. It's now *26* phases for executing a block. There might be a genius out there who looks at a block and divines the execution order according to that list, and I'm not one of those. -- re tools: my past experience *) is mostly with yacc-type tools but looking around it seems there are few options for parser generators which are a) usable from c/c++ and Python and b) are maintained and widely used. ANTLR seems to support both c and python. sell me on it ;) is there a good non-Java, python and/or c++ parser example for a simple language so I understand what we'd be getting into? -Michael *;-) http://www.worldcat.org/title/task-sequencing-language-for-specifying-distributed-ada-systems-tsl-1/oclc/123326453 -- 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
Re: [Emc-users] question on gcode parsing
On 23 January 2012 06:03, Michael Haberler wrote: > A prettyprinter might use whitespace to improve output readability, that's all Does anyone else indent their loops and subs in G-code? -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- 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
Re: [Emc-users] question on gcode parsing
Am 23.01.2012 um 05:56 schrieb dave: > On Sun, 22 Jan 2012 20:16:40 -0600 > Scott Hasse wrote: > >> including things like white space. > > OUCH! I've become quite used to g-code with no white spaces and would > hate to see that forced on user. If it is an option I have no problem. > Just my preference. A new parsing frontent will not change the *accepted* syntax, so there's nothing forced on users A prettyprinter might use whitespace to improve output readability, that's all -m -- 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
Re: [Emc-users] question on gcode parsing
On Sun, 22 Jan 2012 20:16:40 -0600 Scott Hasse wrote: > I understand where you are coming from. Word order is not important > as long as you understand how things will be interpreted, and that > understanding matches what actually happens. I think this discussion > has ranged across several useful applications for a formalized parser, > including: > > 1) My original intent, which is to clean up and normalize gcode input > so that subsequent filters can be much more naive yet still safe. > The parser in this case would fail on malformed input, disambiguate > lines to make things as clear as possible and normalize output, > including things like white space. OUCH! I've become quite used to g-code with no white spaces and would hate to see that forced on user. If it is an option I have no problem. Just my preference. Dave > > I could probably achieve my original use case (wrapping a Y axis > around an A axis) for my specific input files in a very short python > program, and it would serve my purpose. But that is something I > wouldn't feel responsible releasing to others (even with caveats) > because ultimately the code would be used to move machines, etc. As > a result my work would be a development dead end and there would be > no benefit to LinuxCNC. I expect there are one-off translation > scripts like this all over the place that will never see the light of > day because of the lack of robustness. I know I have several. Since > I have some modest experience as a software developer writing > parsers, this is something (along with the Y->A wrapper filter) I can > work on and hopefully contribute back in exchange for all of the > benefits I have accrued from LinuxCNC. > > 2) If this parser/validator existed and was portable, it could be > used to verify gcode in general, serving what some developers call a > "lint" function against gcode > (http://en.wikipedia.org/wiki/Lint_%28software%29). This might have a > positive effect for gcode in the wild, as CAM and motion control > developers could check their output and those considering extending > the language might realize sooner that there are good and bad ways to > extend the language. > > 3) Further, if the parser/validator was sophisticated enough to > understand the LinuxCNC extensions and could be integrated via C/C++, > it could be used as a front-end to the LinucCNC gcode interpretation > process, hopefully providing more robust parsing and validation, more > clear error messages, and better ability for developers to understand > and enhance the parsing process. > > That is the discussion so far at least as far as I understand it. > Michael has done a nice job of providing some requirements for case > #3, which is probably the hardest case, but those requirements impact > how we might go about #1 and #2 as well, in that we would ideally > want to pick a parser generator that would let us re-use the grammar. > > Hope that helps clarify, others please check me if I have this wrong. > > Scott > > On Sun, Jan 22, 2012 at 9:09 AM, John Harris > wrote: > > > I have followed this thread for a day or two, but I cannot > > understand what would be achieved by the parsing. The beauty of > > gcode is its simplicity, a whole block is read and decoded before > > any action is taken, so why is word order important? > > Are you looking for: > > Letter codes without values, or values without letter codes? > > Wrong type values? > > Motion with zero speed set? > > > > I am currently working on a gcode reader in 'C' for a small 3-axis > > machine, and wonder if I am missing something? > > > > __ > > John Harris > > E-Mail jdhhar...@customstage.net > > > > > > On 1/22/2012 2:46 AM, Michael Haberler wrote: > > > Am 22.01.2012 um 04:36 schrieb Scott Hasse: > > > > > >> I agree there is a large and difficult problem with respect to > > >> the > > semantic > > >> checking if the desire is to assure that a program will run > > >> properly. > > I'm > > >> really aiming for a step or two below that, where the code would > > >> be > > parsed, > > >> any semantic checks that can be done statically would be done, > > >> the words would be re-ordered on the blocks in a standard way, > > >> and blocks split > > up in > > >> a standard way to more clearly disambiguate the order of > > >> execution. > > > so you're really looking at source-to-source translation and I > > > guess AST > > rewriting, cool > > > > > >> Unfortunately I don't have the C chops to be of much assistance > > >> with an interpreter rewrite (I am a Java guy primarily, getting > > >> into Python), > > but > > > -^^^ I'm already sit in that pit > > > > > >> I'd be glad to help with work on a common grammar, even though > > >> that is > > only > > >> a small part of the problem, as you say. > > > well, my requirements for a vehicle would be roughly like so: > > > > > > - industrial-strength error diagnosis and recovery, L
Re: [Emc-users] question on gcode parsing
I understand where you are coming from. Word order is not important as long as you understand how things will be interpreted, and that understanding matches what actually happens. I think this discussion has ranged across several useful applications for a formalized parser, including: 1) My original intent, which is to clean up and normalize gcode input so that subsequent filters can be much more naive yet still safe. The parser in this case would fail on malformed input, disambiguate lines to make things as clear as possible and normalize output, including things like white space. I could probably achieve my original use case (wrapping a Y axis around an A axis) for my specific input files in a very short python program, and it would serve my purpose. But that is something I wouldn't feel responsible releasing to others (even with caveats) because ultimately the code would be used to move machines, etc. As a result my work would be a development dead end and there would be no benefit to LinuxCNC. I expect there are one-off translation scripts like this all over the place that will never see the light of day because of the lack of robustness. I know I have several. Since I have some modest experience as a software developer writing parsers, this is something (along with the Y->A wrapper filter) I can work on and hopefully contribute back in exchange for all of the benefits I have accrued from LinuxCNC. 2) If this parser/validator existed and was portable, it could be used to verify gcode in general, serving what some developers call a "lint" function against gcode (http://en.wikipedia.org/wiki/Lint_%28software%29). This might have a positive effect for gcode in the wild, as CAM and motion control developers could check their output and those considering extending the language might realize sooner that there are good and bad ways to extend the language. 3) Further, if the parser/validator was sophisticated enough to understand the LinuxCNC extensions and could be integrated via C/C++, it could be used as a front-end to the LinucCNC gcode interpretation process, hopefully providing more robust parsing and validation, more clear error messages, and better ability for developers to understand and enhance the parsing process. That is the discussion so far at least as far as I understand it. Michael has done a nice job of providing some requirements for case #3, which is probably the hardest case, but those requirements impact how we might go about #1 and #2 as well, in that we would ideally want to pick a parser generator that would let us re-use the grammar. Hope that helps clarify, others please check me if I have this wrong. Scott On Sun, Jan 22, 2012 at 9:09 AM, John Harris wrote: > I have followed this thread for a day or two, but I cannot understand > what would be achieved by the parsing. The beauty of gcode is its > simplicity, a whole block is read and decoded before any action is > taken, so why is word order important? > Are you looking for: > Letter codes without values, or values without letter codes? > Wrong type values? > Motion with zero speed set? > > I am currently working on a gcode reader in 'C' for a small 3-axis > machine, and wonder if I am missing something? > > __ > John Harris > E-Mail jdhhar...@customstage.net > > > On 1/22/2012 2:46 AM, Michael Haberler wrote: > > Am 22.01.2012 um 04:36 schrieb Scott Hasse: > > > >> I agree there is a large and difficult problem with respect to the > semantic > >> checking if the desire is to assure that a program will run properly. > I'm > >> really aiming for a step or two below that, where the code would be > parsed, > >> any semantic checks that can be done statically would be done, the words > >> would be re-ordered on the blocks in a standard way, and blocks split > up in > >> a standard way to more clearly disambiguate the order of execution. > > so you're really looking at source-to-source translation and I guess AST > rewriting, cool > > > >> Unfortunately I don't have the C chops to be of much assistance with an > >> interpreter rewrite (I am a Java guy primarily, getting into Python), > but > > -^^^ I'm already sit in that pit > > > >> I'd be glad to help with work on a common grammar, even though that is > only > >> a small part of the problem, as you say. > > well, my requirements for a vehicle would be roughly like so: > > > > - industrial-strength error diagnosis and recovery, LALR(1) capable > > - can generate a C/C++ scanner/parser from grammer, lexical definition > > - the parser/scanner can be used from C/C++ or Python > > - optional parse tree generation a plus > > - mainstream/widely used code base a plus > > > > that probably suggests some bison or byacc base; I'd refrain from a > Python-only solution like PLY because that's bound to diverge from the > current interpreter since it cant be easily used a frontend; however, there > was some
Re: [Emc-users] question on gcode parsing
On 1/22/2012 4:46 AM, Michael Haberler wrote: > well, my requirements for a vehicle would be roughly like so: > > - industrial-strength error diagnosis and recovery, LALR(1) capable > - can generate a C/C++ scanner/parser from grammer, lexical definition > - the parser/scanner can be used from C/C++ or Python > - optional parse tree generation a plus > - mainstream/widely used code base a plus > > that probably suggests some bison or byacc base; I'd refrain from a > Python-only solution like PLY because that's bound to diverge from the > current interpreter since it cant be easily used a frontend; however, there > was some discussion about moving the interpreter to fully-Python. I think > thats overly ambitious given the resources though. Michael: I think your list of requirements is a good one and the goal being discussed admirable. I just feel an urge to throw out a caution about your first requirement. I never got past idly playing with the primordial Unix tools lex and yacc but I when I was actively engaged in the fledgling ISO/STEP activity I watched closely as one of NIST's best programmers constructed a reference implementation of a compiler for EXPRESS, the language the STEP committee developed for expressing information models. He used all the classic compiler construction techniques of the late 1980s. You'd think he was working against your list of requirements---or the "dragon book." The result was a program that was excellent in a maddening way. If the input schema were correct, the compiler would run to completion and create lots of "stuff" that was needed in the creation of software tools to work with STEP data. It was widely used inside and outside NIST in the creation of production code. However, if the input schema were incorrect, the compiler would effectively roll over on its back and die. Sure, it emitted error messages but they were obtuse and seldom useful. The folks in the ISO/STEP committee writing EXPRESS schemas for their various application protocols went crazy trying to use his compiler as a diagnostic tool. Their mode of operation was, write a schema, submit, amend the schema, submit, looping as many times as needed to get the compiler to stop failing. I had conversations with the author about the need for a "student" compiler---similar in concept to the Waterloo FORTRAN compilers of the 1960s and 1970s [you youngsters can look them up]---that provided copious and useful error and warning messages. His response was that 1) it was much harder to say what is wrong than to say something is wrong and 2) there was no resource to do all the additional work required. (Actually there was also a 3---if I were so committed to the idea, why didn't I "just do it"?) In particular, he convinced me it is generally difficult to implement meaningful error messages in an LALR parser. (Something I've since read in various books.) OK, so EXPRESS is a much more complicated language but I think the situation may be similar with G-code. To develop 'industrial-strength error diagnosis and recovery" requires great discipline. I suspect it might even be better not to use the lex/yacc (flex/bison) approach at all if one is trying to develop a stand-alone diagnostic tool similar to "lint". But, hey, this is just one man's opinion. The first thing I would do if I were determined to go this route is to take the fledging grammar from Tom Kramer's paper, amend it as necessary to reflect the LinuxCNC additions to RS274/NGC (testing, of course, to see that the result is a valid BNF grammar), pass it through the toolchain of choice, and see what it gives me to work with. I suppose the current LinuxCNC interpreter was heavily influenced by Tom Kramer's original RS274/NGC interpreter code. There's a late-model version of this code at http://code.google.com/p/rs274ngc/ (aside-This version has obviously been touched by others since it now bears a copyright statement by Mark Pictor, whom I do not know. The original NIST code was not subject to copyright.) I have no idea whether Tom passed his grammar through lex/yacc in the creation of his intepreter but you can ask him or Mark Pictor. Their email addresses are listed on the Google project page. > I have zero Java clue and would try to avoid adding another language to the > linuxcnc language plethora, which needs to be pruned rather than be added to I absolutely agree. In the early days of LinuxCNC development, one critic in particular returned to this complaint again and again. I see it as the price one pays for open-source development in a widely distributed, sparsely populated community that changes over time. One never knows what will be the language preference of the person with the next great idea (of course this only matters if the person is sufficiently committed to the idea to implement it). We already have shell scripts, C, C++, tcl/tk, Python (what did I leave out?). Let's not add Java i
Re: [Emc-users] question on gcode parsing
I have followed this thread for a day or two, but I cannot understand what would be achieved by the parsing. The beauty of gcode is its simplicity, a whole block is read and decoded before any action is taken, so why is word order important? Are you looking for: Letter codes without values, or values without letter codes? Wrong type values? Motion with zero speed set? I am currently working on a gcode reader in 'C' for a small 3-axis machine, and wonder if I am missing something? __ John Harris E-Mail jdhhar...@customstage.net On 1/22/2012 2:46 AM, Michael Haberler wrote: > Am 22.01.2012 um 04:36 schrieb Scott Hasse: > >> I agree there is a large and difficult problem with respect to the semantic >> checking if the desire is to assure that a program will run properly. I'm >> really aiming for a step or two below that, where the code would be parsed, >> any semantic checks that can be done statically would be done, the words >> would be re-ordered on the blocks in a standard way, and blocks split up in >> a standard way to more clearly disambiguate the order of execution. > so you're really looking at source-to-source translation and I guess AST > rewriting, cool > >> Unfortunately I don't have the C chops to be of much assistance with an >> interpreter rewrite (I am a Java guy primarily, getting into Python), but > -^^^ I'm already sit in that pit > >> I'd be glad to help with work on a common grammar, even though that is only >> a small part of the problem, as you say. > well, my requirements for a vehicle would be roughly like so: > > - industrial-strength error diagnosis and recovery, LALR(1) capable > - can generate a C/C++ scanner/parser from grammer, lexical definition > - the parser/scanner can be used from C/C++ or Python > - optional parse tree generation a plus > - mainstream/widely used code base a plus > > that probably suggests some bison or byacc base; I'd refrain from a > Python-only solution like PLY because that's bound to diverge from the > current interpreter since it cant be easily used a frontend; however, there > was some discussion about moving the interpreter to fully-Python. I think > thats overly ambitious given the resources though. > > I have zero Java clue and would try to avoid adding another language to the > linuxcnc language plethora, which needs to be pruned rather than be added to > > I'd be interested what you think. > > - Michael > > > > > > -- > 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 > -- 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
Re: [Emc-users] question on gcode parsing
On 01/22/2012 10:46 AM, Michael Haberler wrote: > well, my requirements for a vehicle would be roughly like so: > > - industrial-strength error diagnosis and recovery, LALR(1) capable > - can generate a C/C++ scanner/parser from grammer, lexical definition > - the parser/scanner can be used from C/C++ or Python > - optional parse tree generation a plus > - mainstream/widely used code base a plus Maybe you avoid the bnf->C++ step, using some spirit http://www.boost.org/doc/libs/1_48_0/libs/spirit/doc/html/index.html (no pun intended) *am* - Andrea Montefusco iw0hdvhttp://www.montefusco.com tel: +393356992791 fax: +390623318709 - -- 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
Re: [Emc-users] question on gcode parsing
Am 22.01.2012 um 04:36 schrieb Scott Hasse: > I agree there is a large and difficult problem with respect to the semantic > checking if the desire is to assure that a program will run properly. I'm > really aiming for a step or two below that, where the code would be parsed, > any semantic checks that can be done statically would be done, the words > would be re-ordered on the blocks in a standard way, and blocks split up in > a standard way to more clearly disambiguate the order of execution. so you're really looking at source-to-source translation and I guess AST rewriting, cool > Unfortunately I don't have the C chops to be of much assistance with an > interpreter rewrite (I am a Java guy primarily, getting into Python), but -^^^ I'm already sit in that pit > I'd be glad to help with work on a common grammar, even though that is only > a small part of the problem, as you say. well, my requirements for a vehicle would be roughly like so: - industrial-strength error diagnosis and recovery, LALR(1) capable - can generate a C/C++ scanner/parser from grammer, lexical definition - the parser/scanner can be used from C/C++ or Python - optional parse tree generation a plus - mainstream/widely used code base a plus that probably suggests some bison or byacc base; I'd refrain from a Python-only solution like PLY because that's bound to diverge from the current interpreter since it cant be easily used a frontend; however, there was some discussion about moving the interpreter to fully-Python. I think thats overly ambitious given the resources though. I have zero Java clue and would try to avoid adding another language to the linuxcnc language plethora, which needs to be pruned rather than be added to I'd be interested what you think. - Michael -- 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
Re: [Emc-users] question on gcode parsing
Chris Radek wrote: > > But for a modern gcode or for the linuxcnc gcode in particular, this > is not the slightest bit true, and it is a disservice for those in the > know to say it, since inexperienced people hearing it will try to > write regexp-based gcode parsers or other foolishness, and then will > encounter something like > OK, I guess I should have restricted my comment to what I thought the original post was about, which was converting code from a general CAD/CAM system for some special cases. I think the OP was wanting to rotate a part generated by a CAD system he doesn't have 90 degrees in the XY plane. That should be pretty easy to do. I do not know of any CAD/CAM system that produces code using all the math, variable arithmetic and subroutine features of EMC's flavor of G-code. I agree that a "general parser" that can handle any valid EMC syntax that you could throw at it could be quite a bit more difficult. Jon -- 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
Re: [Emc-users] question on gcode parsing
Ed Nisley wrote: > On Sat, 2012-01-21 at 12:44 -0600, Jon Elson wrote: > >> Every numeric value is preceded by a letter telling what it is. >> > > Except in the wonderful world of RepRap, wherein they're now > (contemplating?) dual-extruder "G-Code" with multiple numeric values > after the E axis to mix / simultaneously extrude multiple materials: > > I believe that is a serious enough departure from RS274-D that you can no longer call it G-code. > http://reprap.org/wiki/G-code#M160:_Number_of_mixed_materials > > The E axis must then absorb a linear "distance" of filament, plus the > mix fractions for each material. > > The RepRap dialect seems to be diverging fairly rapidly from what the > LinuxCNC parser understands; in particular, their myriad M codes look > like a problem. > EMC diverged from strict RS274-D in a couple places. I think the comments are compliant, but the way all the in-line arithmetic and use of variables work is probably not compliant. But, then, there really was no good structure for that functionality anyway. Jon -- 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
Re: [Emc-users] question on gcode parsing
I agree there is a large and difficult problem with respect to the semantic checking if the desire is to assure that a program will run properly. I'm really aiming for a step or two below that, where the code would be parsed, any semantic checks that can be done statically would be done, the words would be re-ordered on the blocks in a standard way, and blocks split up in a standard way to more clearly disambiguate the order of execution. This would let through plenty of bad programs, but for me it would still be of value to me when writing gcode filters/post processors, as they could then be much more naive (or conversely take advantage of the parse tree and be more sophisticated) than the post processor macro approach I tend to see from CAM vendors. Unfortunately I don't have the C chops to be of much assistance with an interpreter rewrite (I am a Java guy primarily, getting into Python), but I'd be glad to help with work on a common grammar, even though that is only a small part of the problem, as you say. Scott On Sat, Jan 21, 2012 at 9:14 PM, Michael Haberler wrote: > > Am 22.01.2012 um 03:17 schrieb Scott Hasse: > > > Perhaps it is a lost cause, but having some sort of > > what I would call a "gcode lint" tool would allow people who sometimes > take > > a naive approach to gcode extension to have an reality check. > > a parser with one of the mentioned tools surely can be done > > however, from a "gcode lint" perspective the parser only might be of > limited value because syntax is the easy part, especially with postwar tools > > note that many syntactic correct G-code programs may fail execution, > because combinations of legit syntactic constructs and > interpreter/machine/config state may be invalid > > the tough part is the semantic checking, where a scanner/parser generator > isnt much help; there's not much wiggling around replicating the execution > model and state, which basically leads you to a rewrite of the existing > interpreter > > -- > > that might be a worthwhile project in its own though because the current > interpreter doesnt exactly use bleeding-edge scanning & parsing practices, > leading to a steep learning curve and lots of oddities > > drop me a note if you're interested > > -m > > > > > -- > 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 > -- 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
Re: [Emc-users] question on gcode parsing
Am 22.01.2012 um 03:17 schrieb Scott Hasse: > Perhaps it is a lost cause, but having some sort of > what I would call a "gcode lint" tool would allow people who sometimes take > a naive approach to gcode extension to have an reality check. a parser with one of the mentioned tools surely can be done however, from a "gcode lint" perspective the parser only might be of limited value because syntax is the easy part, especially with postwar tools note that many syntactic correct G-code programs may fail execution, because combinations of legit syntactic constructs and interpreter/machine/config state may be invalid the tough part is the semantic checking, where a scanner/parser generator isnt much help; there's not much wiggling around replicating the execution model and state, which basically leads you to a rewrite of the existing interpreter -- that might be a worthwhile project in its own though because the current interpreter doesnt exactly use bleeding-edge scanning & parsing practices, leading to a steep learning curve and lots of oddities drop me a note if you're interested -m -- 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
Re: [Emc-users] question on gcode parsing
Am 22.01.2012 um 03:31 schrieb andy pugh: > There is a standalone interpreter in the LinuxCNC source, though I am > not sure what it is for, or how it works, or if it works any more. Nor > is it in Python. In fact, I don't know why I am bothering, but I guess > I got this far, and it's now only Ctrl-V > http://git.linuxcnc.org/gitweb?p=emc2.git;a=tree;f=src/emc/sai;h=c01f9e6223e3b713b68f9077c61cf27bdc34dadc;hb=HEAD this is the linuxcnc interpreter, just linked with a 'text output only' canon (aka machine primitives) layer to try it out: $ ./rs274 -g executing 1 N. USE_LENGTH_UNITS(CANON_UNITS_MM) 2 N. SET_G5X_OFFSET(1, 0., 0., 0., 0., 0., 0.) 3 N. SET_G92_OFFSET(0., 0., 0., 0., 0., 0.) 4 N. SET_XY_ROTATION(0.) 5 N. SET_FEED_REFERENCE(CANON_XYZ) READ => g0x10y10 6 N. STRAIGHT_TRAVERSE(10., 10., 0., 0., 0., 0.) READ => it is used extensively in automated tests when 'runtests' is executed (that's the stuff nobody likes to write, which is why rs274 is terra incognita ;) -m -- 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
Re: [Emc-users] question on gcode parsing
On 21 January 2012 15:31, Scott Hasse wrote: > To that end, I'm > wondering if there is a typical approach to parsing and validating > arbitrary-format gcode into some sort of canonical form There is a standalone interpreter in the LinuxCNC source, though I am not sure what it is for, or how it works, or if it works any more. Nor is it in Python. In fact, I don't know why I am bothering, but I guess I got this far, and it's now only Ctrl-V http://git.linuxcnc.org/gitweb?p=emc2.git;a=tree;f=src/emc/sai;h=c01f9e6223e3b713b68f9077c61cf27bdc34dadc;hb=HEAD -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- 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
Re: [Emc-users] question on gcode parsing
In the absence of an existing solution that is basically my plan as stated above with antlr, which can generate a python parser. Although once the grammar is codified, there is no shortage of parser generators that could be applied. Some of the reasons Chris points out above lie at the heart of my motivation as well. Perhaps it is a lost cause, but having some sort of what I would call a "gcode lint" tool would allow people who sometimes take a naive approach to gcode extension to have an reality check. I can certainly say I didn't think there was actually a gcode specification until long after I was exposed to various flavors of gcode in the wild. I think that is probably common, but perhaps not good for consistency of extension. The rs274 bindings seem interesting but from what I can tell are geared toward generating motion type commands (and backplots), and as a native binding don't really lend themselves well to being a portable parser/verifier. Appreciate the input from all so far! Scott On Sat, Jan 21, 2012 at 7:36 PM, Michael Haberler wrote: > > > On Sat, Jan 21, 2012 at 12:44:14PM -0600, Jon Elson wrote: > > > >> G-code is extremely easy to parse. Every numeric value is preceded by a > >> letter telling what it is. > > The LinuxCNC dialect is a context-free language at least with respect to > expressions and control structures and as such cannot be parsed with > regular expressions, or by looking at letters (which is equivalent to > regexes in expressive power). > > to build a parser, the best route IMO would be to use a flex/bison type > tool combination for C/C++; for Python tools can be found here: > http://wiki.python.org/moin/LanguageParsing (unsure what would be the > tool of choice these days; Yapps is already used for comp in LinuxCNC) > > It would be useful longer term to have such a grammer & scanner > combination to serve both as a concise executable language definition, and > as a basis for both LinuxCNC and other tools (like CAM programs) as well. > > -- > > to just parse a program for backplot-type purposes, you might look into > using the rs274ngc module which sports Python callbacks for machine > primitives. An example can be found here: > http://git.mah.priv.at/gitweb/rs274-python.git > > - Michael > > > > > -- > 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 > -- 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
Re: [Emc-users] question on gcode parsing
> On Sat, Jan 21, 2012 at 12:44:14PM -0600, Jon Elson wrote: > >> G-code is extremely easy to parse. Every numeric value is preceded by a >> letter telling what it is. The LinuxCNC dialect is a context-free language at least with respect to expressions and control structures and as such cannot be parsed with regular expressions, or by looking at letters (which is equivalent to regexes in expressive power). to build a parser, the best route IMO would be to use a flex/bison type tool combination for C/C++; for Python tools can be found here: http://wiki.python.org/moin/LanguageParsing (unsure what would be the tool of choice these days; Yapps is already used for comp in LinuxCNC) It would be useful longer term to have such a grammer & scanner combination to serve both as a concise executable language definition, and as a basis for both LinuxCNC and other tools (like CAM programs) as well. -- to just parse a program for backplot-type purposes, you might look into using the rs274ngc module which sports Python callbacks for machine primitives. An example can be found here: http://git.mah.priv.at/gitweb/rs274-python.git - Michael -- 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
Re: [Emc-users] question on gcode parsing
On Sat, Jan 21, 2012 at 12:44:14PM -0600, Jon Elson wrote: > G-code is extremely easy to parse. Every numeric value is preceded by a > letter telling what it is. It depends what variant. There may be some this simple, for instance variants that papertape-reading NC machines used are probably close. But for a modern gcode or for the linuxcnc gcode in particular, this is not the slightest bit true, and it is a disservice for those in the know to say it, since inexperienced people hearing it will try to write regexp-based gcode parsers or other foolishness, and then will encounter something like g20#1=0 g#1x#1y#1f100 o100 repeat[100] g91g1x.01#1=[#1+.01] g90ysin[#1*360] o100 endrepeat m2 where without trying too hard, the only line following that rule is the last one. > In EMC, there are some special cases like comments and > variables, introduced by ( and #. Yes, and many many other special cases. -- 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
Re: [Emc-users] question on gcode parsing
On Sat, 2012-01-21 at 21:27 +0100, Michael Haberler wrote: > LinuxCNC in the chipmaking corner of the CNC universe. Which it does exceedingly well! For a number of reasons, I don't like the Arduino-based motion control that's common to DIY 3D printers and would vastly prefer LinuxCNC for the high-performance printer that's on my far back burner. The language is close enough, right now, but it'd take some effort to make the answer come out right; which is why I'm spring-loaded to notice discussions about parsers. Returning to my lurking niche... -- Ed http://softsolder.com -- 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
Re: [Emc-users] question on gcode parsing
Am 21.01.2012 um 20:10 schrieb Ed Nisley: > > The RepRap dialect seems to be diverging fairly rapidly from what the > LinuxCNC parser understands; in particular, their myriad M codes look > like a problem. new M-codes are really easy to introduce into the LinuxCNC G-code interpreter here's an example where the semantics of the new code is defined by an O-word procedure; alternatively by Python: http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_an_minimal_example_remapped_code --- the issue IMO is only marginally technical - like the lack of extensibility or plugin capability at the language or UI layers. I cannot discern any current plans of LinuxCNC project beyond the fabrication of next release, or any planning discussion for that matter. And outreach into fields like the reprap community doesnt happen by incidental interest alone. So there you have it: LinuxCNC in the chipmaking corner of the CNC universe. - Michael -- 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
Re: [Emc-users] question on gcode parsing
I understand the basic parsing for the majority of common cases can be done fairly easily, but this seems rather error-prone for something that will eventually be moving a machine. I am hoping to build something that is more robust for handling, e.g. inline comments and all of the other special cases present in the specification. I then want to expand it further to perform validation and normalization of the gcode, splitting lines, etc. There is seemingly a grammar for the language that could be used to http://www.isd.mel.nist.gov/documents/kramer/RS274VGER_11.pdf around page 60. Unless something like this exists, my plan would be to use a parser generator like antlr to build a parser using that grammar, and then implement the validation on top of that, verifying using for instance the modal group rules here: http://www.linuxcnc.org/docview/html/gcode_overview.html And ordering things per the actual order of execution rules. My hope is that then I will be able to safely use a simple text-based transformation against the output of this process after the file has been parsed, normalized and validated. I am hoping someone at some point did most of that work, though, in a way that can be used from python in EMC2. Hope that helps clarify, Scott On Sat, Jan 21, 2012 at 1:10 PM, Ed Nisley wrote: > On Sat, 2012-01-21 at 12:44 -0600, Jon Elson wrote: > > Every numeric value is preceded by a letter telling what it is. > > Except in the wonderful world of RepRap, wherein they're now > (contemplating?) dual-extruder "G-Code" with multiple numeric values > after the E axis to mix / simultaneously extrude multiple materials: > > http://reprap.org/wiki/G-code#M160:_Number_of_mixed_materials > > The E axis must then absorb a linear "distance" of filament, plus the > mix fractions for each material. > > The RepRap dialect seems to be diverging fairly rapidly from what the > LinuxCNC parser understands; in particular, their myriad M codes look > like a problem. > > -- > Ed > http://softsolder.com > > > > > -- > 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 > -- 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
Re: [Emc-users] question on gcode parsing
On Sat, 2012-01-21 at 12:44 -0600, Jon Elson wrote: > Every numeric value is preceded by a letter telling what it is. Except in the wonderful world of RepRap, wherein they're now (contemplating?) dual-extruder "G-Code" with multiple numeric values after the E axis to mix / simultaneously extrude multiple materials: http://reprap.org/wiki/G-code#M160:_Number_of_mixed_materials The E axis must then absorb a linear "distance" of filament, plus the mix fractions for each material. The RepRap dialect seems to be diverging fairly rapidly from what the LinuxCNC parser understands; in particular, their myriad M codes look like a problem. -- Ed http://softsolder.com -- 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
Re: [Emc-users] question on gcode parsing
Scott Hasse wrote: > All- > > I'm thinking about writing some gcode filters for EMC2 in python, and want > to make these as robust and flexible as possible. To that end, I'm > wondering if there is a typical approach to parsing and validating > arbitrary-format gcode into some sort of canonical form so that a > text-based approach to transformation could be more generically written. G-code is extremely easy to parse. Every numeric value is preceded by a letter telling what it is. In EMC, there are some special cases like comments and variables, introduced by ( and #. Jon -- 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
[Emc-users] question on gcode parsing
All- I'm thinking about writing some gcode filters for EMC2 in python, and want to make these as robust and flexible as possible. To that end, I'm wondering if there is a typical approach to parsing and validating arbitrary-format gcode into some sort of canonical form so that a text-based approach to transformation could be more generically written. I see there is rs274 python bindings, but the API for that is not clear to me. It seems it is for parsing gcode, but I don't see how I would use it to "pretty print" or normalize a gcode file for subsequent processing. In particular my first goal is a filter that would take XYZ input and with some parameters (radius, etc.) wrap the Y axis around an A axis. Any advice on that particular problem or alternate approaches is certainly welcome. I've very much enjoying EMC2 and am working on my second machine conversion (an Anilam 3300) using Mesa 5i23 after finishing building and integrating a stepper-based rotary table: http://code.google.com/p/sector67-sandbox/wiki/FourthStepperAxis Thus my need for some software to generate A axis gcode :-) Thanks much! Scott -- 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