• Prusa Mendel Visual Instructions
  • RepRap Developer Bookshelf
  • Wade’s Geared Extruder Visual Instructions
Uncategorized

Inkshield – Trying to run before I can walk

April 3, 2012 – 10:23 pm

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.

spacer

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:

spacer

  • 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.
    spacer
  • 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.
spacer

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.

Tags Adderfab, Inkshield, RAMPS | Permalink | Comments (3)
Documentation

Another addition to the RepRap Library

February 27, 2012 – 12:40 am

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.

spacer

Diary of a Technocratic Anarchist.pdf (26MB)

Diary of a Technocratic Anarchist.epub  (25MB)

 

Permalink | Comment (0)
Documentation

A History of RepRap Development

February 13, 2012 – 1:07 am

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!

spacer

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.

Permalink | Comments (3)
Documentation

Learning from Hydraraptor

February 5, 2012 – 6:57 pm

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.

spacer

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.
Permalink | Comments (2)
Experiment Extruder Transmission

Experimental Off-Carriage Extruder Motor

January 8, 2012 – 12:48 am

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.

spacer

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.

spacer
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.

 

Permalink | Comments (17)
3D Modelling

Thoughts on Fill Algorithms

January 3, 2012 – 7:45 pm

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.

spacer

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.

spacer

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

spacer

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!

 

spacer

Sphere-Packed Model Example

spacer

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?

spacer

Mockup of slice with example triangulation between nearest vertices

spacer

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.

spacer

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.

spacer

Hyperbolic Planar Tesselations (via 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.

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.