With apologies to The Graduate.
Years ago I was very interested in 3D computer graphics. This was back in the late 80s and early 90s when Silicon Graphics reigned supreme and simply being able to rotate a Phong-shaded object on the screen in real-time was a pretty impressive achievement. Today, of course, the cheapest computer can render in real-time scenes that would have taken days if not weeks to render even a single frame. Even more interesting to me, anyway, is that it is now practical for a hobbyist to construct a machine that can print out a 3D model as a real, functional, physical object.
3D rapid prototyping machines that can print out objects have existed for some time, and while the prices have been coming down in recent years, the least expensive commercial machines are still in the price range of a new car (~20k). As with any technology that requires an investment in expensive equipment there are business that will provide access to the machines for a price, such as Shapeways and i.materialise. Just send off your 3D design and some money and some days later your newly printed part will arrive via the mail.
RepRap is an open source/open hardware project with the goal of producing 3D rapid prototyping machines that can replicate themselves. The project was initially started as an idea contained in a paper by Adrian Bowyer that was published on the web on February 2nd, 2004 (Ref). While I personally think that the self-replication aspect is a bit oversold by some, the ability to produce a significant fraction of its own parts does prove that the machine is capable of producing functional as opposed to simply decorative parts.
It seems to me (and others) that the RepRap is very much like an Altair 8800. The Altair 8800 was the first microcomputer that was relatively affordable and widely available to hobbyists. It could be purchased as a kit or fully assembled and its base configuration included 256 bytes of ram. I remember first seeing a picture of it on the cover of the latest Popular Electronics in the library of the junior high school that I was attending at the time. No one at the time could have imagined that computers would one day be ubiquitous, used to produce and view graphics, music, videos and games (ok, maybe games, in the general sense, were foreseeable). At that time the Altair barely was capable of balancing a checkbook, although people in the know imagined that one day you could use one to hold and search all of your recipes in a small counter top device. Just like the Altair, the RepRap project has provided the inspiration for a variety of related projects and companies such as MakerBot and Fab@Home.
At this point the RepRap project is on its second generation machine, the Mendel. As designed it can print 3D objects in a variety of plastics, ABS and PLA being the most commonly used. Various people are experimenting with different print technologies, so the ability to print using different materials is experimentally available, with significant improvements foreseeable in the future. The quality is not up to the expensive commercial machines, but it can be used to produce functional parts.
I started working on building a RepRap style print head for my CNC’d Taig several weeks ago. Many of the parts were purchased (nozzle and Arduino and stepper driver, Peek thermal barrier, heater core kit and plastic filament), some parts were left over from other projects (geared stepper motor), and some parts I “designed” in CamBam and produced on the Taig (structural parts to hold everything in place, mostly). The design is roughly modelled on Wade’s Geared Nema 17 Extruder, except that I’ve used a stepper with the gearing built into the motor.
On Wednesday, April 21st, I attempted to print my first object, “Clouds”.
Oops. That print was quickly aborted. It turns out that the default extrusion rate generated by Skeinforge is much too high for the configuration that I’m using to control the extruder’s stepper motor. So, after some modifications to the AWK program that I used to massage the GCODE generated by Skeinforge so that it scales the extrusion rate and, after several other now forgotten false starts, my first object was successfully printed.
Ok, I really should have picked a more interesting object to print first.
The whistle rattles and whistles, but not both at the same time (that is, the ball in the whistle does not move in response blowing on the whistle). Also, the plastic I’m using is not food safe, so blowing on the whistle is not recommended. Besides, it tastes terrible…
This weekend I’ve been experimenting with settings, trying to tune the parameters in order to produce better quality objects. A dozen of the top half of the decorative container are shown below, printed using different speeds, layer depth, and flow rates.
Another test object, the Dodecahedron, is below.
The Dodecahedron has turned out to be a very good test piece. The left-most sample demonstrates what happens when EMC2 runs at a high feed speed in “G64” mode (that is, keep moving at speed regardless of how far from the stated points the tool has to be moved). This piece was printed at 32mm/s with a layer depth of 0.35mm. I’ve only had the Taig/EMC2 for a couple of months, so it took me a while to stubble across the cause of the problem.
The second and third samples are also printed at 32mm/s with a layer depth of 0.35mm. However, EMC2 was placed in “G61” mode (that is, move the the waypoint specified exactly, even if the tool must come to a complete stop). These are much closer to the desired result, but the acceleration/de-acceleration of the tool around the various waypoints leads to significant variations in the width of the extruded filament. In theory EMC2 should vary the speed of the stepper in the extruder in proportion to the speed of the tool in the XYZ axes, so I’m uncertain what is causing the effect. It might be due flaws in the extruder, or it might be due to non-linear effects in the melted plastic itself, or some other effect about which I’m currently unaware.
The forth and fifth samples where printed at 16mm/s with a layer depth of 0.4mm. EMC2 was placed in “G64 P0.1” mode (that is, the tool is allowed to be up to 0.1mm offset from the stated waypoint in order to keep the speed as high as possible). These are definitely better, but still show a significant variation in the filament thickness.
The final piece was printed using the same settings as the fifth piece, with the exception that the maximum velocity of the extruder was set to 15 inches per min (6.35 mm/s) within AXIS (the EMC2 GUI). This produced by far the best copy, but at a very significant increase in print time. The other thing to note about the final piece is the fact that scrap CDs make a very good print surfaces for small ABS objects, unless you print the first layer too close to the CD, in which case the ABS welds completely to the CD.
Of course, I don’t know any better than anyone else what the future holds, or what place RepRap will hold in the future. While I think that the RapRap is akin to an Altair 8800, it might turn out to more closely parallel CB radio. Anybody remember what that was?
In the nomenclature of the RepRep project what I’ve constructed is an EmcRepStrap, a RepRap bootstrap device using EMC2 to control at least the XYZ axes. Within the family of EmcRepStrap designs there are two different approaches to controlling the extruder: one that uses the standard RepRap extruder controller to control the motor and some software that extends EMC2 so it can communicate with the extruder controller, and one that uses EMC2 to control the stepper motor in the extruder directly. The second approach, which is the one I used, is described by David Carr. I’m using an Arduino to control the temperature of the extruder and the Arduino is currently not controllable from EMC2, so only a single fixed extrusion temperature is used.
The following AWK script was used to convert the GCODE produced by Skeinforge into a form that can be used by EMC2. This code allows the A axis values to be scaled by a parameterised constant. As it turns out this scaling is unnecessary as the values can be scaled in Skeinforge directly by changing the Speed:Flow Rate value in the Skeinforge configuration. I’ve left the feature in the AWK code as it is convenient to be able to change the scale on the A axis without re-running Skeinforge. The code also inserts the lines “G64 P0.1” and “G92 A0” into the output. The G64 so that EMC will not decide that missing a waypoint by anything more than a tenth of a millimeter is allowable, and the G92 line resets the A axis to 0 before it is otherwise used (which avoids an issue with the A axis position left over from previous runs).
The AWK code I used can be found here
Assuming that your A axis is set up in EMC2 so that a value of 1 indicates 1 degree of rotation on your pinch drive and that your pince drive is 3/8 inches in diameter, a Speed:Flow Rate value in Skeinforge of something around 8 to 13 is much closer to correct than 210 (the default value).