reflections on g-code

This list has been busy while I was out terrorizing a few German drivers
by getting the alfa to 260km/hr or by red-lining the BMW. Autobahn does
compress apparent distance.--

It has been my impression for quite a while now that the g-code discussion
was the kind of issue that really has no place to go. Let me explain by
asking you to think of g-code as a mix of three different things.

At the lowest level, are the codes that set up the way that the control
should think about subsequent program blocks. These include; kinds of
moves, plane definition, tool to use and offsets. Some M codes
fall into this class, turning on coolant, and such.

The second level of g-code are actual position words. x1.2305. y4.30987,
r2.1039.

The third are all of the "features" that tool builders include to make
their machine more desirable that machines made by their competitors.

Now, if you are just buying a box or executable that takes g codes and
runs a machine, it is good to have as many codes and as many subroutines
and macros as possible. Fancy codes here will allow you to write compact,
non-redundant programs without having to mess with the box.

>Subject: re:gcode vars and subs -- How about macros

>Greg,
>Why not do the "math" stuff up above. Let the CAD/CAM, or your special
>"design" program generate the resultant Gcode. The task needs be kept
>divided into several levels of abstraction. Start from where ever you
>want, and it all ends up as Gcode. IMO.
>Alan KM6VV

IMO Alan is right on here. If you run from a PC using adjustable
software, you only need the first two classes of codes. Why? Because in
the PC, you can make a virtual "fancy" g-code engine that spits out
whatever collection of program blocks you want. A bunch of code can be
inserted with a single mouse click If you want to:

peck a hole at x2y2
from z-1
to z-4
using a .25 peck,
and .01 bottom dwell
and a retract that clears the part on each peck.

Or if you want to thread a rod your virtual engine can develop and crank
out all of the passes to produce the result that you want. These do not
need to be built into the interpreter itself.

>The M code you listed is ugly to be sure, but I have to say the "new
>feature" (msg implemented in EMC is worse. It requires READING at
>least 4 digits into a comment, as opposed to just stopping when
>the "(" is encountered, and going to the next line. Since EMC reads
>the whole line anyway, it SEEMS ok. But these are the 'sneaky' kinds
>of things that lead to bloatware and poor performance, IMO.

>Ballendo

Here I am more than guilty because I wrote a bit of Tcl/Tk that would run
a main program and a sub program and refer to each other using comments.
A better approach is available with what is called conversational
programming. I've seen systems with real old controls like GE 550's that are
being drip fed very modern 3d stuff from PC,s

In the Netherlands, I saw a system that uses just the barest minimum of
the EMC g-code set, runs everything in MDI, (drip-feed) and has enough of
a buffer between the PC and dedicated motion boards to allow NT to do the
control work. The gui, written in visual c, includes many features like
macros, subroutines, and axis position based on variables. And a user has
access to the full range of c language computation, logical expression
evaluation, and looping. And the owner/writer of this system has enough
time left over to be an awesome cook.

No, the author is not your average hacker but if you've spent any time
with a low level programming language you know that that language will
work more logically than the best g-code control language out there.
G-code was invented to move a machine in predictable ways. I don't think
that we should extend to to accept NURBS or any other of the latest visual
offerings. We don't need to extend RS274 to do the latest contortions as
though it was a frantic teen-aged dancer. These need to be handled by
code writers, post-processors, or whatever.

Several of the EMC folk have been working on two conversational
programming schemes. The first is based around the g-code routines that
Jon Elson wrote in c. This approach writes a g-code program file for
later execution. Bolt circles, pocket milling, grill patterns, simple
text, and markers for rotary knobs are a few of the routines already
available. You can get a copy by downloading cpstuff*.tgz from the
linuxcnc.org/Dropbox. You'll need Tcl/Tk to run it but you can get that
program language free from Scriptics for nearly every computer and OS in
existence. Linux users will already have it on their OS.

Matt has been working to transform the cp model into a kind of drip feeder
for EMC that includes complex routines built from simpler routines and
uses a tree widget to show the parts of a program. A simple example
can be constructed by thinking about a bolt circle. 1-a rapid to
location, 2-drill to depth, 3-dwell, 4-return to clear part. This "macro"
is repeated for the number of holes needed.

And at the top level this routine can be changed by changing the geometry
from circle, to ellipse, to rectangle, to line, etc. While at the lower
levels, the routine can be changed by replacing drill with peck. It can
also be changed by redefining the relationship between the holes as
equidistant or some other scheme.

Using his work, you will be able to program with EMC and never look at or
edit g-code, unless you want to. His next step is simple 2d CAD program
that is already in there but needs to be integrated.

A further step might be to make the programmer output something other than
G-code so that it could feed an other box entirely.

>Another note along this line of thinking came up awhile back. EMC has
>a standalone interpreter with LOTS of error checking. Then the error-
>checked code is run through the SAME error checks again at run time!
>I mentioned 'cleaning out' the run-time interpreter, so the speed
>gained could be used for trajectory planning,etc. RayH thought it
>seemed a good idea, and asked me to work on it. I told him my plate
>was already full. Don't know from there what happened/is happening?

>Hope this helps.
>Ballendo

Nothing is happening here right now. Like trashing fine poetry, we
have been reluctant to start in on Tom's code. I'm sure that when we get a
solid conversational product here, we will be running two levels of EMC
interpreter. The first will include all of the error checking and will
be used to verify a cp or program. The second stripped down version will
be used for runtime in those places were we need to interpret more than 100
blocks per second. (autobahn)

If you want to help contact one of us off list. If you want to comment
on my thoughts be considerate and snip 'cause this was a long post.--

Ray