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
