Converting the existing firmware to work for the powder printing process

Hi all,
I am Ajit, and I am new to this RepRap community. I have been closely working on 3D printing for the past one year or so. As a part of my project, I was thinking of converting the existing 3D printing firmware(Repetier) to work for the powder process by adding a few additional motors to to move the powder bed and the wiper blade.

My question is has anybody tried anything similar to this? and if yes can you please provide a link to the source files?

Or if somebody is very good with programming if they could help me understand the modifications I need to make? I am not an expert programmer but i can do a little basic-intermediate programming.

You help is greatly appreciated.

Thanks and regards
Ajit Sajjan Raj

Glad to see I'm not the only one!

I have finished the software (host and printer side) for my powderbed printer: BrundleFab

It uses a (very slightly) modified GCode, and is easily driven by Pronterface or other G-Code senders.

The software is in three parts:

• Software - Host-side software for converting from STL to GCode (with an intermediate SVG slicing step, like UV resin printers)
• Firmware - GCode reader, UI, visualization system, and X, Z, and E axis control (stepper motors)
• Printhead - Inkjet head ('pen') control, and Y axis control (DC motor + encoder, to allow re-purposing of existing 2D printer hardware)

The 'firmware' portion supports either an ATMega2560+RAMPS, or an ATMega2560+AdaFruit MotorShield v2, and 3 NEMA steppers.

For Visualization and UI I used an AdaFruit TFT, but the 'backend' of the UI should be re-implementable on any TFT (and is optional)

The 'printhead' portion uses a ATmega328+AdaFruit MotorShield v1+InkShield with a HP C6602 printhead and a DC Motor + Encoder scavenged from a cheap inkjet printer.

The Axes are: E - powder feed, Z - build bin, X - printhead bar control, Y - inkjet head (pen) control.

The GCode modification is simple - Tool 1 ('T1') has a parameter 'P' that is the pattern to draw - a number 0..4095, corresponding to the bit patterns 0x000 - 0x3ff (12 bit, single color). When the virtual Y axis is incremented, the pattern is sent to the printhead. but no printhead movement occurs. When the Y axis is reset to 0.0mm, the printhead renders the patterns stored on it all by moving the actual Y axis and ejecting ink.

The theory of operation for the printhead is that each dotline (approx 800 12-bit dots) is stored in the ATmega328’s RAM, and when the printhead is instructed to render, it begins a velocity controlled (not position controlled) movement across the plate.

Every 1ms, the controller queries the position, looks up the ink pattern in the dotline table, and fires an ink dotline (12 dots). Velocity control mostly eliminates the jerkyness of position control, and is easier to program than position based control.

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 printhead controller allows both single-pass bi-directional and double-pass bi-directional support.

Video of first print with the BrundleInk printhead controller: https://www.youtube.com/watch?v=AXfwg9JT8Bg]BrundleFab - first ink test[/url]

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.

An Arduino UNO and a faster head should allow for much faster printing, but that will have to wait for the someone else – I have material testing to work on, and a heated post-layer step for improved binding.