Where is the best thread making video featuring correct method?

Hi Jim,

Two points:

(1) Yes, tapered threads are supposed to be tightened until they “jam” together forming a tight seal. In fact, the two surfaces are supposed to slightly deform each other (very slightly), from what I understand. However, in theory, there should be no voids for a perfect thread, screwed into a perfect nut or coupling. (Okay, some minor technicalities at the rest and roots of the thread, but the flat parts of the thread profile should, in theory, generate no voids if geometry were perfect.)

(2) I’m almost sure, that the deviation from the normal frame will not be consistent for a tapered thread. I’ll try to make a demo for this. In fact, I thought exactly as you do, and was then confused about why my surfaces didn’t join together.

Some initial intuition for now:
(A) A 2d Archimedes spiral, or arithmetic spiral is actually pretty weird. Every time it crosses the x-axis, it crosses at a different angle! This is extremely different from a geometric spiral, which always crosses the x-axis at the same angle.
(B) Our tapered thread is based on an Archimedes spiral, just one that moves upwards in the Z-axis.

If you like, a 2d Archimedes spiral in the XY-plane is just an extreme version of a tapered helix. It’s so tapered, it’s flat! (Taper isn’t just a few degrees, it’s 90 degrees.) So if your intuition is correct for all tapered threads, then it should be true for threads that are (almost) tapered at 90 degrees. Say, extreme cases where the taper is 89 degrees (almost flat!).

I’ll make a demo of this, and post it shortly.

btw, I’ve been interested in posting about all this, because I was very surprised by it, myself. And I had the same intuition as you did, until I tried making actual geometry in Rhino.

–Anthony K. Yan

It would be nice if someone split the last, say 25 posts or so into a separate topic - as it’s so far off the original and so long that this thread has become almost impossible to read and find the actual proposed solutions to the OP’s problem.


Okay, let’s look at an extreme example, of a simple flat Archimedes spiral in the XY-plane. Does this agree with your intuition? You might expect all of the tangent lines to be parallel. But they are not. In fact, the right-most tangent is almost vertical, and the tangent line at the center is horizontal.

The tangent line is the “X-axis” of the TNB frame that is used by Sweep1-roadlike. So if these tangents aren’t parallel, but are tilting more and less, then the rail-shape cannot have a consistent orientation relative to the origin (which is the “axis” of the spiral).

Here’s the .3dm file for that.
2d Archimedes Spiral.zip (204.5 KB)

–Anthony K. Yan

Please be specific. How?

And all that detailed and interesting stuff on Tapered threads into another.

Not to mention the iterations of other similar permutations of threads being avoided due to the fear of being labeled as ‘necroposting’.

Although this subject matter has been going on since the '70’s, sooo…

I agree with this 110%:

That’s why I often will 3D-model threads maybe 7 times outa 10, on my projects. But CAD’s don’t make it easy. Although, it seems to be easier for users and more common, than 15 yrs ago.

I’m sure 3D printing is driving it.

Hi ,
V5, yes split the thread into a new one on all this lovely talk over thread making, keep this to my own particular post, though it asked for vids on thread making, and whilst nothing worthy much was seen, its become little o me struggling to replicate this real thread.

so in fact I guess 3 threads.

and here is where I am now, just going at it before looking in on forum thread, following Jim, Tom and Jeremy methods. I have redone that profile as absolutely carefully as I am ever going to manage.

I even found that snapping helix to the radius line gave a different diameter to entering a value. 3 times I redid it, as at one time it was badly adrift from the profile mirrored downwards. even the circle centre snap had gone odd ball. so hyper checking everything, and not trusting snaps, and the helix tool is a bit off at times, I have this.

and I do a Jim Multitrim, and it doesnt work. :confounded:
Then I do a single trim and get the rear end to work. :grinning: :grinning:

but the front end despite a Jim Multitrim fails. :confounded:

I have aligned the cones and ends to give me the distance of the original required.

so what now ?
Thread make_REDO PROFILE fix error.3dm (2.4 MB)

maybe make cutters and thread solids, then try for a boolean difference ?
off to have a late lunch at 6.39pm…as its doing me in despite hammering away at it, ! and see what suggestions there are.


Out of the countless files I’ve repaired over the yrs, the vertices commonly give users trouble, in terms of achieving closed solids or not – for example.

There’s also something to be said for the ‘inflections’ that vertices cause in rendermesh curvature composition, and also something to be said whether Rhino can fillet geometry that contains edges, vertices etc. successfully or not.

Hence, edges/vertices/seams (seem) to be the route cause for common problems in Rhino. Maybe cause (when) users don’t mangage them accordingly – it doesn’t really matter why (for the sake of my point here).

What matters, here to my point, is the probability of a vertice(s) being necessary or not, by ‘existing somewhere’ or ‘being positioned one place’ or another, and leading down the road to ‘failures’ in other features that are intended to emerge through further design developments down the road.

3D-thread-geometric-etities shouldn’t contain a whole bunch of vertices – imo.

(Meshes are a different story of course.)

I’m just reviewing and compiling to find where the angle changed from 55 deg to 60 deg.

I’m definitely more familiar with 60.

Locking down and specifying all the parameters is definitely of the upmost importance in order to convey the design intent.

It would be nice to be able to design shapes like this ‘parametrically’ and see what the degrees-of-freedom are, especially for the designer to see what might happen if they change the parameter from 55 to 60 and so forth.

Before being adopted as a British Standard it was known as the CEI thread.”

I’m only seeing 20TPI here: https://britishfasteners.com/threads-cei

Not here: https://britishfasteners.com/threads-bsc

So, as per Pascal’s point:

So if you want 60 degree and 20TPI along with all the other radius data, it would have to be determined if this thread profile is closely following some standard, or if it’s some hybrid custom profile, with some particular custom design-intent driving it, etc.

If only someone could set this up with that super fancy parametric GH using geometric constraints and dimensional constraints so we can analyze this properly:

" 20 tpi can be seen as well for 7/16 and above." so I guess the radii or depth would have to adjust.

You don’t have enough threads to reach all the way through the cone.
Try it now:
more_thread.3dm (378.4 KB)

I adjusted threads relative to cone, and tried for boolean difference…I get more success ,

It has no choice with boolean Difference, something gets chopped !

and BINGO.

then look in on forum again, so more threads up front. and I sort of did that by ensuring I had solid .

Learning all the time, and many thanks Jim Jeremy Tim, CAD CNC AND all that have helped.

I planar sliced the end with a surface, then cut the surface with the result and joined, made a cutter and boolean diff’s it. and I am done . :star_struck:

Now I must make the thread in the item this screws into.
I presume I clone and offset surface by 0.0002 or whatever the tables say. then boolean difference this from the solid I have. I bet its not that simple.

One small thing I am niggled by, the catching of the top of the previous turn of thread.

Any ideas welcome. has to be to do with cone angle, but 52 degs is what I measure on this item. so I replicated it.

Thread make_REDO PROFILE fix error boolean Difference the front 001.3dm (2.7 MB)



1 Like

On that page it says:

1 Like

Weird they don’t put it on their chart. Seems like there should be something more consistently refined after 53 yrs.

It’s a funny thing to say on a thread data page haha.

I’m looking for thread data, but it’s good to know they have some taps n’ dies somewhere hah.

My trade secret is to not use a ‘cone’ shape per say. So, ‘ramp’ part of the initial thread until it goes from zero ‘trough’ to 100% ‘peak’, then done – no full revolution (technically not a revolve op), and no cut into next thread adjacent.

But some might argue, “no that bad”. :grin:

Side note:

I wanna know the rest of this part :sweat_smile: it probly top secret :money_mouth_face:

Just to be clear, afaik no standard includes a 1-1/16" thread so as I pointed out way back this is probably proprietary. However, as Steve said it came from a company which made cycles it is possible they have adopted a profile they knew well

Yeah, that’s been pretty clear, which is why I’ve been wondering what the degrees of freedom are in terms of how closely, and why bother, to pretend such of any magnitude of conformation towards said ‘standard’ which simply does not match.

Bottom line is, what are the parameters, and what works.

But I guess he got it. I just wish I knew what the other end of this thing looks like lol. I’ll probably put a round flange on it, if I find time.

Show me where this has a surface that shares a vertice twice:

Thread make4t recopy again remove threads_dims_emod.3dm (13.7 MB)

I did miss the back chamfer on the base thread relief, guess I’ll have to do another version later.

I changed the description of step 2.

  1. Select the cutting objects.
  2. Select the parts of other objects or the cutting objects themselves to trim away.
1 Like

Okay, here is the simplest demo that I should’ve come up with earlier. So if you like, you ditch everything I said earlier, and just look at this example.

The black spiral was created using Rhino’s Spiral command.
The green triangle starts off perfectly square to the spiral axis, and in a plane that contains the axis.

If what you believe is true (which I also believed!) then a Sweep1-roadlike should end with a triangle that is also square to the spiral axis.

Zoom into a Top View of the end triangle which I’ve now made as a red surface, so it’s easier to see. Clearly, the last triangle is not squarely aligned with the helix axis.

You can also see that the iso-lines start to get wonky as the helix spirals inward.

If the triangle were a thread-profile, then the generated threads would not always be cut in a plane that contains the helix axis.

Surprising? I was surprised the first time I realized this. But now it makes sense to me, given that Sweep1-roadlike uses the TNB-frames.

I’ve attached the .3dm file used for the diagrams. Feel free to look at it, or try to reconstruct what I’ve done from scratch.
Tapered Helix Test 2.0.zip (2.2 MB)

That’s better but it really doesn’t cover it.

The way it was designed to work way back in Rhino1 when objects were to be trimmed against each other is the user could pre-select all the intersecting objects then run the trim command and snip off the parts that were to be trimmed away and then hit enter (or right click) then run Join command and your done.

In theory, this could be turned into a macro and trimming and joining would be a one-step operation. That probably wouldn’t be 100% reliable. Its best to see if the trimming works before proceeding to Join.

The point is that trimming them all at once is sort of like a boolean, but far more reliable.than a boolean. When the trimming part fails you can easily determine why it fails. Steve1’s last attempt at trimming and joining the ends of his threads with a cone is a good example. The trimming failed on the cone part because the thread part did not extend far enough to fully cut away the cone part. A boolean operation also will fail but you don’t have the immediate feedback that tells you why it failed. Also, booleans can fail or produce results the user does not want because there can be extraneous intersections that the user doesn’t want involved in the trimming operation. With trimming the user can choose what is to be cutoff and what is not.

The procedure of pre-selecting and running trim and join is more accurate as well as more reliable than trimming individually or using booleans. More than one example can be found in the above discussions. In this example from the above topic discussion thread_end.3dm (551.4 KB) a boolean will work, but if you use that you get noticeably less accurate results. Its as if a different , sloppier intersector code is used for booleans than for trimming. And then people who are hooked on booleans wonder why their booleaned object cause all sorts of downstream failures that they would not have if they used trimming and joining.