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 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)

 

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.

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.

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.

 

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!

Comparing the printed parts between Prusa Mendel V1 and V2

With the recent announcement from Prusa about the new version of his Mendel design I thought it would be worthwhile to share a webpage I created that compares the stl files from the two versions: http://garyhodgson.com/prusadiff

It makes use Thingidiff, nrpatel’s version of tbuser’s Thingiview.

Just Another Heated Bed

Maybe I am remembering it incorrectly, but before I recently replaced the MDF bed of my Prusa, I used to be able to print without heating the bed surface before the print started.  Perhaps it’s because the wood is different, or some other change to my setup, but recently I have been having trouble getting that important first layer to go down right.  A temporary solution was to use a hairdryer to blast the bed just as the first layer was going down – but this is loud and gets in the way of making sure the print starts out ok.

A recent forum post about using wall tiles as a base for a heated bed made me think about building one, but the power resistors I had were a bit too high (150Ω vs. 6.8Ω),  Then I remembered I had a few lengths of NiChrome wire and some Aluminium sheet so I decided to embark on a weekend project to build a copy of the Mendel Bed described by Adrian Bowyer.  What follows adds nothing to the original, detailed instructions, but another take on it won’t hurt I guess.

The trickiest part for me was working out what the lengths of NiChrome should be, and how best to lay them out.  For a bed temperature of 55°C Adrian’s suggestion of 1.5Ω at 12v to produce ~100W sounded like the number to aim for.  My multimeter told me that my 115cm length of NiChrome was 31Ω.  So 1.5Ω would be 5.5cm – not much to cover a 25cm² bed, so of course we put a few in parallel.  At this point I wasn’t feeling too confident in my calculations and i’ll admit to using this online calculator for checking the power and amperage given 12v and a given resistance.  I decided that three wires should sufficiently cover the board, and so each wire should be 1.5Ω * 3 = 4.5Ω, resulting in each being ~17cm long.

(As it happened I got the calculations a little off on the day and ended up with a total resistance of 1.9Ω. This yields only 75W (6A) but in subsequent tests this seemed to warm the bed to 55°C adequately.)

Cutting the aluminium to size using a Dremel was interesting – holding it steady was a challenge, and it ate through a cut-off attachment pretty quickly. Still, a little work with a file and it was good enough. I used left over wire from an ATX PSU for connecting the NiChrome together and to the power socket, to be sure to handle the current. A spare thermistor was secured to the middle of the bed with Kapton tape.

The indicator LED was hooked up to a 1k resistor and soldered to a socket salvaged from an old Xerox printer. I had wired up the LED without thinking in series, and was later wondering during testing why the LED came on but the NiChrome wires were not getting even warm. Only after reviewing the circuit diagram Adrian had included in the original instructions did I realise it should (of course) be in parallel across the +12v and common wires of the socket.

The ATX PSU I am using can provide 17A over the 12v wires, so, as I have a Ramps 1.3 board, I decided to wire up both the 5A and the 11A power connectors. I then went ahead and gave it a test run.

To attach the power connector to the aluminium I tried using oven sealant, which was the only heat resistant “glue” they had at my local DIY store. This worked initially, but quickly broke off during handling. I suspect the instructions to “fire the oven or chimney to full temperature to harden the sealant” really is necessary, or it didn’t like the plastic of the connector (it stuck to the aluminium quite well). Regardless I fell back to trusty old Kapton tape.

To stop the wires dropping down, and to reflect some heat upwards I decided to cover the underside with baking foil, secured with PET tape.

As I didn’t have any glass around to use on top of the bed I decided to print directly on the aluminium, but was a little surprised to find the PLA not adhering whatsoever. The extruder was at 185°C and the bed at a little under 50°C (according to my multimeter’s temperature attachment). So I decided to lay some PET tape onto the bed (whilst it was still slightly warm) and subsequent prints came out very nice. No more annoying the wife blasting away with the hairdryer!

Experimental Z Axis Gear Train

I was thinking about alternative ways of driving the second Z axis rod. Using two motors seems a bit redundant, and timing belts have to be the right size and can be tricky to source. This isn’t much of a problem for most people wanting a 3D printer – but if you’re experimenting with the technology then having something more ‘reprapable’ has it’s advantages.

One way would be to use a gear train between the rods. This seemed like an interesting line to pursue, as it gave me an excuse to learn how to design gears, and what’s the point of having a printer if you can’t play a little. So, firing up Openscad and the excellent “Parametric Involute Bevel and Spur Gears” script from Greg Frost, I worked out how to build a set of gears to connect the rods on my test rig. I also put together a basic frame to hold them in place using Tinkercad (which coincidentally tested how big a part my Prusa can actually print).

Gear train mounted on top

Having the gears in this curve was not actually planned to be honest (my calculations were a little off), but it did show a way in which access to extruder could be possible if they were mounted on the top of the machine – assuming some sort of guard around the gear mechanism.

Testing showed immediately a clear problem with this approach – backlash. The poor tolerances between the gear teeth accumulates along the train resulting in a noticable delay between the start of the driver gear and the start of the final driven gear when the direction of movement is changed. This is nicely shown in the video.

There’s a few things to note:

  • The problem only occurs when changing direction which, on the Z axis, does not happen for the duration of a print except at the very start after the axis has gone to home.
  • This could potentially be mitigated by going to home and then priming the gears by moving in the opposite direction for a very small distance. I imagine this would be difficult to do with precise.
  • Another idea is to move the driving motor to the middle gear. This would mean that each end would turn at approximately the same time, but there would be still some play between the driving and driven gears.
  • Increasing the tolerances of the gears would also reduce the backlash. However this depends on the quality of prints, and also how high a quality can be hoped for in printed plastic parts.

The backlash problem seems horribly obvious with hindsight. Perhaps I could have worked it out from a bit more thinking, or from a bit of googling or asking on the forums, but by being able to quickly build a prototype I got to learn about making gears and think more about the problem than I would from just reading about it. And maybe posting this will help others in some way. The joys of 3D printing!

Experimental Off-Carriage X-Axis

I recently had an idea about moving the X axis motor off the X carriage. I suspect there is little benefit of doing this, but I felt I had to at least knock out a quick prototype to see it in action.

The video below actually details it all quite well, but i’ll also add a few pictures and a description below.

So, the idea is to move the X motor off the carriage. One immediate benefit is that the size of the entire X axis is no longer constrained by the size of the motor, perhaps leading to more compact designs?  It would be interesting to try out a vertical X axis design with this setup.

Anyway, the X motion is transferred to the belt via a square extrusion rod which drives a cog which sits directly on it.  This rod slides through the mount and cog during Z motion.  The belt in this design is within the two X smooth rods, but other layouts could be adapted to move the belt to the outside (as with  the original Huxley I believe).  In this design the hot-end would either have to fit through the belts, or hang over the edge of the rods.  Again, here the vertical layout would be interesting.