Throughout the anticipation of the delivery of the Ultimaker (4 to 6 weeks — as are pretty much all 3D printers these days!) and the week of assembly (another post), I spent a bunch of time researching software and otherwise attempting to grok the toolchain without a tool to apply the chain to.
In short, 3D printing requires a slew of tools and the tools are⦠ugh⦠unrefined, if not downright user abusive. Not that this comes as a surprise. Affordable 3D printing is a very new market and it’ll take a few years for the science to be nailed down enough that an easy UI can be wrapped around it.
And it is moving rapidly. Thus, if you are reading this anywhere after about 3 to 6 months from now, it is likely that the landscape has changed.
As well, this is a decidedly Mac OS X centric / Ultimaker centric view of the world. I’ll likely update again in a month or so after I’ve set up the Printrbot.
To drive a 3D printer, there are quite a few stages of software that are employed. In the maker world, there are generally multiple answers to any given stage in the overall chain. If you are working with a commercial printer, it is likely that the stages closest to the printer — the driver, assuredly, maybe more — are fixed.The stages generally are (here is a handy diagram with discussion, too):
1. Design & Modeling
Before you can print something, you have to have something to print!
Just like 2D images, there are quite a few ways you can use to create or obtain a 3D model for the purposes of printing. Regardless of which method or software you use, the end result pretty much must be an STL file which describes the geometry of the object to be printed. More precisely, an STL file is a fairly standard interchange data format that provides a minimal description of a 3D shape (without color, texture, lighting, or other decorations).
As for sources, a great starting point is Thingiverse which offers a huge library of digital designs aimed at created real, physical, objects. While there are non-3D-printing oriented designs, the majority of the things on the site are targeted to 3D printing and, thus, offer STL that is generally ready for the next step of processing. Most of the designs also offer the original editable models that can be modified at will.
If you want to design your own parts, there are a couple of different primary means of doing so. You can go with a CAD package of some kind which can range in price from free to about a bazillion dollars. On the free front, Google’s SketchUp is very popular but I find it to be maddeningly frustrating to use. Personally, I’ve settled on Punch! Software’s ViaCAD (Mac App Store) for $99. ViaCAD provides much better control and feedback over the modeling process and the 2D->3D integration makes modeling of many simple things quite trivially easy! While I also find ViaCAD frustrating, it at least feels like the frustration is my own doing and, thus far, the primary author of the package has been incredibly supportive in the user forums.
I’m really hoping Autodesk’s 123d is released for the Mac. Autodesk has also announced Inventor Fusion for the Mac; it looks to have considerable promise, too!
An alternative to CAD is to go with a parametric modeler like OpenSCAD. In OpenSCAD, you basically describe systems of equations to render your 3D objects. It solves a completely different problem than a draw-in-3D CAD solution. For example, this “thing” is a parametric box where you can easily determine the height, width, number of compartments, and wall thickness just by changing a couple of variables. Even cooler, this thing provides everything you need to generate and print Lego blocks, including the never-before-seen “trilego” (an example I printed is pictured to the left).
In any case, whatever means you choose of generating a model, the end result of this step is generally going to be an STL file; a minimalistic, unadorned, inventory of triangles that roughly (or accurately, depending on export settings) describe the shape.
2. Pre-press Preparation & Repair
If the output of step (1) is particular good, then this step is pretty much a non-step.
Namely, an STL file might have any number of errors within that are invisible when rendered to the screen, but may cause all kinds of problems in the next few steps.
As well, the object(s) described in the STL file may not be rotated correctly or might not be “on the bed”. That is, the object(s) need to be aligned such that “up” is in the direction of printing and the “bottom” is on the surface that represents the printer’s printing surface.
Thus, in this step, you should rotate the object into “printing orientation”. Most software offers some kind of representation of “printer plane” and, in the case of ReplicatorG, it provides a one step means of centering an object on the print bed and making sure it is actually on the bed. An example of ReplicatorG manipulating an Octopus STL can be seen at the right.
Netfabb Engines — another tool that I’ve used, but whose bugs are bad enough that I wouldn’t recommend — can detect and [maddeningly not due to bugs] repair errors in the geometry of the triangle mesh. Errors like triangles that are facing the wrong direction. Holes in the mesh that violate mesh consistency.
There are a number of other solutions out there; many many solutions, ranging from free to very very expensive.
3. Slicing & GCode generation
Once the STL has been cleaned up, the next step is to turn the objects into a stream of commands that can be sent to the 3D printer for the purposes of printing the object. While this is called slicing, that name is a woeful understatement as to exactly how complex, critical, and potentially time consuming this step can be.
A naive slicer might simply slice the model into a series of planar cross sections and then send the print head on a path of simply filling in each planar slice. Not only would this yield horrible print quality, but it would waste a ton of material. For example, given that octopus seen above, there is no reason why the entire head need be composed of solid plastic! Of course, nor can it be entirely empty as that would make it impossible to close over the top of the head because all that overhang over empty space would simply sag as it is printed!
So, typically, the slicer generates commands to move the print head along the outlines of the piece while also creating minimal fill to save material. But it can be even more complex than that! The slicing software may have the notion of head momentum, might have knowledge of the “stringiness” of material (the tendency for the material to draw out tiny threads when extrusion stops), and/or might model what happens as the head turns corners (extruded material behaves differently in a straight line vs. turning corners).
Or the slicing software might model many, many, other potential details. This is one step in the process where, truly, there are entire companies dedicated but doing nothing but generating the most efficient possible tool paths that produce the highest quality output.
And that output is gcode, a very widely used — standard, even — programming language for computer numerical control [CNC]. It is far from limited to 3D printers, controlling just about any CAM/CNC machines these days and having a history that spans back to the 1950s!
For 3D printing, the most popular gcode generator is SkeinForge. It works well and ReplicatorG typically comes with several versions built in. SkeinForge, however, is not fast.
Netfabb can also generate gcode. I haven’t tested the output yet (and intend to do so).
New to the maker/hobbyist market is Slic3r. It is reasonably fast and has a pretty straightforward UI. As it is pretty new, there aren’t much in the way of Ultimaker specific profiles available yet, but that is likely to change rapidly.
At the time of this writing, this is an area I’m actively investigating. SF+Replicator is woefully out of date, thus it is a matter of installing SF and using it from the command line. Slic3r looks very promising. Netfabb needs to be tested further as it has promising gcode generation capabilities, but can’t talk directly to any printer due to bugs [on the Mac version anyway].
4. Host Side Printer Driver
The host side printer driver deserves a mention. It is really simple in role, but very important. The job of the printer driver is simple; spew the gcode at the printer as fast as it can take it, but not faster. Ideally, the printer driver software should also be able to monitor things like the extruder temperature without screwing up the print, allow the user to interrupt the print, and provide a manual control mode for controlling the printer.
ReplicatorG mostly does this, but if you leave the control panel open during the print, it tends to make the print head pause periodically which causes blobbing.
Netfabb is supposed to be able to control the printer, but it doesn’t even detect the printer due to bugs in the current Mac OS X version.
Beyond that, there is Printrun, but it looks pretty tedious to install.
Of all the pieces in the puzzle that is 3D printing, this is the one that I’m likely the most tempted to roll my own Mac OS X specific solution. What is available is just really primitive and user abusive.
5. Printer Firmware
Of all the pieces, this is the one that I fully admit to understanding the least. Yet, it is critically important (i.e. I need to address my ignorance shortly).
Out of the box, the Ultimaker ships with relatively conservative printing firmware that isn’t particular fancy or fast, but produces relatively forgivable prints at a reasonable speed.
With the Marlin firmware, potentially insane speeds are possible while achieveing an even greater degree of accuracy.
Whereas the gcode generated is more or less limited to “go to this point at this base speed”, the firmware apparently controls things like acceleration and deceleration to make it possible to go from A to B at a very high rate of speed while also stopping exactly where expected and changing directions in a predictable fashion.
All in all, much to learn. Next, I’ll write up the build notes for the Ultimaker, including errata, hints, and the adventure that ensued when my extruder fan shattered and I had to figure out how to attach a different sized fan (hint: it involves designing a cooling solution that could be printed without a cooling fan in place⦠then printing it again with the rough version to produce a much better version).