G-Codes Rule!

I’ve switched my RepStrap to use G-Codes, since that seems to be the direction the RepRap project is heading.  I’m glad I did!  The G-Code protocol consists of ASCII text I can read in a terminal, edit with a text editor, and generate with Python.  Now I have several Python scripts for doing various things with the machine.  Sometimes scripting is much more comfortable than a GUI interface.

OTOH, I’m also glad I started with the SNAP codes, since the code in Subversion that implements the new protocol isn’t stable yet.  Specifically:

  • At first, the G-Code firmware failed very badly.  Some poking around revealed that the microcontroller was resetting on every strtod() call.  This turned out to be a bug in Ubuntu 8.04; the solution was to just grab the latest avr-libc package from the 8.10 release and install it with “dpkg -i”.
  • At that point, the compiled firmware was just a little too big to fit on the Arduino.  I commented out the support for drill cycling (codes 81-83; do we really need those?), then it fit with room to spare.
  • The RepRap host interface can generate G-Code scripts, but the scripts contain very long pauses.  I discovered that the G4 codes it was generating were supposed to be in units of seconds, but the code was outputting milliseconds instead.  I fixed that and now the generator works fine.

Incidentally, I just measured my extruder’s output rate, and this seems like a good place to keep a record.  I set the motor speed to 170 (the range is 0-255 and it drives a 10.4V PWM transistor… my old power supply outputs 10.4V instead 12V… I’m thinking of replacing it).  It pulled in 100mm of 3mm filament in 261 seconds, outputting 2045mm of filament that fell on the floor.

Based on that measurement, I calculate that the extruder outputs 7.835mm/s (470.1mm per minute); I’m sure it outputs a little less when gravity is not involved.  It pulls in 0.383mm/s.  Since the output rate is 20.45 times the input rate, while the volume is obviously the same, the output diameter must be 1/sqrt(20.45) = 1/4.522 of the input diameter, so the output is about 0.663mm wide.  Again, that’s with extra gravity involved; the real thing will be slightly fatter.  I’ve been using 0.7mm width as an estimate and I guess that’s very close to correct.