Wednesday, July 28, 2010

Some thoughts and observations about having a Reprap machine in the design cycle

In which your narrator reflects on the rather radical difference between what he perceived the design process would be pre and post the advent of practical Reprap printers.

Do you want to read more?

From 2005 till November of last year, I spent most of my free time trying to build a Reprap printer. It was good fun and I learned a lot of things. Mostly, I learned how not to be intimidated by technology that I was not familiar with. For me, this was an extremely valuable lesson.

When my day job began to require more and more of my attention towards the middle of last year, my development of Tommelise 2.0, my own repstrap project began to suffer. Finally, at the end of October I sat down and did an unpleasant assessment of my situation. I could continue to work on Tommelise, or I could simply buy one of the Reprap-derived kits that were beginning to emerge from small enterprises started up by other core team members. I estimated that it would take something like another 6-8 months to get Tommelise 2.0 printing properly. I subsequently ordered one of Ian Adkins' Rapman 3 printers.

Rapman 3 is a re-engineered clone of the first generation Darwin design. I bought it rather than the somewhat cheaper Makerbot primarily because it had a substantial print volume but also because an associate, Batist Leman, had been blogging his experience with the model. Batist was very impressed with the Rapman and communicated that very well through his video clips of it in operation.

Prior to November, I was designing and making parts with the object of making a Reprap machine. Afterwards, I was designing and making parts WITH a Reprap machine. The distinction can be easily lost on those who have not used a Reprap machine.

What I have discovered in the eight months since is that the availability of a Reprap machine makes a massive change in one's design practices.

Prior to November I lusted after a professional 3D CAD package. Features like dimensioning and reliable boolean operations cluttered my thinking. The problem was that I was thinking like an engineer, viz, I wanted to make careful designs in 3D and then have print them out on an accurate 3D printer. I no longer feel that way.

With the advent of Art of Illusion (AoI) 2.8.1, I stopped lusting after "professional" CAD packages even though by that time I already owned several. My design cycle now looks like this.

  • (re)design (a) part(s)
  • print the part(s)
  • manually and visually see how the parts work together
  • repeat the process until satisfied
Precise dimensions became not very important while things fitting together properly did.  The linkage between these two factors was not as strong as one might first suppose.

With a Reprap printer it became a simple matter to run through a dozen design cycles to get a parts ensemble to work in a matter that suited me. I currently design with the Reprap printer as part of the design cycle rather than using it as a final step after design cycles are finished.

At the beginning of this year Skeinforge, which I had been using previously, went through a rough spot.  This encouraged me to invest in the upcoming Netfabb software prior to its release.  As the Skeinforge rough patch continued and the folks at Netfabb's release dates began to slip, I finally became frustrated and then angry.  I wasn't able to do the design work I wanted.

In frustration, I unearthed my old Slice and Dice code from the Tommelise project and began to bring it up to date.  Having used both Skeinforge and the nascent Netfabb offering to process STL files into print instructions I evolved a very different approach to processing solids files than what either of these two products offered. 

Both Skeinforge and Netfabb basically take your STL and give you print instructions.  They do it very quickly and efficiently.  Unfortunately, if you have a dodgy design file they can produce some very crazy print files.  Ones ability to respond to crazy print files is, perforce, limited.  With both Skeinforge and Netfabb, the majority of craziness is generated when ones STL files are flawed.  The need for perfect STL files had fueled my previous lusting after "professional" 3D CAD packages.

I responded with Slice and Dice by internalising Mandelbrot's maxim that noise is always going to be there and it will be unpredictable.  Instead of striving for perfection, Slice and Dice concentrated on giving me options to deal with imperfect design files.  I began by keeping each slice of a design file as an image that I could bring into simple image handling tools like Windows Paint and manipulate.  Paint let me patch and alter flawed slices to suit myself.  I no longer needed a "professional" 3D CAD system.  AoI was just fine for my purposes.

From there, I discovered that if you use 2-3 print roads to define a print's perimeter you wind up with a strong part even without infill.  I began working to improve my control of perimeter print roads and soon found that I could make parts not unlike those in old fashioned plastic model airplane kits which used injection-moulded parts that you glued together.  Infill became unnecessary in all but the most extreme cases.  Hollow parts were tremendously quicker to print and not nearly so prone to warping. as "solid" parts.  I don't use a heated bed and doubt that I will anytime soon.

Conventional Reprap thinking views a 3D printer as being able to print, more or less, any 3D object.  Development has concentrated on infill and support materials to achieve these ends.  Both are wasteful of printer time and materials, in my opinion.  I try to design parts which keep in mind the strength and weaknesses of my printer.

As you can see with this telepresence 'bot finger, I think I am getting pretty good results.

Monday, July 26, 2010

Memories of plastic model airplanes

In which your narrator harks back to his youth and fingerprints ruined by trimming plastic flash off of model airplane parts with double edged razor blades.

I have an aversion to infills. Recently, I realised where the aversion came from. During the 1950s you could buy plastic model airplane kits for $1-2. These were made with injection moulded parts that came on little flat plastic Christmas trees. Exacto knives in that era were both expensive, for a child at least, and the blades dulled quickly and were largely beyond the ability of a child to resharpen. As a result, this child nicked paper-thin double edged razors from the medicine cabinet to trim the parts off of the tree and trim the flash off of the parts.

That worked fine, except for the cuts which the blades would make on ones fingertips which eventually grew into permanent scars. That was no big deal in those days.

Having trimmed your parts you glued them together with Testors or Duco cement {ethyl or butyl acetate} and, with a bit of paint, you had a lovely airplane to hang off of your ceiling by a thread and dream about flying.

Early on in the Reprap project, we used Solarbotics gearmotors. When you opened one of the gear boxes of, say, a GM-3 you found that the housing had been made using the same injection moulding process that model airplace manufacturers used. With a working Reprap printer I quickly began to loathe the clumsy, infilled parts that we were designing. They wasted both time {to print} and filament as well. Worse still, one tended to stick the parts together with expensive nuts and bolts.

Why not make parts that fit together like the old model airplanes?

The trick there is that the old model airplanes inevitably had a left side and a right side or a top a bottom that were often simply mirror images of each other. This weekend I was design a finger tip with left and right sides. I had designed the left side and got it working acceptably and was going back to do the right side in Art of Illusion {AoI} when it occurred to me that it would be much simpler to just write a script to swap the sign of the coordinates of the axis that I wanted to mirror around. Writing that script took about five minutes and saved me a lot of time in redesign and reprocessing of the resultant STL since my script operated directly on the Gcode.

Printing the two halves was trivial.

It took a few moments to scrape off the raft and a few drops of cement to finish the part.

The result was an elegant looking part that would have been a right bastard to design and print conventionally.

While I've incorporated this simple mirroring script into my own Slice and Dice STL processing software it would be no big deal to incorporate it into the more widely used STL processing routines available to Reprappers either open source or commercial.

Sunday, July 18, 2010

First prints

Slice and Dice is pretty much working now. I'm not completely happy with how the infill and the perimeter prints hook up, but that's mostly parameter tuning. I'm debugging Slice and Dice while I am designing a robotic hand. Here is the distal phalange {finger tip} that I've done for a first try.

I've left out the infills in that they are not necessary.  Here you can see the first print that I am happy with.

I've really got to break down and find a camera that can do better closeups for small objects.  My periodontist uses one for photographing teeth, an Olympus, which might be the ticket.  I may well buy one after my quarterly tax payment is done towards the end of this month.

As you can see in this second pic, there is a separation between the outer and inner print road for the flexural axis.  I've got to reduce some the outer radius there or lower the extruder flowrate and go for three print roads instead of two on that part of the print.

Saturday, July 17, 2010

In production

Got the whole Slice and Dice ensemble running together last night and did some test prints. Vectorization cured up the extruder head slowdown completely for curved print roads. Sweet! :-D

Saturday, July 10, 2010

Operational again

I was able to put the final touches on the Slice and Dice upgrade last night. The app is operational again. Now I can get to work on that telepresence hand project. :-)

Tuesday, July 06, 2010

Vectorization of pixel defined print roads actually working properly

In which a very kind Adrian Bowyer takes pity on your narrator.

In my last posting on 21 June, I laid out a method for vectorizing a pixel-defined perimeter. Having read the posting, Adrian Bowyer, a published expert on this sort of thing, took me aside and showed me how to do the vectorization efficiently instead of just at all, the solution I came up with.

Using Adrian's approach, I was able to achieve my goal of getting exact vectorization of the print road and push out the average segment length to well over the 0.3+ mm that was required to assure a print head speed over the major axis of at least 16 mm/sec.

You can see an example of such a vectorization here.  All values, save the last, are in tenths of a millimeter.

The last value in the listbox, "rho/axis" should allow me to adjust the print speed on the fly in G1 statements to assure a constant head velocity for print road segments greater than 0.3 mm in length.

I should be printing ABS parts again by this weekend, which is good since I want to redesign and print one of these.