Sunday, January 31, 2010
Many useful little things...
In which your narrator continues his relentless campaign to get the steel out of Reprap machines and improve the percentage printed.
Do you want to read more?
Saturday, January 30, 2010
Mendelssohn & LCA2010
Finally got over the flu that I brought back from LinuxConf 2010. Mendelssohn is now printing properly with a stepper-driven extruder and a new heating element/barrel design. This is essentially the old hack using a radio aerial and a heatsink. The M4 nozzle (not shown) fits inside the feed tube, so increased pressure forces the nozzle into a shoulder at the end of the tube. So the more pressure, the better the nozzle seal. The shoulder is created by slowly cutting the tube with a pipe cutter.
I'm dip-coating the 3/16" brass tube in fire cement slurry, drying this, and then wrapping the dry ceramic in Kapton to protect it while I wind on about 6 ohms of nichrome. If the Kapton gets vapourised, the heater element will not then short out on the brass tube. The heatsink traps the extruder as well as cooling the end of it, and also acts as an anchor point for connecting the extruder assembly to the X carriage.
Works so far. No lathe needed, no PTFE, no creep, no leaks.
Vik :v)
Labels: aerial, brass tube, extruder, heater, heatsink, nozzle, reprap
Friday, January 29, 2010
Paste Extruder - The first test
Paste extruders seem to be all the rage these days. They would allow RepRap to utilise a load of new materials to increase the replication count, and also enable us to use a soluble support material. Zach came up with the Frostruder MK2 , and it seems to be the best way of tackling the problem. Zach's idea was to use high air pressure directly to force the paste out of a syringe rather than to use a piston driven by a motor. The real beauty of Zach's design is a relief valve that is able to exhaust the high pressure air from the syringe. This prevents any paste oozing from the nozzle when extrusion needs to stop, a difficulty thats plagues a lot of motor driven systems.
The main difference between this design and others is in the valve. Patrick came up with an idea for a pressure valve based around some reprapped springs and a cam, to clamp a piece of silicon tubing and cut the air pressure. We control the position of this cam by using a simple reprapped tacho, an optoswitch, with the entire mechanism connected to a DC motor.
Secondly, the frostruder design has the high pressure acting directly on the paste. I initially replicated this, but found that for relatively "thin" pastes, the high pressure air was able to bury directly through the paste and come directly out of the nozzle. I employed the use of an intermediate bung between the paste and the pressure. However, the ooze from the nozzle is substantial due to the increased friction unless the bung and the syringe were coated in silicone grease. Adding the grease results in virtually zero ooze.
In addition to the valve, we hacked together a compressor based on a 2L drinks bottle, and a car tyre inflator. What is particularly nice about this is that the tyre inflator is 12V DC i.e. we can control it directly from the MOSFETS on the Extruder controller. As yet we haven't hooked a pressure sensor into the system, but its something we intend to work on(or rather its something we want to replicate)
The above was my first test with the extruder on the machine, attempting to find an appropriate axis speed for a given pressure. The extruder started and stopped with pretty much no lag or ooze. I was manually starting and stopping the extruder by hand with a second optoswitch (We haven't got the firmware sorted yet), which is the reason for any large blobs at the start or finish. I was using the soluble support paste I described in a previous post, I guess each line shown in the picture above dried in under a minute.
All in all, the entire setup cost about £20, I'll be posting some more results next week after we get the entire thing to be controlled by the host software, which should also bring better quality results.
Wednesday, January 27, 2010
Build a better RepRap: $80,000 Prize
The Foresight Institute has announced its Kartik M. Gada Humanitarian Innovation Prize to design and build a better RepRap. There is an interim prize of $20,000, and a grand prize of $80,000. They consulted with the core RepRap team before the announcement and we were initially concerned that the prizes might drive developers to secrecy in order to give themselves a competitive edge. As you will see they have addressed those concerns by making it a condition of winning the prize that solutions should be pre-published and made available under a free licence. For ourselves and on your behalf, we would like to thank the Institute for the enthusiasm that these prizes demonstrate for the RepRap project and for their magnificent generosity.
Reprappers: to your designs! To your experiments!
Upcoming server outage
We are pleased to announce that RepRap.org will have a brief server outage at 8:00 PM on Wed, 27 Jan 2010 Pacific Standard Time. This will last no more than an hour, and ideally will only take 15 minutes.
This will be at 04:00 Thu, 28 Jan 2010 UTC.
(We're moving servers.)
Regards,
Sebastien Bailard
RepRap.org
This will be at 04:00 Thu, 28 Jan 2010 UTC.
(We're moving servers.)
Regards,
Sebastien Bailard
RepRap.org
Labels: server
Tuesday, January 26, 2010
Getting there with herringbone rack and pinion
I finally hit a break in my day job and after sleeping the clock around beginning Friday afternoon was able to get back to my Reprap work. I'd been working with herringbone rack and pinion design and had begun writing Art of Illusion scripts to generate this kind of technology. I'd done most of the rack script a few weeks ago, but I needed to be able to design herringbone gears a bit more efficiently.
Finally, on Sunday the scripts for the racks and gears began to come together. After a considerable amount of feeling around I found that I could reliably print an 8 mm radius, 12 toothed gear. Connecting such a pinion directly to a 1.8 degree step NEMA 17 gives me a 0.25 mm/ step on the axis without microstepping. I then designed a 32 toothed gear which let me get that resolution down to 0.094 mm/step. You can see the layout here...
The NEMA 17 turns the 12 toothed pinion at the top of the picture. It turns the 32 toothed gear which shares an axle with a second 12 toothed pinion which engages the rack. It's simple, easy and quick to print and doesn't backlash if you apply just a slight bit of compression to the gear train. My next task is to design a printable axis assembly to seat that assembly. My goal is to get rid of the skateboard bearings, too.
The scripts are in a lot better shape, but they're still not really ready for prime time.
Sunday, January 24, 2010
New Software - May Contain Nuts...
...but fewer.
I've been a bit quiet for a while, owing to the fact that my pathetic brain can either communicate or work, but not both. About six weeks ago, I decided that the Java host software had not been looked at seriously for a long while, what with all the Mendel hardware developments that had been going on. So I decided to take it apart, put it back together again, then throw all the funny-shaped bits that were left over in the bin.
Ages ago Forrest started to develop his pixel-based STL slicing software, where the pixels are at the RepRap machine's resolution (about 0.1mm). I thought that this was All Wrong, because it was going to be inefficient in memory use, and would not scale well. But I did think that a very similar scheme that used a quad tree to represent slices might be a good idea.
Just before Christmas, I realised that it is very easy to do unions and intersections on quad trees recursively (something I should have known...), so I implemented it.
But, though it worked reliably, and it was parsimonious in its memory usage, it was very slow in execution. A bit of testing revealed that it was the continuous quad-tree-walking to access pixels that was eating the clock.
So I threw away the quad trees and replaced them with pixel maps in the form of Java BitSets. That went a lot faster, and - in fact - didn't use much more memory at all. So Forrest was not All Wrong - he was All Right.
The code probably still contains bugs, and I want to do more testing before doing a release, but it seems to be able to reliably compute the G-Codes for an entire Mendel tray build (pictures above). On my 2GB AMD Sempron 3800+ running Ubuntu that takes about 2 hours. The total-memory monitor for the machine hovers around 630MB for all that time, not creeping up, implying no memory leaks.
It will handle multiple materials and allows single objects to be made from several STLs - one for each material. It does fine-fill over the surface and coarse-honeycomb interiors properly. It also now asks you how many of each thing you want to print, to save having to load multiple copies of them.
The next thing to do is to get RFO file reading and writing implemented, so that you can set up an entire tray, save it, load it, and edit it. Then I'll do automatic support calculations (virtually all the code is in there to handle that anyway, now).
It's in the usual place in the repository - download instructions here.
I've been a bit quiet for a while, owing to the fact that my pathetic brain can either communicate or work, but not both. About six weeks ago, I decided that the Java host software had not been looked at seriously for a long while, what with all the Mendel hardware developments that had been going on. So I decided to take it apart, put it back together again, then throw all the funny-shaped bits that were left over in the bin.
Ages ago Forrest started to develop his pixel-based STL slicing software, where the pixels are at the RepRap machine's resolution (about 0.1mm). I thought that this was All Wrong, because it was going to be inefficient in memory use, and would not scale well. But I did think that a very similar scheme that used a quad tree to represent slices might be a good idea.
Just before Christmas, I realised that it is very easy to do unions and intersections on quad trees recursively (something I should have known...), so I implemented it.
But, though it worked reliably, and it was parsimonious in its memory usage, it was very slow in execution. A bit of testing revealed that it was the continuous quad-tree-walking to access pixels that was eating the clock.
So I threw away the quad trees and replaced them with pixel maps in the form of Java BitSets. That went a lot faster, and - in fact - didn't use much more memory at all. So Forrest was not All Wrong - he was All Right.
The code probably still contains bugs, and I want to do more testing before doing a release, but it seems to be able to reliably compute the G-Codes for an entire Mendel tray build (pictures above). On my 2GB AMD Sempron 3800+ running Ubuntu that takes about 2 hours. The total-memory monitor for the machine hovers around 630MB for all that time, not creeping up, implying no memory leaks.
It will handle multiple materials and allows single objects to be made from several STLs - one for each material. It does fine-fill over the surface and coarse-honeycomb interiors properly. It also now asks you how many of each thing you want to print, to save having to load multiple copies of them.
The next thing to do is to get RFO file reading and writing implemented, so that you can set up an entire tray, save it, load it, and edit it. Then I'll do automatic support calculations (virtually all the code is in there to handle that anyway, now).
It's in the usual place in the repository - download instructions here.
Friday, January 15, 2010
A printable, high speed alternative to belts?
Herringbone racks and pinions might well be a practical, printable alternative to belts for high speed, NEMA stepper driven Reprap machines.
Would you like to read more?
Friday, January 01, 2010
New Year New Plastic
