On 1/29/2012 9:20 AM, 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: > >>> 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
