re:g-code parsers

Wow what quick responses!

Terry, all I have is a book with the rs274-d standards. And yes
quite a bit of variation is encountered. I guess one advantage of writing my
own is that it would be easier to match a dialect later if needed.

Andy, I took a look at emc's parser and although I don't follow all of c++
it does look good. Very good references to rs274 as well.

Allan, I had looked at sscanf() in my borland compiler stuff but it was not
very well documented. It seems that it might be particularly suited to the
task as I don't expect fixed fields- G01 for example could be written as g1
as I read the standard. As a first stab I was using strspn() and some of the
macros in ctype.h. It seemed to progress into what would be a can of worms-
possible but long.

Using sparse data and a curve fitting routine really is a form of look
ahead. To know the precise next move with many splines one has to know the
next several vertex points. It's a digital
filter with group delay.

The other stuff is a collection of routines I have used with the national
lm628 before. I still use it but it is certainly getting pretty old. I think
tech80 just retired the 5638, an lm628 based
motion card I have used for years. But calls to the card are just a tiny bit
of the code and can be easily adapted. I just must keep that stuff apart
from parsing, curve fitting,error mapping, etc. The only computational thing
related to LM628
is feedforward which must be done soft and on the host. It does not have it
like the pmd chips do.

I ought to just get a Servo to go card and EMC and go; I'm just scared of
the Linux learning curve. I have a Two ton gantry machine in the shop just
about done and waiting for the breath of life!!

Thanks!

Leslie Watts
L M Watts Furniture
Tiger, Georgia USA
http://www.rabun.net/~leswatts/wattsfurniturewp.html