The Rack

IMG_1441Q.jpgRecently, I wrote about one of my designs in a “non-3d-printing” web forum. Since most people over there didn’t know anything about stuff like MakerBot or RepRap, I was asked a lot of questions on 3d printing lately.

One frequent type of question was about the stability and rigidity of printed objects.

Of course, there is the normally pitched answer “it’s the same stuff Legos are made of”. And (at least in case of ABS printing) this is certainly true. But almost anytime I give (or hear) this answer, I think: … well, it depends.

Although 3D printed objects are likely out of ABS, there is one huge difference between 3D printed objects and injection mold Legos: Printed objects are layered. So when it comes to rigidity, they are much more like wood than like “atomic” Legos.
That’s why I prefer to compare printed objects -regarding rigidity- with wooden parts instead Legos.
IMG_1455.jpg
In my experience, it’s quite important to consider the layer orientation of a printed part during the design process. When building wooden objects, a stressed span is less likely to fail if tension is applied along the grain, rather than across the grain.
The same is true when printing 3D objects.

Of course, sometimes you need to compromise in order to print a complex object in one piece. And this might be ok as long as the “against the grain” parts aren’t stressed too much.
But sometimes it is way better to split a complex object into two or more parts and bolt (or glue) them together after printing, in order to get the layers into the “best” orientation for each part.

One of many examples of compound objects (to gain more rigidity) is the Adrian’s geared Mendel extruder:
IMG_1443.JPG

Technically, it woudn’t be a problem to print the base plate, the stepper motor retainer and even most of the gear retainer as one single, complex object. But then you’d have to decide in which direction you’d print the object. Besides some restrictions due to overhangs, the main problem would be that either the base plate or the motor & gear retainers would loose a lot of their rigidity when not printed “with the grain”. By breaking down the complex object into 3 or 4 parts, the whole thing not only gets easier to print, but also the assembled full object gains a lot of stability.

However, I recently began to wonder, if I could do some test to measure the strength of similar printed objects, depending on the orientation they are printed in.

To measure the rigidity and strength of printed objects, I decided to print a basic shape in different print orientations and then use a rack to rip the objects apart, measuring the needed force.

IMG_1446.JPG

Given a basic “monolith” shaped object, there are three different ways to print:

1. laying down on it’s face:

IMG_1247.JPG

This would be the “natural” orientation to print such an object for most of us 3D printer operators. Besides much less problems with printing the infill, this orientation also puts the “grain” along the widest span of the object.

2. laying on it’s side:

Although this changes the order of layers, the grain still runs along the widest span. So (besides likely more problems with printing the narrow infill), the resulting object should be as rigid and stable as an object printed laying on it’s face (1.)

3. standing upright:

IMG_1245.JPG

Printing a tall object this way usually means trouble. Not only the longest side of the object will be against the grain (and thus more likely to chip off under load), it’s also harder to print thin, tall objects on a FDM printer like the Makerbot or Reprap for several reasons.

But sometimes there’s no good way around printing a tall object in upright orientation,…

IMG_1249.JPG

4.

And then there was a fourth way to print a tall object. I had this idea a while ago and really wanted to finally try it: The object is still printed in upright orientation, but using some kind of “interlock” between the infill layers. See the following cross sections:

Instead of using a normal infill like this:

normal-infill.png

… the infill would printed in an alterning pattern like this:

bonding-infill.png

As far as I know, this kind of layer-crossing infill isn’t supported yet by any slice’n’dice utility out there.

In order to generate Gcode for the test objects, I wrote a little Perl command line tool. This script generates Gcode for “2001: A Space Odyssey” style monoliths in three different types:

“Mode 0” – The object is printed laying down on it’s face (see above “1.”) with a normal 100% infill.

“Mode 1” – The object is printed in upright position with a normal 100% infill.

“Mode 2” – The object is printed in upright position with the above described interlocking “bonding infill”.

If you’d like to play around with the script, you can download it from thingiverse: http://www.thingiverse.com/thing:5069

Calling the script without arguments, shows a short usage text:

zaggo$ ./monolith.pl
Usage: ./monolith.pl --mode <mode> --out <output path>
[--lw <layer width>] [--lh <layer height>] [--fr <feedrate>]
[--lenf <length factor>] [--depf <depth factor>]
[--heif <height factor>] [--preface <path to preface file>]
Mode: 0 = flat
      1 = high
      2 = bonded
Size: lenf/depf/heif are factors of layer width
Defaults are 10 x 40 x 90 (1:4:9)

There are two mandatory attributes:

–mode defines the orientation of the object on the build platform and the infill algorithm.

–out sets an output file for the generated gcode.

So the simplest way of using the script is like this:

./monolith.pl --mode 1 --out outfile.gcode

This would generate a file (“outfile.gcode”), containing the gcode for the default monolith, printed in upright orientation with a normal 100% infill.

You can easily adjust the gcode for your needs (or your printer’s specific extruder specs) by using the optional arguments. For instance, use –lh to set a custom layer height (default is .45mm) or –lw to set a custom layer with (in mm! If not set, the script automatically calculates the layer width by multiplying the layer height by 1.4).

Since the script doesn’t generate any startup code or temperature settings, you probably want to use the –preface argument to insert custom preface gcode at the beginning of the output file. I simply use the standard preface gcode file, I also use as preface in my Skeinforge settings.

I started with objects in the default dimensions of the script and a simple unmotorized version of the rack. But it turned out, that the printed objects were way too stable for the tests and that using the rack with a wrench was really time consuming.

The pocket balance I use to measure the pulling force has it’s maximum at 25kg (about 56 lbs). During my first tests, the Mode 0 monolith chipped off at 20kg.

The Mode 2 monolith was even more stable: I was able to crank the rack up to it’s 25kg limit without breaking the monolith (with it’s grain across the pulling force!). I let the whole setup sit for a while, just to check if the monolith would withstand the pulling force for longer than just a few moments.

IMG_1305.JPG

After about 5 to 6 minutes the rack finally snapped. But it wasn’t the monolith that cracked, it was the wooden base, holding the monolith…

IMG_1371.JPG

So I printed the monoliths a little bit thinner (using the –depf argument).

Because of the thinner shape (and the resulting issues with still hot ABS in lower layers), the printed objects had slightly different dimensions (although the gcode used the same dimensions). I decided to adjust the –depf argument for each mode, so the resulting objects had the same dimensions after printing. On my Makerbot, this resulted in printing the Mode 0 monolith with –depf 8, the Mode 1 monolith with –depf 6 and the Mode 2 monolith with –-depf 5.

With these settings, I got the 3 types of monoliths, all with the same thickness of 4.6mm.

IMG_1255.JPG

I also improved the rack by using an electric screwdriver as motor:

IMG_1452.JPG

The monoliths were clamped to the other end of the rack:

IMG_1448.JPG

With the thinner monoliths and the motorization, the rack worked much better and smoother:

IMG_1429.JPG

IMG_1431.JPG

IMG_1433.JPG

Here are the results of my tests:

Mode 0: 14.5kg

Mode 1: 8.5kg

Mode 2: 12kg (!)

As expected, the Mode 0 object was the sturdiest.

I’m still surprised, how stable the upright printed object (Mode 1) was. I guess, using more common infill rates (like 15 or 20%) lowers the rigidity of such objects immensely and the results would be much more than I expected. Printing the objects with an 100% infill seems really to make sense if you need a maximum of stability. I guess it would be great if there was a way to manually define parts of an object to be printed with a higher infill rate than the rest of the object.

A great success was the test of the Mode 2 object. Interlocking the infill really seems to make a big difference. The object was much closer to the stability of the Mode 0 object than the Mode 1 object. Maybe there will be a way to generate such type of infill with Skeinforge in the future…

During my tests, I ripped apart a lot more monoliths than just the three above. Although the other objects weren’t all the same size and thickness (and thus not easily comparable to the above standardized objects), the reults of the other tests went all in the same direction (Mode 0 strongest, Mode 1 weakest, Mode 2 much stronger than Mode 1).

I’ll probably try some skeinforged monoliths, with different infill rates, in the future…

Finally, here’s a short video of my tests:

One comment

  1. Awesome work! It’s great to see such and intellegently constructed comparison. I’ll keep it in mind while designing parts.

    Also, great idea with the staggered layering. I hope some of the Skienforge programmers are in the loop on this. Have you any ideas on how to address the problem that an external wall, with layers stacked directly on top of each other would be a different height to your staggered internal layers? Perhaps a slower feed rate to thicken the internal extrusions?

Leave a Reply