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.