Added a `tap` module to create positives for internal threads

[bvarner]

While switching some existing projects over to use this library (which I consider to produce better thread geometry much faster than other libs I've used) I ran across the mental block of adding interior threads to a pre-cut hollow, which broke my brain a bit.

I find it more natural to think of adding a threaded hole to a solid as a 'tap' or difference() operation, rather than differencing a hollow and then adding interior threads to it.

For this reason I've created the, tap(...) module, which creates a positive of the internal threads suitable for differencing to produce a threaded tap hole.

A simple test-case demonstrating the cross-section of a tap() and a bolt() is included.

[bvarner]

Incidentally, this addresses the use-case in question #41

[adrianschlatter]

I like that idea. It is intuitively appealing because it corresponds to the traditional way of creating internal threads. Also, it will in some cases probably reduce the number of lines of user-code: A difference is needed anyway to create a cylindrical hole. The tap will create hole + thread in one go.

Can we make that even better? What about length of the bore vs length of the thread? Let‘s say I need a pipe of 5 cm length. Inside, I need an internal thread of only 2 cm length. Could we also solve that in an elegant way, i.e., without reverting to differencing a hole, then adding a thread? Have tap use an infinitely long cylinder maybe? What about blind taps?

[bvarner]

I think it would make sense to add a shoulder length (unthreaded portion) but I think if you're going to start specifying 'length's (which I really like) we should address the shoulder part in another PR (under another issue, perhaps?) After I submit a PR for 'length' that doesn't break backwards compatibility, and that I believe addresses the concerns you expressed in #39.

[bvarner]

As far as blind taps go, I've had great luck with printing blind-taps using this method.

Example:

use <threadlib/threadlib.scad>

difference() {
    cylinder(d = 10, h = 10);
    translate([0, 0, 10])
        rotate([180, 0, 0]) 
            tap("M4", 4);
}

[adrianschlatter]

I didn't want to keep you waiting but I currently have limited access to computers (which won't change for the next 2 weeks). I see in your example that the thread is "cut-off" on the open side. I will want to avoid that because it can lead to problems with 3D-printing (thin remaining walls) even though it is exactly how it would look when tapping a thread the traditional way.

[unrzn0]

What you actually need is some kind of phase. I've added the following to my projects with threadlib:

module phase_ext(designator, table=THREAD_TABLE)
{
    specs = thread_specs(str(designator, "-ext"), table=table);
    P = specs[0];
    Rrotation = specs[2]/2;
    {
        difference() {
            cylinder(r1=Rrotation+P+0.01, r2=Rrotation+P+0.01, h=(P)+0.02, center=false, $fn=120);
            translate([0, 0, -0.02])        
                cylinder(r1=Rrotation-0.5, r2=Rrotation+P+0.01, h=(P)+0.05, center=false, $fn=120);
        }
    }
}

module phase_int(designator, table=THREAD_TABLE)
{
    factor=1;
    specs = thread_specs(str(designator, "-int"), table=table);
    P = specs[0];
    Rrotation = -specs[1];
    phase=P/2*factor;
    cylinder(r2=Rrotation-0.01, r1=Rrotation+phase+0.01, h=(phase)+0.02, center=false, $fn=120);
}

[adrianschlatter]

I have found the time (and the tools) to checkout your pull-request and experiment with it a little. I think that tap(...) is the natural counterpart to bolt(...). It does have the difficulty that the user needs to increase or decrease intended dimensions a little to make OpenSCAD remove a surface. But so has the bolt(...) module (and OpenSCAD in general). I don't see a way to fix this.

Also, I think nut(...) with its "Douter"-argument was the wrong way to go in the first place. tap(...) is better.

I have merged your PR with a slight modification to the :author: comment in threadlib.scad. Thanks for your valuable contribution!

[bvarner]

Thank you, Adrian for taking the time to review / polish this up!

btw - I also printed out a few test-prints with tap() and they threaded perfectly with M4 screws printed with 0.15mm layers on my prusa-style fused deposition printer. I did find that if I add a small chamfer to the outer entry point it was easier to align the bolt for initial insertion, but I think that should be an exercise left to the designer of a part using a tap().

On Mon, Aug 3, 2020 at 9:28 AM Adrian Schlatter notifications@github.com wrote:

I have found the time (and the tools) to checkout your pull-request and experiment with it a little. I think that tap(...) is the natural counterpart to bolt(...). It does have the difficulty that the user needs to increase or decrease intended dimensions a little to make OpenSCAD remove a surface. But so has the bolt(...) module (and OpenSCAD in general). I don't see a way to fix this.

Also, I think nut(...) with its "Douter"-argument was the wrong way to go in the first place. tap(...) is better.

I have merged your PR with a slight modification to the :author: comment in threadlib.scad. Thanks for your valuable contribution!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/adrianschlatter/threadlib/pull/42#issuecomment-668022683, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMTKLZW4YFCNMQMI2G2FXLR623O5ANCNFSM4OUVQ5EA .