Monday, February 14, 2011

Printing small holes in small features

In which your narrator discovers an out-of-the-box method of making small holes for pinned hinges in small features.

Recently, Chris Palmer blogged an exquisite article on the pitfalls of getting the diameters right in holes made in objects. It related very closely to a problem I was having in developing a printed robot hand.

Previously, I'd had no trouble in that the joints between the phalanges of the robotic fingers were very large and printed.

I loved this approach, but sadly had to abandon it simply because the large contact areas between the phalanges created excessive friction and because the number of things that I needed to have happening in a phalang made the large joints unhelpful.  The need for smaller, more compact hinged joints brought to mind the work of Frank Davies with his Sarrus Linkage positioning system.

Frank used pinned hinges to great effect.

As I was designing such pinned hinges into my phalanges, I soon discovered that the substantial pins that Frank was able to use were too large for the delicate phalanges that I was working on.  In fact, I finally settled on using simple paper clips (0.84 mm diameter) for the pins in my work.

In designing the joints, I followed the usual Reprap gambit and simply included the pin holes in the STLs for the parts.

The only problem with this approach was that both the hole and the hinge joint that it was seated in were very small.  The joint had a radius of only 3 mm and the hole 0.42 mm.  

Ordinarily Reprappers use a few print paths around the perimeter and then infill the rest. I design using thin walled parts glued together after printing, an approach that lets me create fine featured parts that are fast to print.  With a feature this small, however, print roads radiating out from the pin hole very quickly clash with print roads radiating in from the joint.

It's bad design practice to let a hot print head hover for extended periods of time over or near a small feature.  You want the head doing the feature then going far away quickly so that the molten plastic thread has a chance to cool a bit before the next layer is applied.  If you don't get this your small feature becomes a featureless blob.

Print road clashing between the pin hole and outer perimeter of the hinge had me fiddling around with print road width for the better part of a week with indifferent results.  Yesterday, however, an out-of-the-box solution to the problem finally hit me.  I'd do better at printing the pin hole if I simply didn't include it in the STL, something like this.

Basically, I just plugged the hole.  What that did is to limit the print road propagation to those radiating inwards from the outside perimeter of the hinge.   Since I don't use infill because of the problems getting the perimeter roads to match with the infill roads, for the first few millimeters of the print had no hole due to the use of perimeter roads to completely fill the layer.

Once I had the roads calculated I pulled up the .PNG images for the completely filled layers.  You can see the bit that will fill the pin hole circled in red.  

It was a simple matter to pull the images into Paint and remove the inconvenient loop from the images and then continue processing the images into Gcode.  

By calculating the width of the print roads appropriately, I was able to get the proper diameter for the pin correct on the first try.

The annoying part of this whole epiphany was that it took me over a week and dozens of trial prints to see the simple way of solving the problem.


Cefiar said...

Does Slice & Dice use .PNG as an intermediate format for translation into Gcode, or was this Gcode created with some other tool?

flarets said...

Using the streamlines to your advantage - very nice. So, using fewer boundary paths didn't work?

One step could be automated: after calculating the boundary paths, check to see if the part features still exist. If not, flag the user (or recalculate).

Forrest Higgs said...

@Ceifar I keep a set of images in .PNG for each step of the conversion process from STL to print roads.

That lets me have the possibility of cleaning up little imperfections or making graphical changes to the part at several points in the processing. I've found that flexibility very useful.

Once I have the print road images I convert those to an xml format and from there to Gcode.

@flarets "One step could be automated: after calculating the boundary paths, check to see if the part features still exist. If not, flag the user (or recalculate)."

I'm not sure I understand what you are saying here. Could you expand on this a little bit?

flarets said...

Sorry about that. Your slice-02.png shows the feature has been removed by the perimeter roads. I wondered if the program itself could identify this, then tell the user.

Forrest Higgs said...

@flarets It might. I'm not doing it at this point, though.

Pete said...

If I may, could you elaborate on what program you use to create a PNG file to edit and reprocess? I'm a Makerbotter using Skeinforge... that image you have looks familiar, but I wasn't aware you could adjust paths in that manner. Thanks a million, this is beautiful work by the way!

Forrest Higgs said...

@Pete A bit over a year ago, I got tired of having to relearn how to use Skeinforge and put money down for a program that would do Skeinforge's job being developed by Netfabb, a German company. They were supposed to have something working last March and this March they've still not delivered a non-beta product.

Anyhow, I'd written an app a bit like Skeinforge a few years before, so I started upgrading that one, so that I'd have an app that I could fix myself if there were problems.

Anyhow, that effort led to my personal STL processing app which I call Slice and Dice. I wrote it in Visual Studio .NET and treat the print volume as consisting of an aggregation of cubes which are 0.1 mm in dimensions in the xy plane.

When I process slices I treat the information as images rather than geometry, a dodge that lets me keep my code, which is a much slower than Skeinforge and other STL processors, very simple by comparison.

Thus, when I slice an STL I save images of each slice. When I go to calculate print roads, I create them by operating on the slice images and creating print road images.

At any point in the process, I can pull an image into an app like paint and fiddle with it if I choose. This gives me considerable flexibility in manipulating prints that isn't available with other conversion apps.

It's best to think of Slice and Dice as if it is a car that I pretty much always have the hood up on and the engine disassembled to a greater or lesser extent. I'm always tinkering with the code.

This frustrates people who'd like to use it, because the code is solidly alpha, not beta by any stretch of the imagination. I publish what I'm doing to give other developers of apps ideas. I'm not interested in doing what Enrique, who developed Skeinforge, has done which is to become consumed in the development and support for a large community of users of his app. I do what I do so that I can design and print things in 3D.

Mind, a bit of the approach that I use has been adopted by Adrian Bowyer and deployed in the standard Reprap STL processor.

Compared to Adrian's app and Skeinforge, though, I am way off almost over the event horizon. My app is very useful for making small, hollow, thin-walled parts that are subsequently glued together. It would be of very little use in conventional parts design as I have seen being done around the Reprap community.

Pete said...

Thanks for the response, Forrest. I definitely appreciate what you're doing, and may check it out at some point. I'm a camera modifier, and making small and detailed parts is sometimes very difficult. Thanks a million, I'll keep checking back!