January 26, 2015 at 6:04 am #2120ezrecParticipant
I’ve started work on my printhead controller stack, starting with my InkShield and C6602A as a basis for experimentation.
The stack consists of an ATmega328 (Arduino Uno, or Trinket Pro, or whatever is in your parts bin), an InkShield, and a motor controller (I’m using a Adafruit v1, but whatever H-Bridge device you have can be made to work).
The theory of operation is that the printhead controller has complete control over the ink head – both its positioning and the ink ejections.
This allows the ‘feed rate’ to be automatically determined by the ink spray rate (N sprays at 805us/spray per dotline ) allowing precise overspray control when using a DC motor + encoder.
I went with the DC + encoder route to eventually allow the software stack to control HP/Epson/Canon printheads in their native mechanicals, to hopefully allow easier ah-hoc powderbed fabrication.
(I really should take some pictures of this stuff one day).August 4, 2015 at 4:11 am #2795ezrecParticipant
After 6 months of basically living in fear (flaming motor controller episode), I have finished the DC + Encoder printhead controller.
The theory of operation is that the dotline (~800 12-bit dots) is stored in the ATmega328’s RAM, and the printhead is starts a velocity controlled (not position controlled) movement across the plate.
Every 1ms, the controller queries the position, looks up the ink pattern in the table, and fires an ink dotline (12 dots). Velocity control mostly eliminates the jerkyness of position control, and is easier to program. It’s pretty fast (for an ATmega325) right now, and there’s much room for improvement. (Ie using integer math instead of multiple mm to DPI conversions).
The controller allows both single-pass bi-directional and double-pass bi-directional support.
This technique (velocity control instead of position control for DC + Encoder) should allow for much faster printing with a faster head. The HP C6602 is very slow (1ms per dot) when driven according to spec, and the ATmega328 can’t go much faster than that without losing encoder ticks.
A Arduino UNO and a faster head should allow for much faster printing, but that will have to wait for the someone else – I am planning on using a ‘stock’ Canon PIXMA i9900 for the next iteration, using standard printer drivers to render each ‘page’, with a ATmega328 faking the page-present/page-out/encoder-tick signals – more to come on that project later.
- You must be logged in to reply to this topic.