Wednesday, May 27, 2009

Semi-automatic: trigger mechanism...

I thought I would start with the most complex mechanical part, i.e. the trigger. The mechanical idea for this gun is not original. It was inspired by guns I have seen in the past that made me want one to begin with. Below was my first go.

It didn't work at all! I decided to completely redesign it. Below was my second go. It isn't perfect, but it works.

It is functional, but it isn't smooth. Still, I think I want to move on to other areas of the gun. The next challenge will be designing the barrel and handle in such a way as to snap together in some way. I realize nuts and bolts are cheap, but I welcome the added challenge of making them unnecessary in the design.

As this is a mechanical project (read moving parts) I thought it would be appropriate to include a short video of my second attempt.

Beginnings of a rubber band gun... from gavilan on Vimeo.

Tuesday, May 26, 2009

Semi-automatic: a beginning...

Why am I designing a printable semi-automatic rubber band gun?...

I enjoy working on things that have an immediate purpose and a higher purpose. The immediate purpose is that this was the gift Santa never got me. The higher purpose is that it will serve as a proof of concept that software engineering practices can be carried over to mechanical engineering. Now that I have a 3d printer I want to see if I will be able to quickly prototype a small subset of the overall mechanical functionality, test it, and repeat.

RepStrap: parts update...

This is where I currently stand with my RepRap parts.

I had a realization recently that I should stop focusing exclusively on passing the RepStrap -> RepRap threshold. I have been focusing all of my energy on finishing a set of parts because I should get a shorter print time and more precision with these parts. Still, I am currently getting an acceptable print quality / time... and I freaking have a 3d printer! So, I decided to start using it for more than just Darwin part creation. There were reasons why I wanted a 3d printer after all.

One thing I love about software engineering is that you can design a small component, test it, get a feel for how the technology and concepts work, and then use it as a building block in the big picture and end result. Ever since I started building a 3d printer I wanted to try these techniques on a mechanical problem. I have decided to start doing just that.

As a parallel thread of effort I have decided to create a printable semi-automatic rubber band gun. Should be fun... and keep me busy while my Darwin parts are printing.

Friday, May 22, 2009

RepStrap: starting to trust...

Before last night I had no trust in my RepStrap, and for good reason. I have dealt with lots of hardware crashes and software crashes since my first print. On the hardware side the Z axis has given me real difficulty. The last issue I faced was that the calibration would slowly drift after several prints. This was due to the belt slipping only slightly, and only from time to time. Two or three prints later and I had to recalibrate. I know that there are other belt tension solutions around the RepRap blogs, but I needed something a bit more flexible. I came up with this.

It's just an extra bit of thread rod, a printed idler pulley, and some rubber bands and string. I have printed 10 parts since I put this on and have yet to recalibrate.

My software problems ended as soon as I switched to Skeinforge. Last night was the first time I trusted enough to let the printer run all night. I am now letting the printer run 24 /7 and my collection of parts is quickly growing. Here are some images of my most impressive print. The three objects that make up this part took a total of 8 hours to print. Its a bed corner, constraint bracket, and bearing insert for the Darwin.

Next on my agenda is to tackle my warping issue. Basically, the corners of the base of my print are pulling up, making the bottom not completely flat. It hasn't bothered me as of yet because all the parts I have printed are relatively small. I will eventually be wanting to print the X carriage, which is quite large. I am concerned that if I don't solve for warping before attempting this part that the part will be unusable.

I will be looking into different printing surfaces(right now I am using Plexiglas), cooling techniques, and printing speed to see if I can solve this.

Tuesday, May 19, 2009

RepStrap: a software comparison...

As soon as I got Skeinforge working I wanted to do a comparison. For each pair of images the first is an image of an optoswitch-bracket printed by the host software GCode. The second is an image of the same produced by Skeinforge GCode. With no further ado:

Sunday, May 10, 2009

RepStrap: much better software...

As I have said before, the RepRap host software is not fun to use. There are several reasons for this. First, it's a memory hog and crashes if you are not careful. My workaround for this is to first create the GCode through the host software and then read it back in. Thus, I am really only using the host software for converting 3D STL files to machine instructions GCode. Second, the host software writes very poor GCode. I have experienced axis drifting, random noise, bad layers, and bad prints. I have finally had enough. I spent the first part of the day looking for alternatives.

Skeinforge is a model to GCode converter that was written by Enrique Perez. It is used by Nophead and is the suggested converter of the CupCake. I decided to give it a try. It took me a while to get the hang of it. I now plan on using Skeinforge exclusively.

So far I have noticed the following benefits of printing from GCode that was generated by Skeinforge. When it pauses for cooling between layers it keeps the extruder head moving. This eliminates the head from burning and warping and oozing on the object. Its filler strategy uses less plastic and looks to be stronger. It converts objects faster. The end result is a better print.

I hope to post comparison pictures in a bit.

Saturday, May 9, 2009

RepStrap: more parts...

I haven't been able to take time to work on my projects for quite a while. Now that I have time I decided to resume where I left off by finishing a set of Darwin parts. Here is a part I have been having difficulty with. This is an Opto Switch Bracket. The first few goes turned out funny because the Y axis drifted. I'm pretty sure it was a software bug because I printed to GCode and read from the file without any problems.

Now that my hardware is working consistently the host software is really the only thing giving me problems. I would rather deal with its shortcomings than take the time to rewrite it, so I am just taking the quick way out for now. Printing to GCode file and loading it back in seems to work pretty well.

Below is a corner bracket I just printed. This print took five hours.

I am getting quite the collection of parts!