The Raft is pretty important to a print job.  Smaller prints might squeak by without a raft at all, and middle size ones won’t curl up too bad if the raft isn’t there or is defective, but for big jobs, the raft is mandatory, and a build won’t make it if its raft isn’t laid down right.

In skeinforge terminology, the Raft consists of two parts: the Base and the Interface.  The base is a set of thick, heavy lines whose purpose is to glue the raft to the build base.  The Interface is the relatively thin lines that criscross on top of it to provide a level surface for the build.

The Base layer thickness over infill thickness is the speed of the print head relative to the standard feedrate.  Moving half the speed as in the above settings, the print head deposits thick plastic which sticks to a build base like hot glue.  (Like hot glue though, it’ll peel off if you stick your fingernail under it.)  The Base Infill Density is how far apart these layers are, set here to have a spacing between them about equal to the width of the lines.  (Hence, a density raio of one half.)

The Base Layers number is how many of these layers are used.  I have only used one layer for builds with a raft, or zero for builds without one.  Making the nozzle lift less than one standard layer (here it’s 0.75 of one standard layer) means that the nozzle will not raise up as far as it would for a standard layer, which like the other options is designed to flatten the plastic of the raft out so it will be better as a glue for holding the object to the build base.

These numbers repeat for the interface, and mean about the same thing.  So far I’ve used 1 or 2 layers for the interface, depending on how worried I am about the object curling up.

I have done builds without rafts on occasion, when a build is small enough that I’m not worried about it curling up.  However I never do it by clicking those disable check boxes.  Doing this seems to make Skeinforge center the build around zero, which can make it very tricky to correctly position the print head.  A better solution is to leave the raft turned on, but set both the base and interface layer counts to zero.

2D line-division type fractals are pretty easy to create on the MakerBot as it happens. Recursive algorithms can neatly define the act of repeatedly inserting a sequence in between copies of itself to generate the Coch Curve and other related shapes. Further, a wealth of algorithms have long been known for generating fractals for pen plotters, and shapes like the above Coch Snowflake are just a matter of repeatedly performing those very commands at different elevations of the tool head.

3D fractals, like the Serpinski sponge, aren’t as easy to create. The Serpinski sponge in particular has overhangs that will make it poorly suited for printing on a non-support printer, and although the self-similar nature of fractals may make it plausible to make 3D fractals which by construction do not need supports, the added complexity of the formulas, coupled with their lack of innate suitability to the plotting method will cause some trouble. Also likely to cause trouble is the lack of study in this field– 3D fractal research has been done with polygon modeling or point clouds more often than with 2D slicing.

However, I think this is a really important area of study for a number of reasons, one of which is that the biological world consists more or less entirely of 3D printed fractals.

Of course the 3D printing that goes on in our cells runs on vastly different hardware: 1D extruders called ribosomes spray out chains of amino acids which electrostatically contract into useful objects like cellulose molecules, enzymes, and other ribosomes, (mother nature’s repraps are miniaturized!) but at each step of the way, you’ll find self-similar patterns, from the repeatedly-coiled helices of our DNA to clusters of hair follicles, all of which are defined at the bottom level by extruder modules, positioning themselves in three dimensions using relative coordinate systems based on chemical gradients and other signals to create macroscopic machines of dazzling complexity, such as cats.

3D printed fractals made of ABS plastic probably won’t do things like replace lungs, but the research we in the open-source 3D printing community do to make pretty trees and self-similar LED fixtures may inform future efforts in printing with PLA and later more advanced biomaterials to create support structures for re-growing organs or optimize surface area to volume ratios for biological experiments.

There is a revolution in molecular assembly coming, and regardless of whether the biologists and chemists or the engineers and machinists are the first to arrive at a general assembler, I expect that getting there will require fractal geometry, not the Cartesian stuff we’re used to. And learning how to map between the two domains is something we really can learn by designing 3D printed fractals.

This sweet machine by Simon Kirkby is another great example of servos and printed parts working together to create really impressive engineering feats!  I did a search for such devices and they can get rather pricey, so this is also another big bonus to the “3D Printer Basket” of goods available to a new user of a 3D printer without modifications.

I’m also really excited about how the low-end 3D printer segment of the market has grown enough in such a short time that a large fraction of the 3D designs uploaded to Thingiverse come with pictures of actual test prints!

In my many posts on the Real, Serious Economics of Personal Fabrication I’ve kind of ignored a big part of what’s going to make personal fabrication grow tremendously this decade.  (Already happening– Ponoko’s USA office is getting orders hand over fist in THIS economy!)  The thing I’m talking about– and the thing which I think is responsible for Ponoko’s success, is how much FUN it is.

Designing something and then having it is very core to the human experience.  We care about making things.  And digital fabrication is making it easier to design things that really will work when we put them together.

I think a part of the Singer Problem, the list of reasons why sewing machines aren’t presently everywhere, is that feeling we have that we won’t be able to actually make things we’ll like.  Starting up with a sewing machine means a pretty big investment in time and money just to *find out* if we’ll be able to make something we’ll like.  Digital fabrication softens that blow.  It softens it by enabling companies like Ponoko and Shapeways to let users try fabbing systems once without owning a White Elephant of a system if they don’t like the results.  It softens it by making fabrication more automatic and thus, less dependant on muscle memory and other things that take a long time to train up.  It softens it by transforming the skill into software, letting incremental understanding turn into real understanding as users first fab things wholly designed by others, then things they tweaked, and finally things they created.

Digital fabrication might have a big impact on the future as much because of how much fun it is as because it is useful.

Skeinforge: Too Many Options

Skeinforge is a pretty big bundle of scripts, and having a first flawed build as your only reference point for going in and fixing the settings can be a pretty daunting task.  Rather than try to provide a full manual, I’m going to present this the way I learned it: one feature at a time.

There are probably well over a hundred teeny tiny knobs you can turn on this beast, but the first one we’ll cover, and one of the more important ones to getting decent builds, is the Speed control:

The Speed dialog box controls both how quickly the XY CNC machine will move and how quickly the extruder will push the filament.  If your default settings are giving you messy or stringy builds, this dialog can probably help you.

Key vocabulary words here: Feedrate and Flowrate.  Feedrate is how fast the tool head moves (or in the case of the MakerBot and McWire, how fast the XY table moves) and the Flowrate is how fast the extruder is extruding.  For a clean build, both of these need to be about right with respect to each other, and unfortunately I’ve found it to be a bit of a trial and error process.  (MakerBot users: got a favorite setting for this?)

I like to start from the assumption that I want maximum flowrate (255 on PWM settings) and then set the Feedrate high enough that the bot moves so quickly that this is okay.  This can cause trouble if you’ve got a bot that stops at the end of a line segment in skeinforge, as your effective feedrate will be much slower in more polygon-dense areas.  However, I think the current firmware for the MakerBot and other Sanguino-based implementations has buffering which solves this problem, so going for a high feedrate/flowrate pair is probably ideal in most cases.

With the flowrate set where you like it, you’ll find higher feedrates result in stringy, sparse builds if it’s set too high, and gloppy, heavy builds which rip off the build base as the nozzle picks past dried plastic if it’s set too low.  (I find the latter is way more unpleasant than the former, so I shoot high on feedrate.)

More Skeinforge tips to follow: one bite at a time, it is learnable.

There’s a ton of great stuff in this talk– Charles Eames is one of my new-old heroes: new because I just found out he was the inventor behind a LOT of things I admire, old because a lot of them are things I’ve admired most of my life!

The Chimerica project is pretty cool, but what gets me is this statement by Eames: “Beyond the age of information is the age of choices.”

VERY relevant to Thingiverse, that.

Once again, the Thing of the Week was a pretty hard call.  I mean, there was a slingshot, neatly-labeled measuring spoons, and even a set of awesome alphabet blocks!

But in addition to that, we’ve also got this.  A user who has printed out a copy of his own head!  Bre is probably on to something when he talks about a future where custom-fit biometrics are available to personal fabricators, and here we see the beginnings of that.

Looking forward to a “personal biometrics” category of things on Thingiverse!

Some nitty-gritty on parametric 3D printing.  The print head’s movements are intrinsically a parametric equation, since it moves in x, y and z as three functions of the time, t.  For this reason, any printable shape at all could be described by a sufficiently complex parametric equation.  A lot of shapes are easier described by the descrete assembly of lines generated by analyzing mesh data, which is why we have Skeinforge, but this post is about how to actually make 3D prints of parametric objects, so let’s get started!

You can download the GCode-spitting scripts I’m using to see this all in action.  I’ve tried to comment these scripts pretty generously, but if I’ve left anything out, leave a note in comments and I’ll see if it can be made clearer.

First, there’s the setup GCodes and MCodes, a lot like what you’ve seen at the beginning of other GCodes.  No raft this time, but if you want one you can always build your own; they’re pretty easy to bodge together with for loops.  Next, the loop structure of these parametric prints matches the behavior of a typical 3D print: describe the geometry of one layer on the innermost loop, and then have an outer one which increments the position of the z-stage by one layer thickness.

This structure is about the only thing that’s locked in for parametric printing.  (You can probably even break that rule, but you’d better know what you’re doing if you do!)  From here on you can do pretty much anything, although remember there’s no skeinforge settings here to rescue you if there’s overhang.  When parametric prints go bad, they can go really bad.  However, once you’ve written out to GCode, the viewers that come with Skeinforge can be used on them.  (Skeinview is a great sanity check here!)

On to what I’ve done so far: most of my 3D parametrics so far have been straightforward combinations of trigonometric functions.  One nice thing about trig functions (at least, sine and cosine) is that they will never return values outside the range [-1, 1], making it easy to predict and control the size of a 3D print, if not its exact shape.

In para_02.py you’ll see the trig functions being used for one of their simplest parametric applications: describing a circle.  On each layer, X is set to the cosine of the input and Y is set to the sine.  The print head moves in 62 steps of a tenth of a radian each, drawing a circle, and then moves up to the next layer.

The 2D profile laid down on each step can be a function of the current height, so there’s no need for parametric prints to be simple profile prisms.  I’ve experimented with scalling the profile by Z (multipy xval and yval by some function of zval) and rotating the profile, which is done by the following formula which you may or may not remember from Geometry class:

x’ = x cos T – y sin T

y’ = x sin T + y cos T

Note in my example I’ve pulled x’ and y’ off to the side so that calculating x’ doesn’t mess up the value of x when calculating y’.  In para_03.py I made it a function GCode objects can perform on themselves.  The range of spiral shapes and wobbly surfaces that can be concocted from just these base parameters is pretty broad, but there’s a lot of room to explore.  Here’s some things I haven’t done yet, but which someone should:

* Threaded rods and worm gears are screw-spun extrusions, which should be a natural fit for this technique.

* Any profile at all can be used as a base, up to and including pre-computed profiles and solid shapes peeled from Skeinforge output.

* Parametric equations for step functions would be if statements.  A big list of things could be done this way.

* Shapes represented in polar coordinates could be generated using the inner loop as an iteration on those instead.  Z would probably have to stay Cartesian though.

* Recursion and relative coordinates for fractal boundaries.

* Hijack some of Skeinforge’s functionality, calling functions like infill from within the GCode-generating script to extend the capability of parametric modeling dramatically.

* Integrate a formula box with a code-generating script and a 3D GCode viewer to create a parametric modeling suite.  (Hey, I can dream, right?)