This is a bit of R&D I'm experimenting with, so bear that in mind as you look
at the source code - it was thrown together from various bits & pieces I had
lying around, and it's all in one source file during the development stage
while I'm still working out how things will be put together.  Anything for
release will be restructured more sanely and not look quite so hacky. Fortunately
I'm retired now and don't mind about putting crappy code out there because
I've no potential employers I'm trying to impress ;-)

Note this has been tested on a Raspberry Pi only.  Serial I/O will probably
be different on any other system.  And it sort of assumes a 20K RPM spindle
as that;s what I have fitted, though that's probably not an issue really.

What you're looking at is primarily a gcode sender, which simply reads lines
of gcode from the keyboard and sends them to the GRBL controller on a SainSmart
3018 CNC.

However, being the programmer that I am, I couldn't leave it as something
simple like that, so this program has a few extras :-)

Primarily it is a harness where I can test programs to cut whatever object
I'm working on.  It's honestly easier for me to just generate the gcode from
a C program than to learn how to create STL files with a GUI object editor,
and go through all the external processes that turn a model into a GCODE file
that cuts wood.

Also it has a bunch of commands added which I can use in the same sort of
way as a hand tool... cutting pockets, drilling crew holes, etc.  Although
initially there's not much specific code in here to do such things, it'll
get added over time as I need some new routine for whatever project I'm
working on at the time.

At any time while entering a line, you can use the cursor (arrow) keys
to jog the CNC.  Some keys have special effects only if pressed when
the input line is empty.  (As a little extra, try '>' when you try '?'!)

And I try to keep special notices separate from all the scrolling text - there's
a few lines at the top of the page that don't scroll, and the input line
is relatively immune from being messed up when GRBL throws something unexpected
at you (such as asynchronous status updates).

Finally it has a bunch of commands that are really just aliases for GCODE
commands - because they're easier for me to remember.  Someone else hacking
on this code would probably want to remove those and use your own preferred
aliases that you remember better.

I have a few "To Do"s scheduled as well, such as reading in existing gcode
files and executing them (which is after all the purpose of a gcode sender)
but since I don't actually have any externally supplied GCODE files yet,
I haven't added that.

There are also a few places where I do some sanity checks and other things
that raw GCODE wouldn't do for you.  For example, where GRBL reports something
like "error:22", this code detects that string and appends a more readable
natural English description of what the problem probably was.

The source code for editing is in http://gtoal.com/src/CNC/sender/gcode4.c and a
more viewable or printable version is in http://gtoal.com/src/CNC/sender/gcode4.c.html

There's an ancilliary program, takeon, which generates the tables for the
command parser.  It has been hacked a bit from the original which was used
a long time ago when I wrote a small C compiler, but for this program I
removed a few unused features.  It may be a little awkward for other folks
to use if not familiar with that kind of parser, but it's fast and lightweight
and avoids having to pull in a whole mess of code for some external tools
such as yacc+lex.

I'm only passing this around to start a discussion about potential features,
not as a basis for writing a tool from.  As I said earlier, it's R&D which
means it's a quick hack and poorly structured.  But the behaviour is sort
of working (apart from a few places where it still locks up after an error,
which I'm working on) and it's now about as functional for me as cncjs which
I find a pain (as I do all GUI-based programs)

PS The makefile uses an old-school text editor to filter some text.  Rather
than work out how a Unix person would do that with the standard tools, I
have just included the source of the editor.  It's very portable and always
works...

I'll document the implemented commands soon.  You can kind of work them out
by looking at the generated grammar file, gcode4.g


known bugs:
 sometimes locks up, I think when waiting for an 'ok' in some awkward context
 always locks up after calling internal procedure to cut something complex,
 eg cylinder. Not sure why yet, working on it.  (It worked before :-/)
 initialisation can be iffy, sometimes I need to start cncjs first then exit it
 can be problematic after hitting E-Stop!
 Useful to get into the habit of having a spare 'screen' window open, where
 you can do a ps auxww|fgrep gcode and then kill -9 the process. (or use pkill)