Forum Replies Created
-
Posts
-
I think you need to make sure the top-level of this site directs to ytec3d.com/forum, instead of ytec3d.com/forums.
Ha! I will definitely post a video of success – when it occurs.
Still a lot of variables to nail down in the recipe.
Piston problem solved, in the most trivial way – I shaved down the sides of my MDF piston heads by 1mm, then I use a piece of vinyl fabric glued on top as my powder seal.
Currently printing my first calibration object – I still have some sequencing issues, it seems – my fuser pass needs to occur before I lay down the next powder layer!
All in all, a good day!
I’ve moved my project page to http://reprap.org/wiki/BrundleFab on RepRap.org, as my personal site doesn’t have that much image storage space.
The fuser system is working now – and no fires yet! But WOW do halogens get hot!
… but now I have piston troubles.
Varying humidity (humidity really puts the ‘multi-dimension’ in MDF!) and sugar migration into the piston seams has locked up my NEMA 17 based pistons.
I can disconnect the motor and move the pistons by hand, but this will not do for a real build.
I’m considering either going the NEMA 23 route (with bigger motors will also come bigger drivers, and more electronics rework), or trying some loose-fit seal ideas I have.
Any experience here with piston success/failure modes?
The head was still too far from the sugar – got lots of ‘overspray’:
BrundleFab – print head calibration results
Next step is to apply the fuser pass – a halogen lamp assembly from a laser printer, which _should_ heat and fuse the darkened sugar.
HP ink simply colored the granulated sugar, as expected. Many additional material tests are needed to tune the granule size, additional binders needed, and fuser temperature and pass time.
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.
Video of first print with the BrundleInk printhead controller
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.
I have experience with string drive – I’ll see if I can get you a good picture of my ‘grommet drive’ mechanism – it’s a super cheap stepper drive system that gets a good grip on the braided fishing line I use.
Simply put, it’s a large grommet on a brass compression pipe fitting on a stepper shaft.
As for cleanup, I highly suggest a vacuum system – have the bottom section be a MDF sidewalls instead of aluminum rails, with a canvas sheet on the bottom with a port for attaching a shop vacuum hose.
Cleanup is then a matter of turning on the vacuum, and dusting extra powder off the top into the piston chamber, where it falls into the canvas and gets collected by the vacuum.
Or just falls by gravity into a collection bucket.
Instead of conveying powder up (with the associated feed issues to the auger) why not convey the powder down?
If your design requires conveying up, attach a cell phone vibration motor (eccentric weight) to the feed bin to keep the angle of repose of the feed material as low as possible.
I’m getting a 3.3v arduino (Adafruit Triunket pro) to mess with this thing, as it seems that I should be able to write the data to it via the 3.3v SPI interface (with some extra lines for the heater enable):
http://www.google.com/patents/EP1266760A2?cl=en
https://www.google.com/patents/US6742874
The inkshield is.. well.. touchy. I’ve blown out the jets on two HP cartridges so far by (1) having an ISR get stuck during a spray operation and (2) being an idiot and doing a firmware upgrade when the VIN was still enabled on the inkshield.
I’m going to add a 5v Trinket Pro in front of the InkShield to act as a printhead controller – that should allow me to get my ink jetting timings ‘just right’ without having to worry about the rest of the CNC stuff (GCode, stepper control, etc etc).
Know a good place to get HP C6602As in bulk?
Given the commonalities I’m seeing for the various printheads (LVDS, shift registers, etc) maybe it’s time to start thinking about rolling our own pen controller electronics.
I would see the basic idea as a SPI bus to the electronics, along with a ‘dot clock’ line, and a ‘fire’ signal.
The connection from the electronics to printhead would be N bits of LVDS output.The SPI bus would load up a SRAM ring buffer on the electronics with the line to print, N bits wide, by M dots, by F fires.
On every ‘fire’ signal, the next set of M ‘dots’ (N bits per ‘dot’) would be sent to the printhead at the ‘dot clock’ data rate.
The ‘fire’ signal could be directly connected to the microcontroller, or to one of the optical encoder outputs from the printhead carriage if using the DC motor + encoder from an existing carriage.
Yes, that is a time-lapse. Serial communication is the biggest overhead, actually rendering the command takes less time than receiving it over 115200n81.
That said, this was with a ‘null axis’ firmware – all the axes ‘instantly’ go to their target positions.
Yes, Tn is the printhead, Pn..Qn..Rn.. is the nozzle pattern (up to 72 nozzles, given the limits of accuracy with parsing P/Q/R as floats, only about 24 bits are reliable).
And yes, the ; 00000FFFF0000 lines are just debugging comments.
Obligatory github link to my firmware and post-processor for repsnapper’s “Slice to SVG (multiple file)…” output.
Will do, I need to finish my inkshield prototype first (since I already have it all hooked up, just need to put in the hours to finish the Z axes and software).
Probably sometime after the first of the year I’ll get onto the i9900 in earnest. The Linux drivers for it (gutenprint) are crap (sadly), and the “cijfilter” from Canon does not support their 8-color printer families.
Since the printhead is 3.3v logic, I may be able to directly drive it, I hope.
