Ardunio G-Code Parser

I've written a g-code parser for the arduino. It receives commands send by a host laptop by usb and controls a mill based on instructions received.

Current commands supported are linear interpolation (00 and 01), dwell (04), setting units (20 and 21), incremental positioning (92). USB comm is needed since the space on the chip is limited and large jobs would not fit, plus the chip does not need to be reprogrammed for every job.

This weekend I plan on adding absolute positioning which shouldn't be that difficult, so I guess this is an alpha release. My goal is to use my mill to etch pcbs including ones needed for a plastic extruder.

My setup of how this works is
1. layout a board in eagle
2. run pcb-gcode script to create gcode
3. send output file over usb to arduino
4. arduino converts gcode to commands to drive steppers on mill
5. etch a pcb with a dremal attached to the mill

pcb-gcode currently only outputs absolute mode gcode...

Heres a rundown of the files in the arduino sketchbook
user - user loop that handles usb comm
init - user defines and startup stuff
process_string - parse gcode instructions
stepper_control - functions that drive the mill

There are two consts in init that you will need to tweak for your setup, they are the number of steps in an inch and in a mm for your mill.

I think the code is easy to follow and I've used it quite a bit to control my mill. Theres a lot I'd like to add, but for now I just need to add absolute mode. Theres some string problems that require leading and trailing spaces, otherwise the string isn't read correctly (its prob 5 minutes of debugging to fix).

The code doesn't require a mill to see how it works, all the commands received are sent back over serial, which can be viewed in arduinos serial monitor.

Any comments or questions or code contributions welcome! I'll post updates here. Thanks to Zach for his work on the project and his arduino sample code!

mellery Wrote:
-------------------------------------------------------
> I've written a g-code parser for the arduino. It
> receives commands send by a host laptop by usb and
> controls a mill based on instructions received.

Yes! This is exactly was I need. If I had known about this I would not have bothered writing my G-code -> SNAP interpreter.

I would add to your TODO Fxx feed rate and also G02 and G03 arc support if that does not become to impractical (trig in Arduino perhaps not so practical). Have a look at my source code if you like to see how I have handled breaking these down into short straight segments (fairly straightforward).

It occurs to me also that you could use the spare output on the RepRap DC motor controller in conjunction with M3/M4/M5 to stop and start the spindle.

Meanwhile, good work!

Thanks! If people use it, i'll implement whatever g-code instructions that are wanted.

I have speed hardcoded right now, but I'll add feed rate this weekend and post an updated one, I'm not sure it matters for making pcbs? The neat thing is I have a variable speed dremal, so I should be able to tap into that and control it through software.

add

speed = (int)(search_string('F', instruction, size));

to the cases in process string to control feed rate in the mean time, that should work but its not tested. I'll add a MAX_SPEED define for case 00, and put that in the init. Also I'll have to look into what units that is and if any conversion factor if its needed.

Arduino has built in trig functions, so G02 and G03 are doable, but are a lower priority for me, but I'll add them eventually.

I plan on making it full featured eventually, right now just the minimum needed for etching boards so I can make the boards needed for the extruder. Do you know of any free programs to make 3d models and generate the gcode?

Edited 3 time(s). Last edit at 02/15/2008 09:48AM by mellery.

this is awesome guys!

thank you so much for this. if for some reason it turns out that my arduino snap implementation is impossible or whatnot, this is a very nice and viable alternative.

i'm definitely going to try this out this weekend.

also, i'd love to see this get fleshed out even more. that would be great!

i'll read up more on gcode and find out exactly what we'd have to do to extend it so that it can handle our extruder code and such.

very rad.

ps. who wants subversion access to get this into the main reprap project?

I'll be adding lots to it this weekend. If theres someplace I can host it other than this forum let me know. Let me know how it works for you.

Edited 1 time(s). Last edit at 02/15/2008 02:05PM by mellery.

> right now just the minimum needed for etching
> boards so I can make the boards needed for the
> extruder. Do you know of any free programs to
> make 3d models and generate the gcode?

Great stuff. PCB milling is also a priority for me.
I have not had too much luck finding proper free 3D CAD software for this kind of thing. What I would suggest in the meantime is create a layer for each cutting depth in (for example) QCAD [www.ribbonsoft.com] (linux) or Solid Edge 2D [www.plm.automation.siemens.com] (win, free 2D version available), and using Ace Converter [www.dakeng.com] (open source, windows only it seems, might work with Wine) to convert this to .NC, setting a depth for each layer. This is not really a true 3d model->toolpath solution, but should work for simple models.
GCAM [gcam.js.cx] looks very promising, but I do not think that it imports .DXF files right now.
There's some interesting links on toolpath generation here - [www.editthis.info], including a link to [www.gcad3d.org] which looks like it might do the business.

If you do upload this to SVN, I might have a go at the G02 and G03 code myself if that's OK.

I'm just trying out CamBam [www.brusselsprout.org] right now. It bills itself as a CAM program but it seems to have pretty good CAD functionality as well (ie you can draw things in it as well as just convert to G-code). It can generate toolpaths for pocketing, engraving, and various other operations. The G-code that it produces seems pretty straightforward (except for comments which would need to be stripped out or ignored by the Arduino interpreter).

It occurs to me that this is perhaps a bit off-topic since it's about milling and not repstrapping, but for me at least the ideal situation is a super-duper machine which can do additive & subtractive manufacturing in one. Laser cutting too, let's allow ourselves to dream. That would really be a wee factory on your desktop, which I'm sure we'd all love to see.

For doing PCB manufacture/routing using eagle output you need G82 for the drill holes, I know this as i have a beautifully routed 3 channel stepper driver board with Arduino connections and a parallel port (all single sided) still sat on the router table until I figure how to make my CNC software recognize G82 :-(

I will post the design very shortly as soon as I have tested it, the idea is with one simple board and a parallel port you can then make all your own baords for the Arduino, extruder etc etc.

---

Ian
[www.bitsfrombytes.com]

Ian Adkins Wrote:
-------------------------------------------------------
> For doing PCB manufacture/routing using eagle
> output you need G82 for the drill holes, I know
> this as i have a beautifully routed 3 channel
> stepper driver board with Arduino connections and
> a parallel port (all single sided) still sat on
> the router table until I figure how to make my CNC
> software recognize G82 :-(

Since G-code is just a text file you could do a regexp search and replace the G82 with an appropriate sequence of G01 and dwell codes. For example;

search
G82 [0-9\.]*) Y([0-9\.]*) Z([0-9\.]*) P([0-9\.]*) R([0-9\.]*)

NOTE - that should be a capital X followed by an open bracket, not the jumping smiley thing, but it is getting read as this!

replace
G00 Z$5 (raise Z axis to release plane)
G00 X$1 Y$1 (move to X-Y position)
G01 Z$3 (feed to hole depth)
G04 P$5 (dwell)
G01 Z$5 (retract to release plane)

any decent text editor can do this (I use jEdit). You may need to adjust this a little, but it won't be too different from this.

You won't need much trig to do the G02 and G03 codes. Just for calculating start and endpoints. Stepping through the circle is easy, no need to cut it up into little segments:

[en.wikipedia.org]

--Blerik

Quick update!

heres what I got done this weekend

1. Fixed all the string parsing bugs, arduino's serial availible needs a delay before you read...

2. Added and tested feedrate, and G00

3. Added G91 (absolute positioning)! wasn't as hard as I was expecting

I'm going to try drawing a PCB with my mill tonight, if all goes well I'll post an updated version. I hope it works! I'll look into adding G02, G03, and G82. Any others?

> I'm going to try drawing a PCB with my mill
> tonight, if all goes well I'll post an updated
> version. I hope it works! I'll look into adding
> G02, G03, and G82. Any others?

Wow, fantastic progress. I suppose G20 and G21 to select inches/metric would be handy, although most folks will likely use one or the other, not both.

cmeighan Wrote:
-------------------------------------------------------
> > I'm going to try drawing a PCB with my mill
> > tonight, if all goes well I'll post an updated
> > version. I hope it works! I'll look into
> adding
> > G02, G03, and G82. Any others?
>
> Wow, fantastic progress. I suppose G20 and G21 to
> select inches/metric would be handy, although most
> folks will likely use one or the other, not both.

already there :-)

i just want to repeat how awesome this is. could i get the latest version? i'd like to add it to subversion and start using it myself.

Latest version, see above for whats new

found a bug with slope calculation, stright lines and 45* angles seem to work fine. Gonna try a formula Zach sent me... but absolute mode works great and I calibrated my mill today! So some progress :-)

i'll be hacking on this code late into the night. added all the stuff i think i need for printing. going to try my first print with it here soon. will post code later tonight.

of course its all in subversion here already: [svn.reprap.org]

had a great night of hacking on my end. here's a summary of what i did:

* changed pins to correspond to Single_Arduino_SNAP pins (sorry mellery!)
* added support for different speeds/step sizes per axis
* made the firmware use the RepStepper / LinearAxis classes
* added to subversion / firmware release script
* fixed line drawing to use bresenham DDA. works great.
* added a couple custom commands to handle temperature
* implemented G28 and G30 (home commands)... anyone wanna check them? (i'm a gcode n00b)
* implemented G50 (spindle speed command?)
* implemented G92 (set current as home, i think)
* implemented M3, M4, M5, M7, M9 to control extruder and fan
* made indentation tab based (cant stand spaces...)

please double check my work. theres most likely something wrong somewhere. also, gcode specs are pretty damn confusing. i may have misunderstood them, so feel free to correct me.

as far as i can tell, this is everything needed to control a reprap machine. tomorrow is looking to be a full day. i plan on making a processing based app to send the commands to the arduino. yayaya!

i've tested all the commands and they work properly (as i understand them to work.)

we still have lots of work to do. theres a million un-implemented commands and of course we still need to make a host to send gcode, as well as handle the whole slice/dice of objects to gcode. i have a couple ideas, but we're on the right track.

of course i forgot to attach the code. its generated using the release script. its in firmware_dir/gcode/GCode_Interpreter. keep in mind you'll also need to copy the library files over to your Arduino library dir.

cheers!

> we still have lots of work to do. theres a
> million un-implemented commands and of course we
> still need to make a host to send gcode, as well
> as handle the whole slice/dice of objects to
> gcode. i have a couple ideas, but we're on the
> right track.

Fantastic work. It occurs to me that slice/dice code is not necessary since all the SNAP commands can be emulated in G-code. All that is needed is new code to handle sending G-code instead of SNAP (and the host software seems modular enough to make that fairly straightforward).

@Zach:

Be careful using the M commands to control the extruder. They usually control the spindle, this could give problems to people using a real mill. They cannot choose to use the extruder instead of the spindle, and the extruder could be mounted to the spindle which would lead to cables snapping and such. Maybe it is better to use gcodes for an alternative or secondary spindle like M21 - M25. Or use R-code for the extruder (R for RepRap).

*edit*

This is the g-code standard. In case you haven't got it: [www.isd.mel.nist.gov]

Oh, and don't use G50 for spindle speed. G-code never controls the spindle, it only controls motion. Just like M-code only controls the whole machine. Spindle speed is controlled with S.

--Blerik

Edited 3 time(s). Last edit at 02/19/2008 04:10AM by blerik.

ZachHoeken Wrote:
-------------------------------------------------------
> had a great night of hacking on my end. here's a
> summary of what i did:

cool, I'll try this stuff tonight

> * changed pins to correspond to
> Single_Arduino_SNAP pins (sorry mellery!)
> * added support for different speeds/step sizes
> per axis
> * made the firmware use the RepStepper /
> LinearAxis classes

whats this class?

> * added to subversion / firmware release script
> * fixed line drawing to use bresenham DDA. works
> great.

sweet!

> * added a couple custom commands to handle
> temperature
> * implemented G28 and G30 (home commands)...
> anyone wanna check them? (i'm a gcode n00b)
> * implemented G50 (spindle speed command?)
> * implemented G92 (set current as home, i think)
> * implemented M3, M4, M5, M7, M9 to control
> extruder and fan
> * made indentation tab based (cant stand
> spaces...)
>
> please double check my work. theres most likely
> something wrong somewhere. also, gcode specs are
> pretty damn confusing. i may have misunderstood
> them, so feel free to correct me.

can we get a wiki page to keep track of bugs/ideas?

> as far as i can tell, this is everything needed to
> control a reprap machine. tomorrow is looking to
> be a full day. i plan on making a processing
> based app to send the commands to the arduino.
> yayaya!

nice! does this processing stuff run on linux? Something that reads in a .nc file and sends the instructions to the arduino would be awesome, as well as allowing sending one at a time manually like the serial monitor... very handy for debugging.

> i've tested all the commands and they work
> properly (as i understand them to work.)
>
> we still have lots of work to do. theres a
> million un-implemented commands and of course we
> still need to make a host to send gcode, as well
> as handle the whole slice/dice of objects to
> gcode. i have a couple ideas, but we're on the
> right track.

don't know what the slice and dice stuff is (for printing 1 layer at a time?), but gcode does 3d... I just haven't found a free 3d program, but I just found a plugin that converts google sketchup files to gcode, that might work

Slice and dice (term coined by Forrest Higgs, what the CNC world calls it I don't know) is the process of turning a shape into thin layers (bottom-up for additive manufacturing like RepRap, top-down for substractive), and then creating a 2d toolpath to fill out the layers (inside fill for additive, outside fill for substractive). It is the simpler cousin of full 6dof toolpath creation used with advanced milling.

--Blerik

Hi blerik,

... have a look on LOM (Layered Object Modelling or Laminated Object Modelling) - here you have the technology and some systems for building highly sophisticated and sometimes really big objects from paper or thin sheets of different materials.

Or search in the forum, here i posted some ideas of a lathe-type of LOM-fabbing too ...

Viktor

mellery Wrote:
-------------------------------------------------------
> ZachHoeken Wrote:
> --------------------------------------------------
> -----
> > had a great night of hacking on my end. here's
> a
> > summary of what i did:
>
> cool, I'll try this stuff tonight
>
> > * changed pins to correspond to
> > Single_Arduino_SNAP pins (sorry mellery!)
> > * added support for different speeds/step sizes
> > per axis
> > * made the firmware use the RepStepper /
> > LinearAxis classes
>
> whats this class?
>
> > * added to subversion / firmware release script
> > * fixed line drawing to use bresenham DDA.
> works
> > great.
>
> sweet!
>
> > * added a couple custom commands to handle
> > temperature
> > * implemented G28 and G30 (home commands)...
> > anyone wanna check them? (i'm a gcode n00b)
> > * implemented G50 (spindle speed command?)
> > * implemented G92 (set current as home, i
> think)
> > * implemented M3, M4, M5, M7, M9 to control
> > extruder and fan
> > * made indentation tab based (cant stand
> > spaces...)
> >
> > please double check my work. theres most
> likely
> > something wrong somewhere. also, gcode specs
> are
> > pretty damn confusing. i may have
> misunderstood
> > them, so feel free to correct me.
>
> can we get a wiki page to keep track of
> bugs/ideas?
>
> > as far as i can tell, this is everything needed
> to
> > control a reprap machine. tomorrow is looking
> to
> > be a full day. i plan on making a processing
> > based app to send the commands to the arduino.
> > yayaya!
>
> nice! does this processing stuff run on linux?
> Something that reads in a .nc file and sends the
> instructions to the arduino would be awesome, as
> well as allowing sending one at a time manually
> like the serial monitor... very handy for
> debugging.
>
> > i've tested all the commands and they work
> > properly (as i understand them to work.)
> >
> > we still have lots of work to do. theres a
> > million un-implemented commands and of course
> we
> > still need to make a host to send gcode, as
> well
> > as handle the whole slice/dice of objects to
> > gcode. i have a couple ideas, but we're on the
> > right track.
>
> don't know what the slice and dice stuff is (for
> printing 1 layer at a time?), but gcode does 3d...
> I just haven't found a free 3d program, but I just
> found a plugin that converts google sketchup files
> to gcode, that might work

wiki page: [reprap.org]

processing should run on the 'big 3'. i've added the sketch to the release files. i've also attached the most recent version of the stuff (gcode firmware + host)

its all very basic and rudimentary, but it does work. i can explain it in more detail later, but i'm very hungry now. one note: it basically looks for job.gcode in the 'data' dir of the sketch, and sends those lines to the first serial port. its pretty nifty.

also, i changed more library files again so you'll have to copy them to arduino/hardware/libraries and overwrite the old ones. i'll look into rewriting that to put it all in one sketch. we'll see.

blerik is right on the slice/dice. one thing i'm going to look into doing is hacking the RepRap host software to output the GCode directly. If we can do that, then we'll be golden!

You're all doing great work on the GCode parser; which in my opinion is vital, because once you have a print spooler you pretty much have replication.

Zach mentioned hacking the RepRap host to output GCode directly. If this works great, if not you can try translating the slice XML developed made by Forrest and Steve DeGroof, a sample of which is at:
www.3dreplicators.com/coupling.xml

are i/o pins on the arduino pulled high or low internally? I don't have limit switches on my mill yet...

i'm not sure. i think they only have internal pullup resistors. if you want, you can wire them to gnd temporarily. or edit the code in LinearAxis to ignore them.

mellery Wrote:
-------------------------------------------------------
> are i/o pins on the arduino pulled high or low
> internally? I don't have limit switches on my
> mill yet...

It might be a good idea to make a constant in the main sketch file for high/low active limit switches. The optointerrupters that I have used are noninverting, since I was not able to source the inverting type specified in the arduino opto endstop instructions. It's pretty easy to just add an inversion in the appropriate method, but it might be worth making this a bit easier to set up.

indeed. i'll see what i can cook up.