> > I see no need for anything pythonesk in machine control. This just > adds an obscure level of abstraction from the real machine. > > I too wrote a gcode generator for some of my standard shapes but found > it was more elegant to do it in gcode > as I could use sensible(ish) variable names. why enter in a form, > generate code, transfer, when it is a simple edit to a standard gcode > file. > > Gcode needs bringing up to date we no longer need cater for paper tape.
To me your first sentence does not seem congruent with your second. Surely a real scripting language would allow for much more elegance and expressiveness than a gcode language extension. One does not seem necessarily more obscure or abstract than the other to me. Although I must admit I would rather point someone at an existing scripting language tutorial for variables, looping and conditionals than try to explain the LinuxCNC gcode extensions for the same, even with sweeter syntactic sugar. In that sense, using an existing scripting language seems much less obscure. Also, I am not proposing an intermediate step such as filling out a form, generating gcode, etc. The scripting API would be directly interpreted by LinuxCNC, allowing the sort of edit-in-place you describe. Whether it generated gcode or made NML calls (or some other approach) would be an API implementation detail not visible to the person running the program. Hope that helps clarify, Scott ------------------------------------------------------------------------------ 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
