Monthly Archives: September 2012


More Wood Composite Printing

A short post to give some more feedback about working with the wood composite. I decided to print out “Working Micro Gear Heart Keychain” by CrazyJaw.

Heart Gears – Under a Fluorescent Lamp

The stuff really sticks nicely to the bed without it having to be heated with no curling. The gear heart trays are quite small so I will try and print something larger to see how well it copes.

It acts largely like PLA, but oozes much more. I had to up my retract settings a little, and it still blobbed quite a bit. I was printing at 195°C and so it may be that a cooler hot-end might reduce the ooze. I chose 195°C because I got the impression at 185°C it came out a little rough. Now I have a couple of prints done I will be more daring and print at 180°C for longer.

An interesting observation is that the visibility of the layers, which is usually something we try and minimise, becomes a feature aesthetically. It gives the print more of a wood grain look. The photos were taken in a range of lighting conditions to try and convey how it looks.

Heart Gear – Daylight

The parts still feel, and act, like a polymer, which is to be expected, but it has a much rougher finish – at least at the temperatures I have been using so far.  Directly after printing it has a rather spongy feel and after a while it hardens somewhat, but it is generally a bit more rubbery and compressible than PLA.  Sanding, drilling and cutting is more similar to working with PLA than with wood, unsurprisingly. Sanding makes the surface much lighter and detracts from the overall appearance. I used various grades of paper, including wet&dry, to some success, but bringing out the Dremel makes it much lighter work, remembering to keep the revs nice and low.

I also drilled and tapped a small test piece for a 3mm bolt. It holds well though I would be wary of putting it under any serious load – as with PLA.

I also applied some water-based acrylic paint to a piece (not shown) and it appears to go one well. Once it’s dry I will report how it looks and holds.


So far it’s a fun material to work with, and the aesthetic quality will definitely add something new to 3D printing. From my very limited testing I would be wary about using it for precise or complicated engineering parts and would probably lean towards structural components. However, my machine doesn’t produce very high quality prints, plus I’ve only just begun playing with it, so there may be much more to this material than I have discovered so far.

I should state, the gears don’t actually turn, but this is due to my being unable to print out the pins to a sufficient quality. A tighter calibrated machine could well produce a working copy with this material.



Printing with Wood Composite

The recent articles (3ders, Thingiverse) about printing with “wood” piqued my interest, and I was excited to see the GRRF sells 0.5kg rolls. It seems I submitted my order in time because they are now out of stock – but taking pre-orders. The filament arrived today and I got a chance to make a test print – the trusty, if now unoriginal, minimug.

The GRRF page and the original Thingiverse entry by Kaipa state that it’s warp-free and requires no heated bed, so I gave this a try and true enough it printed out perfectly. The hot-end was set to 190°C at the start, and I manually increased the temperature in 10° increments to 220°C back and forth to produce the colour gradient.

The bottom of the print is smooth, similar to the finish from PLA, whereas the sides and top are rougher. So far I haven’t attempted working with it (drilling, cutting, etc), which I will try tomorrow. I did try a little sanding which required a bit more effort than real wood and again was similar to working with PLA. I’ll be interested to see how well it takes paints and lacquers.

I find this development pretty exciting as it opens up another material that works immediately with a reprap FDM printer. Kaipa isn’t revealing what is in the composite, nor his process, but Viktor from the forums pointed out  a material from Tecnaro called Arboform. This thermoplastic composite is based on Lignin, a natural polymer, which is a by-product of the pulp industry.

“Mixing lignin with natural fibres (flax, hemp or other fibre plants) and some natural additive produces a fibre composite that can be processed at raised temperatures and, just like a synthetic thermoplastic material, can be made into mouldings, plates or slabs on conventional plastics processing machines.”

What’s also really interesting is seeing the other products from Tecnaro: Arbofill and Arboblend. The latter having comparable properties to ABS, apparently.

I believe Tecnaro only sells granules, and cater for manufacturers, as their minimum order quantity is 25kg (1 bag) but considering the recent arrival of filament extruders (Lyman, Filabot) it seems it would be a perfect match for the 3D printing community. Anyone in Germany (Baden-Württemberg) want to split a 25kg bag with me?


… and of course the minimug was watertight!

Wood Minimug - watertight



Githubiverse – A Github Pages Template for 3D Printing Projects

I’m a big fan of github, and I think it provides an excellent set of resources for hosting 3D printing projects. Recently I had the idea that it would be useful if these projects were able to utilise Github Pages to provide a project landing page, showing similar information to that found on Thingiverse.

It sounded like a fun little diversion so I threw together something called githubiverse. It currently consists of a Github Pages template: drop this into the gh-pages branch of any github project, add a little configuration, and your github pages will display the source files, STLs and any images, along with some other information. The beauty here is that the content is dynamically pulled from the github repository so it is always up to date.


The screenshot doesn’t do it justice so here is an example site:  The project has a master branch which contains folders for source files, STLs and images. The project also has a gh-pages branch which contains the template. Within this, _config.yml contains the configuration parameters that allows the gh3 github api client to connect to github and pull the information. Because it’s dynamically generated it’s a little slower than a standard website, but I think it’s an acceptable compromise for always having the latest information.

[Update: The way I have used Thingiview means that only ascii STL files are correctly displayed. I’ll see if I an find a way to also load binary STLs.]

To get an idea of how other projects might look I took a few screenshots (via locally running instances) for Nophead’s Mendel90 and Josef Prusa’s PrusaMendel:

There’s a few pros and cons to consider.

  • + Free hosting of project site by github.
  • + Easy to set up.
  • + Always up-to-date.
  • + Easy to change the look and feel to suit your needs.
  • – Depends on Github, Github Pages and the API – any changes to the terms and conditions, or future availability, of these services could impact the site.
  • – No search function, tags or commenting system (although this could be remedied).

Further Ideas


An interesting advanced use case is the ability to use the same core template across many projects.  You could fork the githubiverse-template project and edit the html/css as you wish. Then, in each project’s gh-page branch create a submodule referring to this fork.  All that’s left would be to create a _config.yml file with the details in the root project gh-pages branch and an additional entry defining the source of the jekyll site as being the submodule folder.  I’ve added details on how to do that in the project’s readme.  The benefit of doing this is that each project can be updated solely through updating the template submodule. [Update: it seems I had forgotten to actually test this method when deployed to github, whilst it works locally via Jekyll it seems that github modifies the source folder settings during the build.  Thanks to dzach for finding this out the hard way.  I’ll see if there is a way around this as I feel having a shared template system would be quite useful.]

Another idea is to edit the template to utilise the blog aspect of jekyll. The site runs on Github Pages and already does this to announce releases.  The blog could be a development log, release history, or news section for example.

To address the search and discovery aspect I considered trying to implement some form of tracker service, whereby projects could register themselves and use the service for searching, browsing and tagging etc, also as a Github Pages site.  However I realised that something like the RepRap Development Tracker would do the job perfectly well, as this is agnostic to where a project is hosted – it only categorises each entry and refers to the originating pages.

Development Tracker is currently tailored specifically for tracking reprap and 3D printing parts and projects, but it wouldn’t take much to make it more generic and suitable for tracking all sorts of projects.  And of course the underlying software is open source, so anyone can fork and go!

DLP Resin Printer

Printrun Projectlayer Update

I recently updated my mod of Printrun’s projectlayer with a couple of important improvements which are worth sharing.

  • Replaced wxpsvg with cairosvg.
    Wxpsvg didn’t handle scaling correctly and so I decided to replace it with the better cairosvg module. This means there is a new dependency on pycairo (I installed via: pip install pycairo).  Now each model should project to the correct size when the X and Y resolution, and the ProjectedX, values are set correctly, and the scale is set to 1.  See below for a brief outline of my XY calibration technique.
  • Slow SVG reading caused timing issues.
    When the SVG file is large (e.g. > ~5MB) the time it took to convert to bitmap caused the image to not be displayed in time, as the original code worked on a fixed time schedule. I changed it slightly so that the displaying of the image waits for the bitmap to be ready before continuing. This means that the “Blank” time is now really the minimum blank time – it could blank longer if the SVG takes a while to convert, but at least the amount of time exposed should be always correct.
  • Projectlayer settings are now saved between sessions.
  • Show filename, layer count and estimated time for print.
  • First layer can be displayed for a set number of seconds.
    Setting a positive value in the number box next to the “1st Layer” checkbox will immediately display the first layer for that number of seconds. Useful for testing or for exposing the first layer for longer before starting the print.  A value of -1 sets it to infinity.

XY Calibration

It may also be worth mentioning how I calibrate the XY dimension of the printer.  There may be better ways, but the following works for me.

Projectlayer - Calibration

Projectlayer – Calibration

The key settings are the X and resolution (in pixels), plus the ProjectedX value (in mm).  The former should be set to the resolution of the projector (in my case 1024×768), and the latter to the full width of the image that is projected onto the bottom of the vat – not just what is visible in the vat of course, but the entire width of the projection.  (I should also note that the display should of course be set to “fullscreen”).  With these figures dialled in the calibrate checkbox should display a grid of 10mm² squares.  The ProjectedX parameter can be modified to fine tune.


It’s also worth testing with a few real models to make sure – the “1st layer” option is useful here.


If anyone uses this and comes across problems then please let me know.