Saturday, 20 April 2013

Printing - Test Objects And Other Things

Thing 64549 by Conseils - derivative:35077
There are many test objects on Thingiverse for 3D printers, each with its own particular purpose. Recently Makerbot released its own STL test object into the wild. According to the Makerbot blog, its primary intention is to test slicing engines. Below is how I managed with Thing 64549 on Huxley #710

This month has been about design and printing rather than twiddling with Huxley#710. I also ran a rapid prototyping course for my colleagues so they could appreciate some of the benefits and limitations of 3D printing technologies.

You can see the printed test object in PLA Faberdashery Village Green. I chose this colour for a number of reasons. The main being I had sufficient for the print, I also like the colour. But the second reason is our eyes are most sensitive to green / yellow additionally my camera seems to represent the colour well. Finally, it was in the printer as we also use it for printing Minecraft creepers, which the boys have been selling at school. The youngest forgot to negotiate with the manufacturer and was surprised the manufacturer had to make a profit too! More than one dimension to using a 3D printer, practical lessons in business, scheduling, bills of material, quality, design for manufacture, costing and so on!

Dimensional drawing of Thing 64549
Slicing the object took around 4 hours and I left it to run without monitoring the computer. I had no problems using the original file, which seems to have been a problem for some peoples slicing engines. Of course this would appear to be the principle purpose of the file, to test slicing engines. So an STL clean up could be considered an unrealistic test at some levels. Netfabb reported the model file Manifold, however InStep reported a few inconsistencies in the file. Knowing the tool chain used to produce the STL file would be helpful to know what the design intent is for various features in the model. So the usefulness of the STL file without this information is somewhat limited.

We can't for example understand what influence the specifying geometry has interacting with the STL generation. Although not the principle purpose of the test, it would non the less be very useful. For example my CAD program has limited (crippled) STL output resolution for curves. You can see this sometimes where peoples STL curved features have steps in them. As the STL is after all generally triangular facets, the output filter will also usually set an angular resolution. As an STL object though, it has features which clearly 'stress' a slicing engine.

For the test object the following tools and settings were used for printing:

Sample Part Manufacturing Technical Documentation
Printer : Huxley #710 (RepRap Pro)
Firmware : Marlin 1.0.0 RC2 - 15 Feb 2013
Software : RepRap Pro Software 811708f - Pronterface
Material : PLA - Faberdashery - Village Green
Material Dia. : 1.75 mm (Msd 1.80 mm )
Nozzle : 0.50 mm
Layer height : 0.25 mm
Layer width : 0.6 mm
Extrusion T : 198 C
Bed T : 60 C
Feed Rate : 28 mm/s
Perimiter rat. : 0.5
Cooling Fan : Yes
Bed material : Borosilicate Glass
Over hangs : Yes
Support : No
Print Time : 04:37
Material : ~ 21.2m

Model Tools - Used only for inspection of the design in this print - Original file sliced
Function: Model Fix up
Tool: NetFab Studio Basic
Version: 4.9

Thing 64549 by Makerbot
Comments
The design of this test beast is quite nice and there is clearly some thought put in the model. I saw some reports of issues, but I had none. It printed straight from the model which is important, if it's the slicing engine you are trying to benchmark. Although the 21m of filament and 4 hour print time with my default settings mean I won't be repeating a print of this soon.

The slicing engine put in a full solid layer across the 4.5 mm first platform step from the bottom. This would only really be needed under the bridged area above the spiral and cylinders. The Slicing engine has obviously simplified the representation, using quite a bit of plastic in the process. As this could have been left open being and interior feature. Additionally it would have made the print easier reducing shrinkage forces, to assist with polymer bed adhesion. This effect occurs each time a new layer of the same type is employed. Subsequently leading to shrinkage distortions in the part, visible as irregularities in the wall edges.

Generally quite happy with the results. Especially bridging, as I always thought it was a problem for Huxley #710, it appears not. Though clearly a fan is required. In fact I think slicing needs modifying for unsupported overhangs to modify the extrusion rate and nozzle velocity. I imagine Makerbot are checking filament quality as well with all the colours shown in the article. As printed items will be affected by filament diameter, melt viscosity etc. which will be influenced by the additives in the filament and base polymer quality.

From the reference page here are my results
1) Some spiral elements not filled
2) Block dimensions good (+0.15mm)
3) Internals spurs as Makerbot example
4) 5.5mm high, not quite square as per the model. No output from slicing engine.
5) Beautifully flat
6) All bridges correctly formed, some minor sagging. Does require a cooling fan.
7) Wall clearly don't have spurs but there are some interesting effects from quantisation, rounding and flow. Otherwise quite good.
8) Cylinders appear round 9.95, 8.18, 6.09, 4.16, 2.31
9) Removal gap, not needed with the glass bed.

Makerbot annotated view of Thing 64549
Summary
The quality of the slicing engine clearly has an important impact on what's printed, of course tuning and alignment matter as well. I quite frequently find myself designing around the slicing engine and printer, in design for manufacture. An improved slicing engine would help and I suspect there are more parameters to be considered in the design than called out above.
Some tuning is required to my retract rate for the nozzle plastic as I have little blobs at the start of extrusions which might be improved. This would impact both the pyramid and 2.00 mm cylinder.
Huxley #710 is performing nicely though.


There is a huge amount we don't know about the object, related to the tool chain used in its creation. So the value of its release is limited, perhaps intentionally. The drawing of 64549 included here should help if you want to better understand the meaning of your print. My CAD program would not generate the same font used in the test object and the STL to STEP converter I have being testing could not handle the large STL file or small sections, an unintentional benefit. I did send it to Solve Engineering but am awaiting a response. I also discovered limitations in my CAD program's ability to produce spiral features, which would require some script to overcome. STEP files of my model and a no version model can be downloaded from the associated links if you want to test your own tool chain.

Here are some useful CAD, Meshlab and Netfab views of the object. The intention of the Meshlab views here is to show the mesh construction. The STL could have had included errors in it.In order to test the slicing engine.

Meshlab rendered view of Thing 64549

Meshlab Wire frame view of Thing 64549

Meshlab point cloud of Thing 64549

NetFabb rendered view of Thing 64549

NetFabb mesh view of Thing 64549


Here are a few of the Things we have printed this month.
Derivative 34708 - Earbud holder


Just because it was useful, Thing 53455.

Derivative 25949 - Compressor Wheel

1 comment:

  1. Conseils,

    Great blog post! You've clearly got some great prints coming off of your Huxley and I'm sure the level of detail you put into your testing is one of the main reasons. I was inspired by your detailed analysis, so I did a few tests with the MakerBot test object as well. I wanted to offer up a few additional comments that might be worth noting. While MakerBot describes this object as something used to test slicing engines, I think the resulting print is also heavily dependent on the firmware being used. As you can see in your wireframe view, this object has an extremely fine mesh density around the spiral and cylindrical towers. This typically creates thousands of incredibly tiny linear G1 moves, which will take time to be processed by the microcontroller firmware. Better firmware will be able to process these commands faster, whether printing from an SD card or via USB. There's a good chance MakerBot is also using this test to evaluate their firmware updates to ensure all of these tiny moves don't bog down the firmware calculations. It looks like you're using Marlin RC2 which is pretty good at this, but this was a big issue for most firmwares about a year or two ago.

    A lot of my observations on the final part were fairly similar to yours. The one huge difference I noticed was the slicing time for the part. Using our new slicing engine, I was able to slice the part on my laptop in under 3 minutes. I almost fell off my chair when I saw it took 4 hours using Netfabb! I applaud your patience for being able to wait that long :) Like I said, I was really impressed with the level of detail you put into your analysis, so I'd be happy to provide you with an evaluation version of our slicer if you want to see how it performs with your Huxley. It's a fairly new software package, so I know we would appreciate the feedback.

    Keep up the good work! We have a lot of engineers here so we always enjoy reading your work.

    ReplyDelete