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, 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
