On 29.01.12 14:20, andy pugh wrote:
> On 29 January 2012 14:02, Erik Christiansen <dva...@internode.on.net> wrote:
>
> >> oo = 10000
> >
> > 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
