Yearly Archives: 2012

Documentation

Another addition to the RepRap Library

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

Diary of a Technocratic Anarchist.pdf (26MB)

Diary of a Technocratic Anarchist.epub  (25MB)

 

Documentation

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 blog.reprap.org.  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.

Documentation

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.
Experiment Extruder Transmission

Experimental Off-Carriage Extruder Motor

There was a recent thing on Thingiverse called the Vert-X-Belt-Truder by Johann which describes a way of moving the extruder motor off the carriage. The benefits are a lighter, and potentially faster, carriage. The Bowden cable is another way of achieving this goal. A comment by Martin Price (martinprice2004) caught my eye:

…keep the x axis as current prusa, but turn the extruder 90 degree around the z axis. Drive the extruder using a motor mounted at the end of the axis with a square or hexagon bar mounted horizontally. The extruder drive gear moves along the shaft when the x axis moves, but can still be driven by the motor at any point.

I had already done something similar for moving the X-axis motor off the carriage and so I quickly threw together a proof of concept to thrash out how a design would work.

Sketchup Design

The results are shown in the following video (please excuse the varying focus, the many “er”s, and the fact the audio is muffled between 2:10 and 3:35 – I didn’t realise I had my finger on the microphone – but I don’t say much of value here anyhow, only that it seems to work and the drive gear moves through the drive shaft. Also that the test “print” is running at 200mm/s (travel:250mm/s))

I utilised the Compact Geared Extruder by Matt Roberts (Thingiverse) because it’s small, modular, and as it is designed in OpenScad it’s easy to hack with. I went through a couple of iterations to come up with a bracket that would hold the drive gear in place as the extruder moved along the square drive shaft. As I put the parts together I realised the same effect could be achieved using herringbone gears, so long as the drive gear is held close to the driven. The coupling is a rubber roller from an old Xerox laser printer, as is the square rod. The NEMA 11 motor is simply zip-tied to the X-axis motor end, and the idler is simply a bearing zip-tied to the X-axis Idler end.


A few things I learned as I put it together which might be worth considering if anyone recreates this.

  • Positioning of the motor and idler dictate where the drive gear will be placed, and so I would align these precisely with the X-axis rods and place the drive gear with a bracket. Then I would make position of the extruder flexible (using slots for the bolts for example) so it can be accurately pushed back in line with the drive gear, giving a good fit.
  • The bracket holding the drive gear would be made more robust – reducing lateral movement and possibly adding bearings or bushings either side of the drive gear to support the rod.
  • The bracket should have a way of removing and inserting the square rod, otherwise it’ll be a pain to disassemble the whole thing. Of course if bearing or bushings are used then it might be easier to design it so the rod slides out along the X-axis when disassembling.
  • As mentioned above, using a helical gear such as a herringbone might remove the need for a bracket at all. I guess this would depend on the amount of flex along the driveshaft, and whether the drive gear keeps engaged during the back and forth.

If I get chance to fix the hobbed bolt of the compact extruder then I will try to get this setup printing for real. Here’s a couple more photos and videos just of the running.

[gallery include=”942,946,944,943,941″]

 

3D Modelling

Thoughts on Fill Algorithms

Whenever I’m watching a print (because it can be hypnotising after all) I usually become acutely aware of any superfluous aspects of the design and how inefficient the fill patterns can sometimes be.  The fact that the model is sliced into layers leads quite naturally to filling each of these layers with a 2D pattern. The line and grid patterns from Skeinforge produce stable, solid objects from as little as 30% infill, and for the most part this is sufficient. I wonder though if we can find a better filling strategy? One that utilises the 3D nature of the model.

If the fill is to provide internal strength to an object and support any internal overhangs (ceilings), but also use minimal material, then I guess the ideal algorithm would analyze the model and identify where best to position struts, columns, butresses and such.  Taking into account the printers ability to bridge gaps and so on.

Mockup of model with "ideal" fill of struts, etc.

Even if such an intelligent algorithm is possible it would no doubt be so computationally intensive as to break another constraint we should define: that the fill pattern should be determined in a reasonable amount of time.

This is why the line algorithm works very well – it fits almost any organic or non-organic form, and can be computed relatively quickly. This is also demonstrated by the alternative fill patterns that Alessandro Ranellucci has implemented in Slic3r: hilbertcurve, archimedeanchords and the octagramspiral patterns are marked as “slow” and indeed can take a long time to generate for non-trivial models.

X-end-motor.gcode, Slic3r, Line Algorithm, @32s

X-end-motor.gcode, Slic3r, Hilbertcurve Algorithm, @7m 20s

As a sidenote, this highlights another observation I have made: that the current delineation between 3D model (usually STL format) and Gcode seems skewed, and some information that should belong in the model (e.g. fill structure) is delegated to the runtime process. I’ll hopefully expand on this in another post, but it’s worth mentioning here because perhaps our view of what a reasonable computation time is, would change if it is moved back along the workflow to model generation.

So the question: Is there a fill pattern, that provides the same strength and can be computed in the same order of magnitude as the line approach, but which uses less material?

Some Ideas

Some initial thoughts involve ways of packing other, simpler, 3D forms within the model, which leads to such things as the sphere packing problem.  In this case we would ideally find a solution that has a dense, irregular packing of unequal spheres, where each sphere is the largest possible size for the containing form. Here is where my woeful lack of mathematics causes a real problem. I suspect, but can’t be sure, that there is no way of determining such an ideal packing arrangement within the timescale constraints we have set (i.e. minutes, if not quicker).

This also highlights another aspect of the problem: the 3D model we are attempting to fill can be any arbitrary form. If the target model was always a cube, or even always a regular solid, we could potentially pull some tricks (lookup precalculated values perhaps?) in order to use a sphere packing approach. With the prospect of packing non-regular, and potentially very organic, models the problem becomes ever more difficult!

 

Sphere-Packed Model Example

Sphere-Packed Model, Slice Through

 

Another avenue of investigation is whether an arbitrary model can be divided into simpler shapes?  The assumption being that working on several simple solids would be easier and quicker than working on a simple complex shape.

Another idea involves using the vertices of the target model as a basis for generating internal edges, perhaps utilising Delaunay triangulation or something similar, but in three dimensions. This would have the benefit of being tailored for each model, but would it guarantee structural strength? How would such an algorithm work in three dimensions?

Mockup of slice with example triangulation between nearest vertices

Mockup of slice with example Delaunay triangulation (but not actually correct, only to give an indication)

Then something dawned on me: do we have to constrain the fill pattern to the boundaries of the target model? What if we had a pre-defined 3D fill pattern, say a honeycomb, which we intersect with the model to produce the fill pattern?

The pattern could potentially derive from a 3D Tessellation.

3D tessellation with truncated octahedron (via Wikipedia)

Further browsing online leads to Hyperbolic Planar Tesselations. I have no idea whether something like this could be utilised, but the fractal nature of how the pattern interacts with the boundary could yield ideas for resolving how to give strength to irregular, organic shapes.

Hyperbolic Planar Tesselations (via http://www.plunk.org/~hatch/HyperbolicTesselations)

 

Mock Print

In order to get a feel for the problem I decided to mock up such a pattern to print. This led to an interesting realisation, that the various tools available will each work with this solution to varying extents. I played with OpenSCAD, Google Sketchup, Skeinforge and Slic3r whilst trying to manually generate an example structure. I found that concept of internal structure in these tools is rather foreign, and I had to hack a bit to get some results. Most 3D modelling tools I have tried concern themselves with solids, the skin of the model, and not the skeleton. Perhaps there exist CAD programs geared towards engineering which use a skeleton + skin paradigm? Perhaps this is also worth investigating further?

In the end I used OpenSCAD to generate a cube filled with a set of sphere-spaces, and used Skeinforge to slice two models, one with zero infill and one with 30% infill.

It is worth mentioning that I attempted creating a similar structure in Sketchup, but using a real model (Mendel X Motor Mount) and a lattice of spheres (as shown a few paragraphs earlier).  Attempting to intersect the spheres with the model caused Sketchup to hang (or rather take an unacceptable amount of time to respond). This perhaps hints at the potential performance problems such a solution may have?

The printed model shows that, for a very basic target shape, the packed sphere approach yields a reasonably rigid object. It is certainly not comparable to a cube filled with 30% line pattern infill, but printing the mock gave me confidence that it is at least worth continuing to research such techniques.

Where Next?

The goal of writing this post was to collect some thoughts on the subject which I could refer people to for discussion.  It would be cool if someone more mathematically-minded could comment on the feasibility of such 3D space filling algorithms. Or if others have had similar ideas on the subject at all!

To summarise:

  1.  I think it is worthwhile looking for more efficient fill patterns that take advantage of the 3D nature of the model it is filling.
  2. The main obstacles are computational intensity and ensuring the resulting model has sufficient strength, regardless of its form.
  3. It is worth reviewing whether current 3D modelling tools are suitable for defining such things as internal structure.  There is potentially an opportunity to develop something interesting here.

I’m going to try and find time to play further and try and throw together perhaps a script to preprocess a model, or perhaps implement a fill algorithm directly.  I will also look a bit more at existing tools to see if there is already something out there which allows the definition of internal support structures.

Any feedback would be very welcome!