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

Reply via email to