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.
DLP Resin Printer

DLP Progress Report

Failed attempt at Tiny Planetary Gears at 80% scale

I had hoped to have some nice successful prints to show off but progress has been rather slow. Vat #2 also developed cracks shortly after the initial test runs. Whilst assessing the situation I made the uncomfortable realisation that the “perspex” I had bought was not actual perspex but rather polystyrene! A project manager from a previous job once dealt me some sage advice: “Assumptions are the mother of all fuck-ups”. Here I had assumed that the transparent sheets of plastic at the local hardware store were perspex, because that’s what I was looking for and that’s all they had, and it certainly looked and responded like perspex. On making this realisation I fell immediately into a second trap – that the cause of the vat failure was due to the material. So I merrily went off and found some real perspex and rebuilt the vat, which promptly failed in exactly the same way!

I recount all of this because I find it interesting how we have to deal with such traps and set-backs as part of the development process. We constantly have to fight against our own hubris, ego, and our willingness to mislead ourselves as we try and maintain focus on solving the current problem, whatever it may be. Robert Pirsig wrote about set-backs and hang-ups, as “Gumption Traps” in Zen and the Art of Motorcycle Maintenance (PDF, p.139 onwards) and I am reminded of them often as I tinker.

So, after 3 failed vats, I actually started to consider that the design might be the problem. Some rudimentary research on working with acrylic showed quite clearly that it “has a high thermal expansion coefficient compared to traditional glazing materials and allowance within the frames must be made in both directions for thermal expansion and contraction”. So the rapid heating of the center from the reaction in the resin, together with the use of bolts through the material, was a recipe for disaster. I had, once again, assumed that my memory of working with perspex (at school, so now a few years ago) was accurate and that it would tolerate such temperature changes and design. It was only after these failed attempts that my hubris was sufficiently dented that I was forced to question my assumptions and check, and double check, my work.

Vat #4

Build #4 removes the bolts and leaves some allowances around the edges for the thermal expansion. It uses aluminium U-bar to “clamp” the PTFE foil between the L-shaped walls and the perspex floor. All held together with a generous amount of silicone. It’s still far from perfect, but at least so far it hasn’t developed cracks! The main problem I foresee is that any damage to the foil will mean having to destroy and rebuild the whole thing.

I also built a second base from copper pcb board. So far it seems to hold the parts enough for the duration of the print and they can be easily scraped off afterwards.

New vat and base

During the times that I did have a vat, I attempted the Tiny Planetary Gears by Auebenc. I’m still waiting for my pigment to arrive and so am still trying to judge the cure depth of pure resin by timing alone. Because of this I wasn’t expecting a working print (which I indeed didn’t achieve) but I think the model shows the potential of what the printer will eventually be able to do.

Failed attempt at Tiny Planetary Gears at 50% scale, note the M3 nut for scale.

The above print would have been great however I had reduced the X/Y scale to 50% but failed to reduce the Z layer height, and so it is elongated x2 in the Z direction. I think I will have to put a reminder message in the host, or do something automatically, as it is all too easy to forget a variable whilst making adjustments such as this.

Tony Buser asked what the durability of printed parts is like and I replied that the belt pulley from the first test run certainly appear to be strong enough to use in that capacity, and these prints remain as strong now. One thing I did discover whilst attempting to clean up some of the planetary gear parts is that the material is very brittle directly after printing, and even after a couple of minutes under a UV lamp. When I tried to enlarge screw holes the resin cracked or crumbled quite easily. However it has to be noted that the models were ridiculously small (I printed at 50% and 80% of the already tiny size), plus I think that allowing the models to cure over time makes them stronger.

Brittleness directly after printing

Another thing worth remembering is that spotamaterials also offers harder, more robust resins – Spot-HH and Spot-HT. I will no doubt be trying this sometime soon.

DLP Resin Printer

Prints from Vat #2

After waiting a couple of days for the silicone on vat #2 to dry I got around to testing it out.  This version is identical to the first, but with a 4mm perspex bottom, and better care taken drilling the bolt holes. Initial tests seem successful, but it will take a few days/test cycles to see if the cracking problem occurs again.

Another change I introduced to the exposure cycle was to move the Z axis up 3mm after each exposure, then moving it back 3mm minus the slice height. This was to ensure the last exposed layer was not sticking to the vat floor and causing deformation of the print, as I had hypothesised in the previous post. Looking at the cube-sphere test model here though the same problem occurs, therefore this hypothesis fails. The extra Z movement in the cycle is probably a good thing to have in any case, even though it adds a few seconds to each slice time.

Cube-Sphere Model

The Cube-Sphere is a simple model created from a Functional Representation CSG program I am working on (which needs its own post sometime). The same deformation  occurred again as it did in round 1, and I now suspect it has more to do with newer layers bleeding into the older layers, and lack of support. It will prove to be a good test piece as I dial in the layer height vs. exposure time. I also plan on buying some pigment to help assert control, and look into creating support structures.  It’s worth mentioning that version 0.8.3 of Slic3r introduced experimental support material for SVG, but I have not yet had time to test it.

The image below highlights an interesting problem. I created the model so each part is hollow, but the way the print is pulled out of the resin – together with the amount of resin – caused some to be trapped. This is nicely shown below by the bubble, which would move around when the part was rotated showing that the contents were still fluid.  It became solid after a few minutes under the post-cure lamps.

Cube-Sphere - Bubble

Assuming we desire the part to be completely hollow we now have an interesting challenge – how to “drain” the part before it is enclosed? As it happens, this was another reason I decided to abandon the powder printer. One of my long-term goals is to develop efficient fill algorithms, as I outlined in a previous post. If a part is to be printed in a powder bed, and the part is enclosed, then it follows that, unless some form of drainage is designed in the part, the loose powder will be encased.

There are a couple of solutions for the DLP printer that immediately come to mind. One could raise the part above the resin level completely, and when re-lowered the air trapped in the gap would push the resin aside, leaving the empty space. This assumes of course that the enclosed gap is complete, and air-tight. Another approach could be to reduce the resin level to be as low as possible. Ideally this would be exactly the slice height, but with such small tolerances I can imagine problems being introduced: surface tension; accumulated errors in the z axis; plus simply being able to position the feed mechanism so accurately would all cause headaches.  So a minium acceptable tolerance would have to be accommodated. Still, that’s a problem for sometime in the future.

Goldberg Polyhedron

George Hart’s model of Michael Goldberg’s polyhedron has quickly become the “Hello World” of resin printers. I tried to print a half of the model simply because it was in my test folder, not expecting it to print at all.  Surprisingly it came out reasonably well, except that the sides suffer from z-layer bleeding. Several of the holes remained filled with resin – some isopropyl alcohol and some diligent cleaning would sort that out I think. I should note that each square on the mat in the photos is 10mm across.

Failed Goldberg Polyhedron

Even the failed prints look good! Here the print failed to attach to the base and remained on the vat floor for the duration, leaving a 2D projection of the half-sphere.

Microstructure Model

This model is again from the Functional Representation program. In my search for efficient fill algorithms I came across the work of Alexander Pasko and various colleagues, particularly a paper entitled “Procedural Function-based Spatial Microstructures” (PDF) which details exactly what I was looking for. Since then I have been attempting to recreate their findings, particularly the models with parametrised internal structure. Last week I finally was able to create the model and so of course it was one of the first things I wanted to print. The photo’s do not really do it justice – and there is still a lot of improvements to make – but I was pretty excited to print some resemblence to the model. Below is an image from a later paper, “Procedural Function-based Modelling of Volumetric Microstructures” (PDF) which shows how the model should look. The first image in the gallery above is the model I created, and the photos are of a print of the middle quarter of the sphere, and some of the structure is clearly visible. I plan to write an entire post on this subject as I think there is a lot of potential in relation to 3D printing.

Volumetric Microstructure taken from "Procedural function-based modelling of volumetric microstructures", Alexander Pasko et al.


Something that may prove useful for people generating SVG files from Slic3r: I created a small html file that renders the file and allows one to slide through the slices. Similar to the Layer View from Skeinforge’s SVG output.  A demo is available here:


The project is on github.  Either clone, or unzip, the project into a folder under a web server, and copy the svg into the root or examples folder. Then in the url access the file like so: “http://localhost/slic3rsvgviewer/?file=examples/my_model.svg”.

To run the html directly from the file (e.g. from “file:///T:/www/slic3rsvgviewer/index.html“) then the browser must allow Cross Origin File access. For Chrome simply put the following parameter in the startup command:  “–allow-file-access-from-files”

UPDATE: Now with added goodness!  Drag an SVG file from your desktop onto the browser window to load and display the file!

DLP Resin Printer

DLP Resin Printer

I recently changed tack.  Instead of pursuing a powder printer design I decided to focus my energy on building a DLP resin printer. Once I had considered what my end goals really were I came to the conclusion that the powder approach would not yield the resolution and quality I would want.  Looking over the blogs and forum posts in the 3D printing community I suspect several people have followed a similar line of reasoning.  There is also a growing interest in this type of printer amongst the 3D printer community and so I imagine a better chance for  support.

This post, and presumably subsequent ones, will attempt to document what I have achieved so far, outline the issues such a printer has, and how I intend to tackle them. As is often the case, everything I write about has already been done before in some way or another, but hopefully this account will add to the shared experience.  I have to caveat that my goal here is purely fun and education, I’m not trying to develop a product, or even a guide on how to build your own version of this. It’s all quite hacked together, as will become apparent! Still, I will still make all files and designs available in case they prove to be useful.

I should also say that it’s very early days and whilst I have had a couple of “successful” prints, my definition of success here is purposely quite flexible!  There’s a lot to do, not least calibrating for dimensional accuracy, repeatability and robustness.

First Successful Print - Belt Pulley


Here I run through the various parts that make up the printer. Future posts will no doubt go into more detail for each one, but this should give a good idea of what I have done so far.


My initial idea was to build the frame with wood but I soon changed my mind for 20mm aluminium profile for the flexibility it would give. Additionally, I picked up various brackets and small steel sheet parts from the local hardware store and my scrap pile to hold things in place. The remaining parts were printed on the Mendel, with the majority of the design coming ScribbleJ’s Thingiverse entry, but with a few parts modified to fit the aluminium profiles.


Initial designs in Sketchup

The Frame

I swapped the motor coupling for a thrust bearing design, in order to reduce wobble, and changed the arm that drops into the vat to a modular design using threaded rods and a custom base.  The Z axis is so high simply due to the rods I had lying around being that length.  The middle sketchup design shows an alternative where the bulk of the Z-axis goes below the vat table, but this introduces more parts and a potential source for more wobble.


I can already foresee that this component will undergo many revisions. The interaction between the vat floor and the layer of resin being activated by the UV light is critical, and subject to much discussion on the yahoo forum. As I will detail below, already my initial version quickly developed problems and has had to be rebuilt. But for reference, in version 1 I used off cut aluminium extrusions for the walls and 2mm thick perspex (acrylic) for the base. On top of the base, secured between it and the walls, is a PTFE film layer (PDF data sheet). The whole thing was made water-tight with standard transparent silicon caulk.

Vat and Z-axis Lift System


The key component which, to date, has impeded DIY DLP resin printers due to it’s exorbitant cost. However, this is already changing. I bought 1kg of Spot-GP resin from spotamaterials here in Europe for ~€85 (+€35 shipping to Germany). Still way more expensive than materials for FDM printing, but I imagine prices will drop over time as they did with PLA filament.


This is perhaps a tricky component to acquire as there are so many options open and one wants to be sure of getting the right one. After several days of hunting on Ebay, local classifieds and even Amazon, I lucked-out and found an InFocus IN2104 on Ebay which I picked up for €170.

InFocus IN2104

The most important feature is that the projector has to be one with DLP technology! LCD projectors filter the necessary UV light and appear simply not to work. The next key properties I looked for were the wattage of the bulb and the native resolution. My initial plan was to get one with 800×600 resolution, but I changed my criteria to a higher resolution for the simple fact that I could imagine soon wanting higher definition in my prints (it affects the X/Y resolution of course) and would be kicking myself if I had to buy another projector after 6 months. The IN2104 has a resolution of 1024×768.

I considered bulb wattage a more important factor than the lumen rating as it seems the lumen values given by various manufacturers varies considerably, and I got the feeling, after reading many reviews, that the lumen value is not very dependable. Saying that, higher lumen is generally better, but also look at the bulb wattage. The InFocus has a 200W bulb. Most projectors I looked up had values around 180W, particularly Acer, and so the exact value will depend on the brand and model. I set myself the hard criteria of type and resolution, and then was a bit more flexible on bulb wattage, price and availability.


The part which the first layer attaches to and, in my case, rises up from the resin. My initial tests were with wood and then perspex because I had no local source of glass pieces, which seems to be the preferred material. These proved unsuccessful and so I tried a couple of other materials I had lying around. It seems that copper PCB board and stripboard work quite well. With the latter allowing the resin to harden within the holes and potentially provide a better grip – but this is only a hypothesis. I shall no doubt replace this in the future revisions, but it provides a cheap starting point.

The board is simply glued to a small 3D printed piece which allows four PCB stand-offs to be attached. These provide the lift over the rim of the vat. The stand-offs are then screwed to another 3D printed part which in turn goes on the vertical Z-axis rods. Over the stand-offs are stiff springs – these allow each corner to be individually adjusted so that the base is parallel with the vat floor.

Base pulling out 1st almost successful print

Whilst using threaded rods for the vertical Z-axis was handy because I had some around, I think these will soon be replaced with an L-bracket design as there is some flex in the rods. The weight of the model is negligible, but the suction force of the part and the vat floor can be considerable and it is therefore a design goal to reduce flex where it is not wanted.

Lens Throw Reducer

The shortest distance the projector can throw, and be in focus, is approximately 35cm (if I remember correctly). One could possibly open the projector and physically modify the focus mechanism, or lens, in order to reduce the throw (as Mike has done with his B9Creator), but I’m wary of making modifications to the projector itself and so opted to use a cheap magnifying glass to do the job. This choice has obvious disadvantages – optical distortion, inconsistent image placement, etc – but it’s cheap and it works fine during the initial phase.

Hi-Tech Lens Throw Reduction System

Resin Delivery

I expected to have to design a resin delivery system – perhaps something as simple as an upside-down bottle with a tube to the vat floor, with the liquid pressure regulating the delivery – and I may still do this. In the meantime the vat holds enough resin to complete my small test prints, and I load the resin via a large syringe.


I am using a modified version of Printrun, adding the following features:

  • Open the presentation window fullscreen in a second monitor.
  • Project a calibration grid
  • Display the first layer of the model – useful for displaying the first layer longer than the subsequent layers.
  • Accept SVG from Slic3r. (Update: To do this I replaced the SVG module with wxpsvg which has a dependency on pyparsing.  Install instructions are on the pyparsing site.)
  • Accept a set images (bmp, png, jpg) in a zip file (with suffix so it’s recognisable but can also be opened in a regular archive program).

Printrun - Projectlayer


Sprinter for it’s ease of hacking.

Post Cure

I’m not 100% sure how necessary post-curing is. The parts appear quite stable directly after coming off the base. A bath in isopropyl alcohol may suffice for post-processing, to remove non-cured resin. However, as I had a UV lamp handy I threw the parts under that for a few minutes.


The following are a few random notes and findings as I got to print #1.

As the resin photo-initiates the reaction is very exothermic. A very quick test with the thermocouple of my multi-meter and a drop of resin on a thin clear plastic sheet in the bright sun produced a temperature change from 23°C to 74°C. This may have been a contributing factor to the demise of my first vat bottom, which I discuss below. 74°C won’t burn too much, but it’s definitely worth considering – particularly if you get some on your skin and then walk into the sunlight! So be careful! I use latex surgery gloves when testing as the resin tends to get everywhere.

I used a RAMPS board and the related reprap firmware largely because it was lying around. There are a few alternatives as well as the option to roll your own of course. Chris Marion has put together a python based Host which works with the Firmata firmware. It’s currently in beta and windows only, but worth considering.  Chris’s software uses freesteel to produce png slices – this is also worth playing with, although it’s not open-source.


Belt Pulley

The initial successful test pieces came out well partly by luck – the model’s design is such that even though the exposure times per layer were slightly too long this only reinforced previous overlapping layers directly above. I attempted a more complex print soon after and the exposure times resulted in a solid block of resin where it should have been a mesh of struts within. A standard technique to bring more control over the exposure times is to add a coloured pigment to the resin (between 0.2% and 2% by weight according to Fernando at spotamaterials). Currently I am testing the resin without a dye until I order some. My very unscientific initial tests seemed to show an exposure time of 1 second will harden ~0.1mm of resin – but I have to caveat that there are many factors which can play a part, not least of which is my my poor process. I shall endeavour to produce more reliable figures in the near future.

The adhesive properties of the resin are not the only force to contend with. The bottom-up approach has the added problem of a vacuum force – just as with a suction cup. There are several ways to overcome this: brute force (not recommended of course), tilt mechanisms, and slide mechanisms. At the moment the printer simply pulls up, and because the parts are quite small, in comparison with the forces involved, the parts are forcefully pulled vertically off the vat floor. This obviously will have to change, and in fact a subsequent test print nicely highlights this interesting failure:

This should be a cube with a sphere coming out of one edge. The sphere is deformed due to the ‘top’ of the cube sticking to the vat floor, from vacuum force, for several slices. Either the vat floor, the Z-axis rods, or the something else, flexed sufficiently to allow the part to remain attached, until the force was overcome, and could continue. One way of resolving this would be to adjust the print cycle so that the Z-axis rises several millimetres at the end of an exposure, and then lowers to the next slice height. However this would likely only defer the problem until later, larger prints, where the vacuum force would be greater. I think I will introduce a tilt mechanism as part of the next iteration.

Vat Failure

Soon after my initial test prints the perspex vat bottom developed some cracks in the middle, which developed to the point of failure. Prior to this a deformation had appeared at a spot after I had exposed for several seconds (whilst attempting to get the resin to adhere to the base). The autopsy showed that this deformation was mainly in the perspex, and slightly in the PTFE film.

I had done quite a poor job of positioning the bolt holes, and consequently, as I tightened the bolts, slight cracks appears at the holes. Therefore I think it is safe to assume that the entire vat bottom was under some lateral pressure, which may very well have contributed to the overall failure. I also had chosen to use only 2mm thick perspex which could also play a part.

The next iteration has a 4mm thick base and I took much more care to align the bolt holes. I expect a similar failure with this version too, but will hopefully be able to test some more whilst I design iteration 3.

As an aside – as I was writing this post and gathering links and facts I came across an anti-friction dry PTFE lubricant from WD-40 (PDF Data Sheet) which may be worth investigating. It would certainly simplify vat construction! One could simply use a Pyrex dish and spray some PTFE in before each print run. (Of course that’s a bit glib – I suspect oven dishes won’t have the optical clarity required!)


The blogs and forum are certainly worth a read! My thanks to the authors for the information they have shared within.


This post is turning out to be quite long, so I shall end here and put the remaining stuff into smaller posts in the near future.  Hope the information is useful to someone.


Inkshield – Trying to run before I can walk

Recently I found myself with the time to finally build the Inkshield I bought last year. My (rough) goal is to recreate the Adderfab work of the Open3DP team and perhaps put together a powder bed printer. At the very least the Inkshield is a cool little gadget to put together, and Nicholas Lewis has done a good job in creating the kit.

Rather than directly use the Adderfab firmware and code I decided to try and drive the Inkshield from Ramps, with a modified Sprinter firmware and Pronterface. This is perhaps a bit overkill to start with, but this setup has the advantage of being ready to drive all the axis, plus using G and M-codes to control everything.

I got to the point of recreating a dot-matrix printer, and along the way discovered a few things:

  • The Inkjet cartridge is very sensitive, and the thermal heaters can burn out very easily when subjected to too long pulses, which sadly can happen when simply uploading new firmware. Nicholas’ instructions warn to take out the cartridge whilst doing this but I seemed to have forgotten once or twice and now I have a dead printhead… annoying!
  • The Inkshield isn’t terribly suited for stacking with RAMPS as the latter has to go on top due to the stepper drivers, and the former has the ribbon cable leading to the cartridge holder directly over the digital header pins.  The photo below shows the Inkshield next to an Arduino Mega with the Ramps in the background – note the ribbon cable on the right hand side.
  • To get around the stacking problem I plugged the Inkshield in a spare Arduino Duemilanove and linked them over a Soft Serial port (fully accepting any subsequent syncing issues just to get some results). This largely worked, and I was able to get a nice row of dots by having the Ramps tell the Inkshield to print every 80 steps (1 mm). I then pushed my luck by printing after every step, which may have overloaded the Inkshield causing too many pulses and subsequently burning out the nozzles. The Inkshield Arduino Library has a 800us delay built into the command, which I expected to “save” the nozzles, but it may be the case that bombarding the Inkshield with a command to print every step caused the commands to overlap, and hence burnout – I still need to think a bit more about what might have happened.
  • My attempt to buffer the bitmap image data in the Arduino quickly introduced me to world of embedded systems and limited RAM! My naive approach of using hex representation of the data directly in gcode seemed a reasonable starting point, but even the 2k this represented results in headaches. Obviously this could be reduced dramatically, but it made me stop and think about how best to represent the data. The original Adderfab gets around this by using an SD card and reading each set of nozzle data directly.

So, after such fun and games I ordered some replacement C6602A cartridges (not a cheap way to debug!) and will probably go back to basics using the Adderfab code as a baseline and building a simpler setup. Once I have that working I will then revisit integration with Ramps etc.


Another addition to the RepRap Library

Continuing the recent series of RepRap books, Forrest Higgs has kindly agreed to allow his blog posts from and to be collated and made available in eBook format.

Diary of a Technocratic Anarchist.pdf (26MB)

Diary of a Technocratic Anarchist.epub  (25MB)



A History of RepRap Development

Whilst putting together the Hydraraptor eBook I realised that a similar treatment to other RepRap development blogs would be useful, in particular the one from the core developers at  Modifying the scripts and a bit of hacking produced the following 1758 page(!) history of the early days of the project.  Essential reading for any budding RepRap developer!

A History of RepRap Development.pdf  (40MB)

A History of RepRap Development.epub  (37MB)

A couple of interesting side notes:

  • Several image links in the original posts are dead, particularly the early stuff.  However, a little sleuthing on Google  found some of them, and so this version is technically more complete than the original blogs!
  • With agreement from Forrest Higgs I pulled in the content of his contributions (which were links to his own blogs) into the book, which means a more complete, smoother reading experience.
  • A couple of people suggested that offering the book in ePub format would be a good idea and so both this book and the Hydraraptor book are also available in both PDF and ePub versions.  In producing the ePub version I learnt a bit more about the format (a zip file of html and images) and found, unsurprisingly, that the resulting book has fewer formatting issues as the PDF version. To generate the ePub book I simply told the script to output one huge html file and then converted this using the Calibre eBook management tool.

A note about the formatting: because the blog has many collaborators the html of the posts varies greatly, consequently the layout of some entries may be a little off. I have attempted to correct this with various hacks, and I believe the result is acceptable, but the task can be a real time-sink. If any pages are completely unreadable please let me know, however small layout issues will probably not be fixed.

The books have a dedicated page on this blog (RepRap Developer Bookshelf), and will be  are mirrored in the RepRap Wiki.


Learning from Hydraraptor

A common variant of a George Santayana quote is:

Those who do not know history’s mistakes are doomed to repeat them.

Sometimes it is worthwhile repeating mistakes in order to really learn more about the problem, but most of the time we are happy to learn from the work of others, and build onwards with this knowledge in mind.

I mention all this because I recently spent a weekend reading the entirety of Nophead’s Hydraraptor blog. Since starting on the RepRap project I have read many of his posts, but for some reason never actually sat down to consume the whole thing. This was a mistake because reading through the posts in chronological order gives an excellent insight into the thought processes, trials, pitfalls and successes that one comes across whilst developing a 3D printer. One also develops a greater appreciation of how the current state of the project came to be.

While online access is today mostly ubiquitous I found that reading the entire site through a browser was sub-optimal, and so I decided to create an offline version that I could have on my eBook reader or tablet, or read whilst having no internet connection. As I did this I realised that such a document would be useful for others, and so, with Nophead’s permission, I am making the pdf available to all.

HydraRaptor – The story so far.pdf (30MB)

HydraRaptor – The story so far.epub (27MB)

A few notes:

  • The copyright of the posts belongs to Nophead and so any further reuse of the material requires permission from him.
  • Comments are not included. Whilst several did in fact add to the original discussion, the majority did not, and so they can be found online should the reader wish to dig through them.
  • Several images are missing and are highlighted as such. This draws attention to the preservation benefit of the pdf!
  • The document was generated from a script which parsed archive pages of the blog, formatted as necessary, and then generated the pdf. This process may have introduced inconsistencies and errors. Should you find any problems, and wish to report them, please send an email to me here.