G-code (GCODE) interpreter for RepRap

Hi there. This is my first post on the RepRap forums; hopefully it's not my last.

It has been noted here before I believe that most commercial CNC milling machines read G-code, which is a standardised language for controlling machine tools.
I am really impressed with the RepRap project, and I am sure that I am not the first person to see the potential of the electronics and control protocol to be used for subtractive modelling (ie milling, drilling) as well. In fact, the McWire Bot seems to be designed exactly for this purpose.

The problem is of course that CAD programs tend to export .DXF files, which are then converted via various methods to G-code .NC files. The RepRap host software is designed for additive manufacture, and does not read this type of file.

This is where I have been busy with. I have written an interpreter for G-code, which will drive a RepRap/RepStrap. Attach a Dremel or whatever to the end of it and you have a CNC milling machine.

Please note, what I have here is VERY early work (about three days old, and it is my first ever effort at writing Java). What I would really appreciate is if people could give some feedback and suggestions, find the bugs, and help make this something useful. It is of course GPL licensed so do with it as you will (I have myself made use of some code from the RepRap sources here and would like to acknowledge as much).

NOTE - YOU MUST HAVE THE RepRap HOST SOFTWARE INSTALLED FIRST TO USE THIS! ALSO, THE PREFERENCES FOR BAUD RATE, ETC. NEED TO BE SET UP PROPERLY IN THE RepRap HOST SOFTWARE.

Here is the tool chain which I have been using for testing;

* Draw in 2D with Solid Edge 2D Drafting. This is available as a free download from [www.plm.automation.siemens.com]
I would of course rather get this working with some open source CAD software.
* Export as .DXF
* Convert to .NC with Ace Converter [www.dakeng.com]. I set up the Default layer in the .DXF to cut at 0.0000 units, and the release plane to 10.000 units.
* Load .NC file into G-code for RepRap (attached).
* Cut!

The following G-codes are supported for now;
G00 rapid move
G01 linear move
G02 clockwise arc
G03 counterclockwise arc
Fxxx set feed rate where xxx is units/minute

More information at [en.wikipedia.org]

I have included a few .NC and .DXF files by way of demonstration. I attached a pen to the end of my (incomplete) RepStrap and set the thing drawing.
This has only been tested so far on Windows. I see no reason why it should not work on Linux etc.

Comments and suggestions please! Note, "it doesn't work" is of course not very helpful. Once again, I would point out that you must install the RepRap software first and get it working.

I have only tried this with the Arduino electronics (which are in heavy development right now and a bit buggy). No idea how it will work with the other type. In theory it should not be a problem since they use the same communication protocol.

There is one known bug already - the program will crash when executing a "Home Y" command. Not sure if this is a problem with the Arduino firmware or the host software. Also, it can sometimes just hang for no obvious reason. These are early days!

I have quite a bit more information as well as photos and a video of it doing its thing on my website [www.chrismeighan.com]. Please excuse the blantant plug here.

Good luck.

Very nice... A GCode interface is something the RepRap project has needed for a long time, since it will allow anyone with a cnc mill to start RepStrapping.

However, it seems you wrote the software to _read_ GCode and convert it to SNAP to drive a RepRap instead of allowing the host software to _write_ GCode. If you have a .NC file, why use the RepRap bot when you can use EMC and just about every cnc mill in existence?

--Blerik

> However, it seems you wrote the software to _read_
> GCode and convert it to SNAP to drive a RepRap
> instead of allowing the host software to _write_
> GCode. If you have a .NC file, why use the RepRap
> bot when you can use EMC and just about every cnc
> mill in existence?

Well, I suppose I like doing things back-to-front...
Seriously though, it was because I was interested in building my own mill, and using the RepRap electronics seemed like a very elegant way of doing it. I for one cannot afford to invest in a commercial mill.
Most available free & affordable software (EMC, Mach3, KCam etc) seem to be set up primarily to drive stepper drivers directly using parallel port pins, which is fine for a dedicated machine which can be set up for real-time operations. Using the RepRap electronics, which take care of the low level stuff, means that I can drive my DIY mill via the USB port on my laptop, which seems like a better situation. Having a machine set up just to run a mill seems a bit over-the-top to me.

Also, using this approach allows the same hardware to be used for both subtractive and additive work - if it is sturdy enough, it can be used for milling as well as thermoplastic extrusion RepRap style. For example, I have not yet built an extruder, but this software allows me to start doing useful things with my bot using just about any software which can produce .DXF files (to be converted to .NC). I am particularly interested in using my bot for PCB milling, since I do not have the space necessary for doing it by chemical means (I live in the Netherlands, where we are used to living in pretty modest sized accommodation; this is the most densely populated country in Western Europe).

What you are proposing (RepRap (ie .STL) -> G-code, the opposite of what I have written) is of course certainly something worth looking at.

Chris

Fair enough. Be warned though, the Darwin design is not suitable for light milling, you need the McWire design for that.

Zach is currently rewriting the Arduino firmware because of some nasty SNAP related bugs. He might be interested in using GCode instead. Maybe you should contact him.

The Arduino firmware seems to me the best place for a GCode interface like the one you wrote. That way you can push a .NC file over the usb serial to the Arduino, and it executes it. Together with an addition to the host software so it speaks GCode as well, the whole RepRap speaks GCode, and is compatible with the rest of the CNC world.

*EDIT*

Should have looked at your website first, Doh! That robot you built seems to be fine for PCB milling, good job!

--Blerik (I'm from Amsterdam by the way)

Edited 1 time(s). Last edit at 02/14/2008 08:26AM by blerik.

blerik Wrote:
-------------------------------------------------------
> Fair enough. Be warned though, the Darwin design
> is not suitable for light milling, you need the
> McWire design for that.

Yes, of course. I have myself built a machine based on found parts (printers, typewriters, etc) which should be a bit sturdier than the Darwin design. It still needs a bit of work before being of practical use (photos at [www.chrismeighan.com]).

> Zach is currently rewriting the Arduino firmware
> because of some nasty SNAP related bugs. He might
> be interested in using GCode instead. Maybe you
> should contact him.
>
> The Arduino firmware seems to me the best place
> for a GCode interface like the one you wrote. That
> way you can push a .NC file over the usb serial to
> the Arduino, and it executes it. Together with an
> addition to the host software so it speaks GCode
> as well, the whole RepRap speaks GCode, and is
> compatible with the rest of the CNC world.

I take your point, the problem is that the range of G-code instructions (were a more complete set to be implemented) is quite extensive. There's things like canned drilling cycles where one single instruction gets the machine to make a series of complex, timed moves. I think it would be pretty unlikely to get this all working in the Arduino firmware (the current firmware already almost fills the 16k available). The SNAP protocol used at present is a much better option IMO because it is much simpler. Complex G-code programs can be broken down in the host into more primitive instructions ("move to ??,??,?? at speed ??" and such like).
Also, if the firmware was to read G-code instead of SNAP, then the host software for RepRap would also need to have a new machine interface written to spit out G-code instead of SNAP. Of course in this case space is not a concern.

I thought of another (minor) use for my software - if and when somebody does write a G-code interpreter to make RepRap output G-code, then this could be used to check that it works OK by driving a RepRap with the resultant output (if it could be saved as an .NC file instead of being sent directly over the comms link).

> --Blerik (I'm from Amsterdam by the way)

Ach, wat 'n toeval!

>I take your point, the problem is that the range
>of G-code instructions (were a more complete set
>to be implemented) is quite extensive.

Yes. But when using a limited set of G-code (RepRap doesn't need much), you get about the same codesize as SNAP and less complexity. And the added bonus that you can use any old cnc mill as a RepStrap.

But this is just a pet peeve of me. RepRap reinvents the wheel too much:

* Its own STL parser (there are very nice open-source versions, like MeshLab),
* Its own slicer-and-dicer (CandyFab uses PovRay which is weird, but almost no code to write),
* Its own machining protocol (while the rest of the world uses gcode),
* Its own token bus (they could have chosen TWI, I2C, 1-wire, SPI or CAN),
* Its own stepper interface (fixed by Zach with the Arduino).

It basically ignores lots of knowledge the DIY CNC world and the open-source world have accumulated. But hey, I complain too much and code too little... Back to work.

(Just for contrast, the RepRap project does brilliant things as well, like the extruder design, the PLA work Vik does, and the Arduino and Seedling work of Zach)

--Blerik

i agree that re-inventing the wheel is something we spend way too much time doing. its something i'd like to change in the future and am working towards right now. getting a gcode parser firmware for arduino would be a great step forwards for that.

Surely G-code is a file format, not a comms protocol suitable for sending down an electrically noisy serial connection?

---

[www.hydraraptor.blogspot.com]

No - G-code is a information format definition that the CNC industry uses to control a tool head. Move this direction, this fast, this axis. It is a specification of how to place a tool from one location to another. To get diagonal movement it is just like a multi-tasking computer it just does one thing just each one very fast.

G-code
[en.wikipedia.org]

G-code/M-code listing
[www.machinemate.com]

Edited 2 time(s). Last edit at 02/14/2008 03:52PM by Robert Teeter.

---

Bob Teeter
"What Box?"

@Nophead:

G-code is not a comms protocol, that is correct. It doesn't need to be. RepRap currently uses USB as a serial comms protocol. And USB is rock solid in all conditions. It's got error detection and correction, and lots of other goodies, and it's included in both the newer PICs and the Arduino. No need for an extra SNAP layer as far as I can see (maybe for pacing, but you might as well use kermit or xon/xoff for that).

G-code is not a file format either, it's code that runs on an interpreter (you can also save it in a file). Both the PIC and the Arduino have plenty of oomph to run a G-code interpreter, and everybody in the cnc world uses G-code, so why don't we?

--Blerik

ZachHoeken Wrote:
-------------------------------------------------------
> i agree that re-inventing the wheel is something
> we spend way too much time doing. its something
> i'd like to change in the future and am working
> towards right now. getting a gcode parser
> firmware for arduino would be a great step
> forwards for that.


I have one written for the arduino that I've been planning on posting for a few days... just been busy...
right now it only does incremental mode, but it works great!

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

Hello folks!

I have a KOSY A5 milling machine that I planned to use as start for a reprap ( check at [www.max-computer.de] )

The KOSY A5 have a series of relais to switch for example a dispenser on/off, just a simple line in the G-code activates the switch on or off. PERFECT!!

But is there a program that converts my 3D (STL-file) to a GCODE toolpath that also can activate the dispenserswitch or do I need to program the switch manually?

Would be great to get a answer to this!

With best regards
Wretan

blerik,
The standard RepRap does not use USB protocol. It uses 5V serial comms which has little noise immunity in the presence of motor noise. To stand any chance of working reliably it needs a protocol with error detection, timeouts, retries, etc, such as SNAP.

If you are using USB comms and sending commands in USB packets then yes it makes no sense to use SNAP as well becase USB has all these things, but if you are just using a USB to serial converter then you do still need a serial protocol.

The confusion here is that SNAP is just the transport layer which ensures the packets get there. USB already has that. The command layer is the thing that is unique to RepRap. If those commands are sent over USB there is no need for them to be wrapped in SNAP packets as well.

The commands that are sent are low level commands specific to the PIC implementation, allowing tiny PICs to be used. You could send G codes over a serial bus, wrapped in SNAP, or naked over USB but it would require a G code interpreter, which cannot really be distributed over multiple tiny PICs.

Given a more powerful, single controller doing all the axes, then yes you could use G codes over USB but that is only applicable to the Arduino platform.

Remember this project is a project to make a specific self replicating rapid prototyping machine, not a project to allow every possible CNC mill to be converted into an FDM machine.

---

[www.hydraraptor.blogspot.com]

The RepRap has analogue feedback from the thermistor, I don't think G Code can cope with this. I'm sure later versions of RepRap will have USB comms but what we now have works so why re-invent it?

---

Ian
[www.bitsfrombytes.com]

nophead Wrote:
-------------------------------------------------------
> blerik,
> The standard RepRap does not use USB protocol. It
> uses 5V serial comms which has little noise
> immunity in the presence of motor noise. To stand
> any chance of working reliably it needs a protocol
> with error detection, timeouts, retries, etc, such
> as SNAP.

True. But RepRap uses a subset of SNAP with some differences, and then the host ignores some acks and naks so there is still no reliability... It also splits the serial lines into a christmas-tree lights token bus which breaks very easily. All that leads to people tearing their hairs out trying to replicate these efforts. And for what? These problems have already been solved by the cnc community. Steppers and servos speak step/dir, motors speak pwm, temperature sensors use ADC. All of them are used in electrically noisy environments and all of them work.

> If you are using USB comms and sending commands in
> USB packets then yes it makes no sense to use SNAP
> as well becase USB has all these things, but if
> you are just using a USB to serial converter then
> you do still need a serial protocol.
>
> The confusion here is that SNAP is just the
> transport layer which ensures the packets get
> there. USB already has that. The command layer is
> the thing that is unique to RepRap. If those
> commands are sent over USB there is no need for
> them to be wrapped in SNAP packets as well.

Right. And big parts of the command layer look so much like G-code it is uncanny. Because both try to do the same thing. Create a few special G-codes (the spec allows for extensibility), and it matches 100%. And you are instantly compatible with 10.000+ cnc machines that are already out there. RepStrapping couldn't be easier, just stick an extruder on it, calibrate it and print the parts.

> The commands that are sent are low level commands
> specific to the PIC implementation, allowing tiny
> PICs to be used. You could send G codes over a
> serial bus, wrapped in SNAP, or naked over USB but
> it would require a G code interpreter, which
> cannot really be distributed over multiple tiny
> PICs.

Except that the tiny PICs used aren't so tiny anymore, because Microcontroller Inc. stopped making them. The 648s have plenty of power for a G-code interpreter. They still don't have USB, but pretty soon they will. The 18f series with USB costs only $1.5 extra. If you really want to go multiple controller, buy a USB hub as well ($5), and you can have 1 master (either the host, or the x-axis controller) distribute the G-code to all. Or use step/dir to control your axis, like the rest of the world.

> Given a more powerful, single controller doing all
> the axes, then yes you could use G codes over USB
> but that is only applicable to the Arduino
> platform.

Which is why I'm using the Arduino platform. USB to the host, step/dir to the axis, pwm and adc to the extruder. And I've been working on a G-code interface on and off for some time now. Chris and Mellery have as well, and now the RepRap speaks G-code.

> Remember this project is a project to make a
> specific self replicating rapid prototyping
> machine, not a project to allow every possible CNC
> mill to be converted into an FDM machine.

True. But there are two big parts to the project as it is now:

* The bits that can be replicated like the extruder and the cartesian bot. They are fine (and almost finished).
* The bits that cannot be replicated yet. They (seem to be) overly complex and ignore the cnc world that has already solved these issues. Zach has fixed most of these issues with the Arduino based electronics and the McWire RepStrap design, and now G-code is here.

--Blerik

(disclaimer: I'm a moody old curmudgeon with a knack for pissing people off. I still think the RepRap project is brilliant, I just think it should be more open)

>
> I have one written for the arduino that I've been
> planning on posting for a few days... just been
> busy...
> right now it only does incremental mode, but it
> works great!

Great! It's a pity I didn't know about this before I went and wrote this program, otherwise it could have saved a bit of work. My motivation was entirely practical - I wanted something with which to mill (not reprap) 3D shapes NOW, and using the RepRap Arduino electronics and writing a G-code -> SNAP interpreter seemed like the fastest way of doing it. I hope that won't be seen as abuse of the work that the RepRap team has been doing (in that I'm not immediately interested in FDM).

In response to Blerik's point about reinventing the wheel, I couldn't agree more. It is one of the most frustrating things about the open source movement that sometimes egos or I don't know what seem to get in the way of finding practical solutions that will make people's lives easier and get them using open source - you get more kudos for starting a new project than for contributing a vital patch to an existing one. I am being a bit hyprocritical here but as I said, the reason I wrote this program was to get something done with as little effort and in as little time as possible. If is useful to other people then that's even better.

If an effective G-code interpreter can be run in the Arduino firmware, then that seems to me to be an ideal solution on all counts. A few custom extensions for reading sensors, controlling the extruder etc, and there is the double benefit of allowing existing CNC machines to be used for reprapping, and allowing a suitably-strongly built reprap/repstrap with a drill attached to be used for milling using existing software (EMC etc). Win-win.

Is there anything in the CNC world that talks G-code over USB? I.e. would changing the command protocol to G-code increase interoperability?

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
-------------------------------------------------------
> Is there anything in the CNC world that talks
> G-code over USB? I.e. would changing the command
> protocol to G-code increase interoperability?

The Arduino uses the FT232RL USB chip which is recognised by the host computer as a USB->serial converter. What the software sees is just another serial port (COM1, /dev/ttyS0 etc). Therefore all that needs to be done is that the generated G-code is sent to this serial port. This could be as simple as;

cat ????.nc > /dev/ttyS0

if handshake etc are set up properly. I think it should be made clear that G-code is a description language for tool paths, not a communications protocol. How it is transmitted to the hardware is independent of this.

So yes, interoperability would increase immensely.

... i'm repstrapping with a fully functionable CNC-mill too (beside mey experiments with parallel-kinematic-robots).

The problem is not the communication to the steppers - here i have an Isel-CNC-controller, which ist driven by the PC with proprietary Isel-NCP-code or common G-code over the serial RS232-port.

Many others have other CNC-mills or PCB-routers with DIR/CLK-drivers over parallel port with simpler Motor-drivers, and others more ...

My wish is a module (postprocessor) in the host-software, which i can adapt to my controllers, so the path-information is outputted in the right format for my controller.

Then it would be no problem to apply different hardware-setups, printertypes or coordinate-systems (as my tripod or hexapods/stewart-platforms, scara-robots or many other types) as backends.

Another point is the extruder, which could be a dispenser too or even a drill/mill or diode-laser.

So for me here is the interface to the common world of DYI-routers and selfmade 3D-printers assembled from salvaged scrap ...

Viktor

cmeighan Wrote:
-------------------------------------------------------
> If an effective G-code interpreter can be run in
> the Arduino firmware, then that seems to me to be
> an ideal solution on all counts. A few custom
> extensions for reading sensors, controlling the
> extruder etc, and there is the double benefit of
> allowing existing CNC machines to be used for
> reprapping, and allowing a suitably-strongly built
> reprap/repstrap with a drill attached to be used
> for milling using existing software (EMC etc).
> Win-win.

I've posted my arduino code here, let me know what you think :-)

[forums.reprap.org]

all i have to say is this:

AWESOME! Keep up the great work guys. I'm going to have a go at trying to run all these new Arduino developments.

with enough of us hacking away at this thing, we're going to get something sweet and easy going in no time at all.

keep up the good work!

I've just look ove arduino code gor GCODE interpreting routines:

1:

For implementing real G2 and G3 function this book have good routines:

[www.amazon.com]

SCHAUM'c COMPUTER GRAPHICS

2: For LINE You will need ramp up and ramp down anyway yoo will be loosing steps!
Linear acceleration works fine! But S curve is better!

Regards,
Ike

kepp up good work



blerik Wrote:
-------------------------------------------------------
> Very nice... A GCode interface is something the
> RepRap project has needed for a long time, since
> it will allow anyone with a cnc mill to start
> RepStrapping.
>
> However, it seems you wrote the software to _read_
> GCode and convert it to SNAP to drive a RepRap
> instead of allowing the host software to _write_
> GCode. If you have a .NC file, why use the RepRap
> bot when you can use EMC and just about every cnc
> mill in existence?
>
> --Blerik