On 05.02.12 18:35, Dave Caroline wrote:
> >For the relatively smaller edge case of those wanting to
> >hand-code sophisticated machine control, gcode (even the LinuxCNC flavor)
>
> For a lot of us hand coding is not an edge case, the available free
> open source cam tools simply do not cater for anything over 3 axis
> milling. which is just a subset of the users.
+1
The constructs of the LinuxCNC extended gcode language are fine for my
purposes too. It's just that the current parser infrastructure does not
meet the requirements expressed by a number of users:
1) Document the legal grammar.
2) Accept the current gcode extensions without useless obfuscating trash
characters surrounding keywords and variable names. (They are only
there because the current parser can't cope without. They are not
there for user benefit.)
3) In Addition to accepting the _current_gcode_syntax_ (minus the
unhelpful guff surrounding keywords and variable names), accept
_also_ a more human readable form of the very same
_current_gcode_syntax_.
Several contributors have expressed interest in exploring this
direction. My interpretation is that the other form of the
LinuxCNC dialect should make clearer _what_ is programmed, rather
than just recording raw machine code, which requires more mental
translation effort, and can lead to wasted workpieces when under
pressure, or on a hot Friday afternoon.
Here, an example or two may be clearer than general arm waving.
The HR (human readable) part of my growing dual grammar for an input
filter for LinuxCNC currently accepts this input:
»
; Setting of the coordinate system to one of the 9 workspaces uses
; a curious hotch-potch of numbers, masquerading as commands.
; Here instead, we state _what_ is happening.
Workspace: 1
Workspace: 7
Workspace: 9
Workspace: 10
End
«
to generate:
»
G54
G59.1
G59.3
; <- Modal Error: Illegal Workspace
M2
«
Now the numbering is the same as for "G10 L2", and we don't need to
remember that G57 is married to "G10 L2 P4".
Because that part of the grammar and its handling were only written
last night, the error handling does not yet display the offending
source line. (Perhaps later today. The comments are handled too, but
need not be repeated in this post.)
Should we, though, be more verbose, using syntax like:
»
Select Workspace 2 ; Needs to be differentiated from G10 L2:
Define Workspace 2 X3.2 Y6.4
«
Now, for hand written gcode programs, does such explicitness improve
clarity? (Here, I'll duck for cover, and count to fifty. :-)
Incidentally is there any documentation for "G10 L20" which more
clearly explains what it does? Do the two wiki sections mean that L2
sets the nominated workspace origin to "axes", expressed in the
currently active coordinate system, while L20 sets the current
position in the currently active coordinate system to be the position
in the nominated workspace given by "axes"?
The grammar also currently translates:
Plane: XY
to
G17
etc.
> The poor syntax of the current gcode held me back for a while.
It seems to be worth working on, then.
> >Wouldn't it make more sense to just
> >develop something like a simple python API that corresponds to
> >(results in) machine motion operations (it could ultimately generate
> >gcode), and modify the LinuxCNC interface to interpret those files
> >line-by-line (the code displayed and stepped through would be the e.g.
> >python, not gcode).
>
> I see no need for anything pythonesk in machine control. This just
> adds an obscure level of abstraction from the real machine.
+377
> 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.
Yes, my aim is to remain true¹ to the LinuxCNC dialect, just with
optionally different "pronunciation" in one of the two grammars. e.g.
"End" instead of "M2", and "End_Pallet" instead of "M30".
> Gcode needs bringing up to date we no longer need cater for paper tape.
May I borrow that for my sig quotes? :-))
I have long felt that it was for paper tape and discrete valve
controllers with 8 bytes of memory that those funny numbers were used
instead of real commands which humans can read.
Granted, if I had them ingrained in my brain, after decades of use, I
would not change either. There is no reason to. An optional input filter
only provides flexibility to anyone wanting more. The filter I'm playing
with will offer decluttered old syntax, and a more human readable form.
Should it be completed, its use is discretionary.
Its formally documented grammars seem an appropriate foil to the python
free-reign available at the other end of the LinuxCNC interpreter, also
optional.
Erik
¹ That doesn't mean including the useless clutter characters which don't
do anything. It'll put them into the output, so we don't have to see
them, yet still support the current interpreter.
--
Programs must be written for people to read, and only incidentally for
machines to execute. - Abelson and Sussman
------------------------------------------------------------------------------
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
