RepRap: Blog

Inspired by Fernando Muñiz over on the RepRap Builder's blog and by meeting Norman Frost of Sustainable Composites Ltd. (who kindly donated a sample of their UV-cure resin to me) I have been experimenting with thermosets. (There is plenty of time between my tweaking the parameters of my new Darwin as it makes a splodge of polycaprolactone almost resembling a cube.)

The idea is to mix the resin with a glass filler like this stuff from Tomps to make a paste, and then put that in the paste extruder with a ring of UV LEDs round its nozzle to set the stuff after it's been laid down.

Norman said that the ideal cure wavelength is 365nm.

The first thing I discovered is that cheapo vanilla 400nm LEDs won't touch the stuff. It just sits there and stays sticky for hours. So then I got some NSHU550A LEDs that emit at 370nm. The picture above shows one of these zapping a drop of resin about 5mm underneath it using a forward-bias current of 20mA. That forms a thick skin at 10 minutes, and is solid to the touch in 15.

Now. All we need is for each layer to be mechanically rigid enough to support the next, so that should be fine. And, of course, layers underneath will be further hardened as the layers above are laid down, because the UV will percolate down through the resin and the glass.

As you know, we've been working on using polylactic acid in RepRap because it's a plant-source thermoplastic that can be home-made, and when it's finished with it can be locally composted. Widespread use would take CO₂ out of the atmosphere then put it back, and so would be carbon neutral.

But Sustainable Composites' thermosets are plant-derived too. So using that resin to make stuff that gets thrown in landfill rather than recycled would be even better. Thermosets are very stable underground (think amber), so widespread takeup of them in replicating RepRaps would be carbon-positive...

Labels: CO2, LED, resin, thermoset, UV

Recently, I became a 'Fab Fellow' at the Sustainable South Bronx Fab Lab. This is very exciting for me, and yesterday I got the chance to actually go up there and use some of the tools. First up was getting a build base for my darwin CNC cut on the ShopBot machine. Check it out:


FabLab ShopBot Demo from Zach 'Iowa' Hoeken on Vimeo.

I couldn't really justify using Bath University resources to create a RepRap machine for me to use at home, so I bought a set of PCBs from Zach at the RRRF and a set of resin-cast parts from Ian at Bits from Bytes and put one together from them.

Over two weeks of elapsed time I think it took me about twenty hours work in total. I've copied the properties file from the RepRap that Ed and I have in the lab at the University and am using that as the basis from which to set up my own.

I know that Zach has just got his RepRap machine together too, so we're having a race to the first minimug. Watch this space...

Labels: Adrian, Bowyer, home Darwin

I did a foolish thing. I fixed a bug in the Java host code (in the bit that algebraically simplifies CSG expressions) and, instead of just checking that back in, I also spent some time tidying the code, then tested it, then checked in the lot. That gave Subversion revision 1333.

Unfortunately my tidying introduced several new exciting features that many users would have found not entirely helpful that were not apparent in my testing... Sorry.

Now (with Zach's help - thanks), the code has been reverted back to the version that worked, to which I have applied just my CSG fix.

The current revision is 1369. It's not perfect. But it's a lot better than 1333...

Next thing: fix the memory management...

Labels: host, java, software

I have something to do while my RepRap is out of action. Toby Borland has done a wonderful design of the RepRap which is meant to be cut on 4mm plywood. He has kindly released the
source, and I've converted an early version of it to the EPS format used by Ponoko on their laser cutting and vending service. We're putting the files up there for free use; we're not taking a cut. Ahah.

I've put up the plywood parts separately to the thick acrylic bed; I'll experiment with a 9mm MDF base but it might be too thin. Toby has since sent me some fixes for the plywood parts - already in EPS format - which I'll work in and scale according to how well the first batch of Ponoko parts fit. The files need optimising to reduce the cutting cost (mostly removing double-cut lines) too. Until that's done, the design should be regarded as pre-alpha and non-functional. As it stands, the ply seems to be slightly thicker than 4mm, so a lot of parts don't fit together properly. Oh yeah, I did muck up the scaling in a few places too - mostly ones that matter!

Prepare for strike two, and props to Ponoko for their support.

Vik :v)

Labels: laser, plywood, ponoko, reprap

If you've been following along in the forums, we've been hacking on an epic firmware bug for the Arduino based electronics (available from the RRRF). Well, I'm proud to announce that not only have we defeated it, but in the process I audited nearly every piece of code and removed anything that I though could have slightly caused a problem. The end result is that the Arduino code is now damn near rock solid. There still might be some slight bugs, and I dare you to find them ;)

For those who are curious, the bug was actually rather stupid on my part. It was related to the interrupt. I created some interrupt code that was set to go off at regular intervals. As this was my first time dealing with interrupts in my code, I had copied some code without fully understanding it. Not only was the code enabling the timer interrupt, but it was also enabling another interrupt... one I had no interrupt handler declared for. The end result: an interrupt handler with address 0 was called (which was the address of the first function) As you can see, this was exactly our bug. A certain set of conditions triggered the undesired interrupt which sent us back to the beginning of the program.

A huge thanks to Marius Kintel for his great catch. If you are ever in Austria, give him a high five and/or buy him a beer. I'm serious!

There are only a couple major things remaining with the Arduino code:

1. forward/reverse commands are not implemented. the single arduino code does not have enough room to hold them (that i can manage to write) the good news is that it may be possible to squeeze them in. also, they are not required to print, nor do i think they are used anywhere. darwinian evolution also means abandoning obsolete things (like tails!) ;)

2. the speed commands are not yet 100% emulated as on the PIC's. currently they are interpreted as RPM. as soon as i figure out how the PIC stuff is translated into time, i should be able to implement it. this is not a big deal, but just though i'd let you know incase someone wants to help.

Download it from SourceForge!!

As you can see, the Y-motor coupling broke near the grub screw closest to the Y motor. It had printed pretty much an entire RepRap before it failed, I should point out.

So the replacement PLA part fared little better. It deformed but didn't crack up over 20 mins or so of constant operation - trying to print another Y motor coupling, of course. The red mark is merely a leftover from me marking the length of the grub screw.


An attempt to patch it with a couple of hose clamps and some thick PVC pipe 6mm ID (normally used for hydroponics systems) also failed. After a while, the PVC softened and the coupling went all soggy.

I'll try a piece of Teflon. Hmm, nope, too weak - tap tears out. Teflon & hose clamps holding the grub in place, promising...

Vik :v)

I finally found some time to slog through some code and get my Darwin printing. This print was done using the Arduino GCode Interpreter started by mellery. The SNAP stuff is almost done as well, we just recently found the major bug and fixed it (last night). Hopefully I'll have a minimug to report tomorrow. =)

Anyway, not bad for its tottering first steps.

Read more on the builders blog entry.

Yes, I know, you have some e-mail about a pill that can fix that. I wish. The Y Motor Coupling disintegrated on my Darwin. Aha! I have a PLA spare! That lasted about 20 minutes (not even long enough to print a new spare) before it melted and deformed around the hole for the motor-side grub screw. Clearly, the polycaprolactone part isn't going to get a much better lifetime, 'cos it would just melt sooner. We can try going high-tech with adhesives, using stiff plastic tube and hose clamps, or just machining a part out of steel. I'm going for the hose clamps.

Vik :v)

As some of you know, the mediawiki we'd used as a template for objects.reprap.org has been infested with spammers for some time now. I've frozen the site in a spam-free but untinkerable state and will be mucking about with a cms-based replacement. I'm bringing this up because of an email from Tom Owad:

The Google 3D Warehouse has reached 300,000 objects, while the RepRap object library remains at seven. That size, coupled with the ease with which SketchUp and the 3D Warehouse integrate, has the potential to shut out open source software and place the world's object library in Google's hands. While I don't have a specific problem with Google, but I don't think a for-profit corporation makes the best library curator. There's great potential for things to go downhill at Google, especially after the founders die.

The Fab@Home project and all sorts of cnc projects all have their own independent libraries, none of which amount to anything substantial. I think it would be beneficial to see an organization dedicated to being a public _library_ for objects, separate from any specific hardware project. I think it may be outside the RepRap project's scope to build an object library that can compete with the likes of Google, but it would seem to me that this is well within the abilities and the charter of the Internet Archive. Perhaps it might be possible to collaborate with the Internet Archive to create an open object library?

Thanks,
Tom Owad

If people want to take on this project and build a site to do this, please read further on for the project requirements. And please hop into the forum with your ideas and expertise:
http://forums.reprap.org/read.php?58,9504

My take on it is that it would be useful to use a CMS, like plone.
I'll be tinkering on something to do this, but I don't know if it will work. Volunteering to help? Introduce yourself:
http://forums.reprap.org/read.php?58,9504
or email me at penguin@supermeta.com

I know what I want it to look like, which brings me to...

Project Requirements:

A standard wiki isn't suitable for this project, because of their 'everything goes' permissions model. This is fine for an anonymous article, but if you're putting up an artwork, or your group is working on a project, you don't want people stumbling along and tweaking or deleting it. (I'm not ruling out 'everything goes' projects, but most people will want more control over their projects, the way the linux kernel team won't let random users check in changes into the main code base without looking the changes over. This is also true if you have a flickr account.)

What we want in an objects library:

1) We want the obvious definition of an objects library. A straightforward hierarchical archive of files.

2) We want much more than an objects library; we want a site that can host RepRap and similar projects. Like instructables or the reprap docs wiki. Otherwise, it's just another file archive, which Google 3D Warehouse can do better than we can.

3) Along with the communal area, we want people to be able to own their own personal and group subsite. Myspace or your own favorite online community is a good model for this, in as much as it reveals how people like to use the web.

Example usage patterns:

A: General random files. "Hey, I caught a frog and scanned it. Here's the scan. Oh and here's a windshield washer reservoir cap for my Range Rover, and here's a wrench." We need a way to store these files, and a way for people to find them.

Priority: High.

B: We want to be able to host the RepRap 3D Printer files on it. Along with the .stl, .aoi, and .etc files, we want our documentation to be up there as well. where they'd have documentation, files, and so on. Just like we're doing with RepRap.org currently.

Priority: Middling High. We need this in order to offer more to users than just a place to dump files.

C: The user 'Jane' might have a page like:
"objects.reprap.org/people/tinker_jane"
where she puts up her projects and files, and people can comment on them, and say hi to her if she wishes. Jane needs to be able to do this: "This lamp was my senior design project. You need to print _these_ out, drill here, and solder _this_ like so. What do you guys think?"

Priority: Not as High, but if we don't do it, someone else will, and everyone will end up using their site instead of ours.

One of the frustrating things about developing the RepRap is the need to focus on making it actually replicate. I've had a few great ideas about RepRap pass me by for this reason, so I thought I'd better document them.

1. Make it print braille. In theory, easy. In practice, it needs someone to convert braille into STL (mistakenly called SVG earlier by torpid author).

2. A spooling device driver for the RepRap GUI. If we can produce pre-processed files, a much simpler production program is needed. This would allow RepRap to be driven by primitive controllers, PDAs and the OLPC.

3. A Logo turtle driver for RepRap. Logo is well understood in the educational sector, and runs on the OLPC. It would enable novel fabrication techniques to be developed by the young and inquisitive.

Pick it up and run with it, folks.

Vik :v)

Labels: braille, logo, reprap, stl, turtle

My LCD screen is starting to return to a less blue shade after enduring a stream of classic Anglo-Saxon last night. The cause of this was the crashing of the GUI software with an Out of Memory error about 98% of the way through the biggest part of the RepRap - the carriage.

I knew things were not going well. Garbage collects were happening with increasing frequency. I'd run the job to a nullcartesian device first to make sure it would print - probably best to close and restart given the current state of play.

I had "top" running, so I know it was all Java. No other applications of any consequence going on a 2GB machine.


Now the good news: Though technically incomplete, on inspection the part appears quite functional. There are some big blobs on it where the extruder was left running in garbage collects (should we force a GC at the end of a layer? Can we, or will Java "know better"?), but these will soon succumb to my trusty Dremmel tool. I believe I can now start work on the X axis assembly, the first phase of mechanical construction in our instructions. Yeah, looks like the picture on the left :) I leant on the X motor bracket and cracked it, but clear epoxy cures all ills.

Vik :v)

Labels: carriage, reprap

Need I say more?

Well, yes. The pads definitely stopped the corners curling. One pad didn't print (dodgy patch on baseboard most likely) and that corner started lifting. Not having superglue to hand after Oz, I put a dab of hot-melt glue on that corner to anchor it down, and that stopped the curl nicely.

The mounting slots for the smaller motors are a little short, but I've fixed the STL file and uploaded it. I'll just hold this one on place with some cunning wire-bending.

Next, the carriage.

Vik :v)

Labels: bracket, motor, reprap

A mini-milestone for you RepRap-watchers. Ed and myself have now fabricated half the V1.0 RepRap's parts, if you count them by type (i.e. we have 8 corner brackets but that only counts as one "part" even if I've only made one).

On the left is the latest batch of parts: X and Y axis Opto Flags, a couple of X Belt Clamps and a Z Studding Tie. I think the flags are the most delicate objects I've made, and appear to be approaching the limits for our current software's resolution.

Vik :v)

Labels: flag, half, parts, reprap

Being allowed to present RepRap at LinuxConf 2008 was wonderful, and thanks to all for the encouragement I got that really belongs with the RepRap team. So many new ideas, and very little time spent on repairs all considering.

One that stood out was the idea of using RepRap to print braille, and to make relief maps with textured surfaces to assist the blind.

I contacted the OLPC project to see if they would cooperate on ensuring an OLPC can drive the RepRap. Currently our software won't fit, and the OLPC is essentially python-driven so a re-write or novel way of printing the CAD files might well be necessary as things stand.

Finally, I've been porting Toby Borland's plywood RepRap files to Ponoko's upload format and I think I've got something that should print. Whether one can actually assemble what comes out remains to be seen. The parts cost for RP'd parts, gears & base is in the region of USD$350 and you can download the source. I say again, it's not quite perfected yet.

My Darwin has been chugging along while I work, having a little difficulty with the Z axis after its return from Oz. Perhaps I was just lucky before, but now the Z axis rubs on parts of the base. Being me, I've bashed holes to allow clearance for the nuts.

Here are three Y bearing housings, recently printed. One is marked with a break and is dud, the other two were printed after Adrian's recent accidental sqrt() bugfix. I now have 3 of them, and have manufactured bearings. Bearings look a little short on infill - OK, very short - but seem functional. I've just done another corner bracket (3 to go) and the next part is: Replacement Y axis flag.

Vik :v)

Labels: braille, lca, linuxconf, olpc, ponoko, reprap

Some people have been having troubles with the PTFE tube slipping out of the extruder. I have done a design modification to fix this: I put a couple of 3mm holes sideways through the clamp.

You put the PTFE in and clamp it gently, then run a 3mm drill down those holes. A couple of 3mm pins (or screws) placed in the holes then prevent the PTFE moving downwards under the force from the screw drive.

I've run this with the clamp screw just finger tight, and it all works solidly.

You can do this as a retro-fit: drill the holes (take care to miss the central hole where the polymer filament runs...) and put in a couple of pins.

I've checked in the modified clamp design to the repository.

Labels: extruder, PTFE rod