[BUG] Higbee Corrections - formal from original patent 1891

[dr-occams-r]

Firstly, thank you so much for these amazing libraries! Both BOSL and BOSL2 are incredible! :)

Issue: Higbee rod (bolt) thread is only half profile, it should be full profile. Higbee nut thread should be implemented also.

Refer to original patent US447775A published in 1891 (link below). The drawings of the of both the rod (bolt) and nut starts are much clearer than what I could explain by text.

https://patents.google.com/patent/US447775A

[dr-occams-r]

In reviewing the BOSL2 threading.scad code and the original patent, it might be simpler to add a parameter controlling the length and/or angle of the bevel and removing the current Higbee code. The Higbee parameters could possibly be kept as a alias for bevel (or very short bevel to keep with the intent of Higbee).

Another simple option to code is to cut off the end straight or some other simple variation (eg: constant slope)

The key feature of the Higbee thread end is: blunt and symmetric alignment with the thread.

From the original patent: "The exact form of the thread end is not very important so long as it is blunt and substantially symmetrical with respect to the center line of the thread. It may be cut off on an oblique plane, as in Figs. 1, 2, 3, and at, or cut off square, as in Fig. 5, or rounded, as in Fig. 6."

Any thoughts on this? Was there a specific reason for a truncated Higbee? I might submit a PR, but I rather do something that aligns with the teams vision for this library.

[revarbat]

For the most part, I made the original higbee code to try to emulate the forms of threads on glass and plastic bottles, for bottlecaps.scad. There isn't much consistency on the exact form, though, from bottle to bottle, and I'm unclear on the right way to handle this.

I actually wrote and rewrote the higbee code two or three times, which is why there's an inconsistency in higbee by degrees and higbee by length between threading.scad and spiral_sweep()

[dr-occams-r]

I just noticed that your thread_helix() does a perfect Higbee, but not the threaded rod because the top and bottom of the thread is truncated.

I tried playing with the code of the generic_threaded_rod(). Reducing the twist seems to permit the Higbee taper to be completely exposed instead of truncated. However, the Higbee code in the threaded rod is quite different from that of the thread helix, the change will be a bit more complex.

For now, using using the thread_helix() to get a proper Higbee is ok for me. But since I am digging into this, I would be happy to help in any way possible, including submitting a PR. Reading your comments in the code, it almost seems like the main difference between the two functions is specifically for the performance of rendering the Higbee taper. Maybe you could provide some guidance on how you best see the correction of the Higbee in the generic_threaded_rod() or maybe it's not really possible?

[adrianVmariano]

I tried to decipher the original patent. I found the diagrams basically incomprehensible. It I understand how higbee is supposed to work, it's that you abruptly cut off the threads without narrowing or scaling them. And in fact, a simple vertical slice is valid:

as compared to the unmodified thread, which has a partial thread running to the end:

You're allowed to also cut them at a taper or curve, but it's not required. (Above example was produced by cheating, not by modified code.)

The current code in generic_threaded_rod scales down the threads, so it doesn't do the right thing. It seems like modifying the code of generic_threaded_rod to produce this abruptly truncated thread would be the easiest way to produce a compliant higbee.

The module thread_helix() is different because it produces tapered ends where the sample rate is higher, which makes the taper actually look OK. This is also not higbee. This module was designed to make bottle threads and is correct as it stands for that purpose, I think. That is, bottle threads actually taper approximately in that way.

So paths forward would be to either (1) merge the two thread makers and add real higbee as an option along side tapering, or (2) alter generic_threaded_rod to do higbee. There's a question of if it's at all possible to do higbee on internal threading. With the simple abrupt truncation it might be. With something fancier pretty sure not.

I think the theory was that the method of generic_threaded_rod is faster than the other method for making threads. It seems like thread_helix should be changed to refer to thread tapering or something like that and the "higbee" language removed.

So if the above is all correct...what's the right path forward? The problem with the cut face I show above is that it is no longer a tidy array of vertices, because you have to repeat one set at the cut. It's possible to do a single step transition with barely any code change. That looks like this. I had to change style to "convex". Not sure if that looks bad under some other situation.

This seems like a pretty good solution, actually, if "convex" doesn't break anything elsewhere. Here's a lower $fn example:

So the hard part actually is figuring out the point in the threading to make the cut. I don't know how to do that at the moment.

[adrianVmariano]

It seems to actually work OK to set the higbee angle to 180/starts though it's not quite right. Under some circumstances it is a little too close to the end. The strategy seems to be clean for all the profiles except buttress threading, which has a funny looking pair of quads on each side of the higbee cut. But overall threading is OK with style="convex".

Making this work for internal threading is harder, though. It requires making a change to the top/bottom half of the profile, which means assuming things about the profile. And then you need to union on a cylinder at the ends, which means figuring out where it starts. I was also wondering about how higbee interacts with chamfering at the end. It seems like the chamfer could obliterate the higbee.

I do wonder how the original poster was using the thread_helix to produce higbee. Was it by setting higbee=0?

[adrianVmariano]

Internal thread mask with higbee:

[dr-occams-r]

Thank you for working on this issue. I am happy to help as much as possible because the BOSL libraries are absolutely awesome and I want to support and give back to this project as much as possible.

Here is a specific demo example. I use this pattern extensively now, including for 3D printed parts that screw together. Meaning, I create the helices, then add them to the other parts, I do not cutout the nut anymore. Additionally, to be explicit in this demo, I have not used the internal $slop and instead explicit set the Thread Tolerance between the bolt and the nut. I have used the term bolt and nut to simplify the discussion for a specific use case.

Although I would like to have a modular way to call the functions for both the Bolt and Nut thread without repeating most of the code, I haven't figured out a more efficient way. Ideally, it would be a thread_pair object with some over-rides as required, in particular, internal, slop/tolerance, sometimes length.

include <BOSL2/std.scad>
include <BOSL2/threading.scad>

// aka slop
Diameter = 20;
Length = 40;
ThreadTolerance = 1;
HigbeeLength = 5;
Pitch=10;
Depth=3;
Angle=45;
BoltThickness = 10;
BoltThreadDiameter = Diameter;
NutThreadDiameter = BoltThreadDiameter + ThreadTolerance*2;
NutInnerDiameter = NutThreadDiameter + Depth*2;
NutOuterDiameter = NutInnerDiameter + BoltThickness;
Turns=Length/Pitch-1;
OffsetUp=Pitch/2;
BoltLeft=Diameter*2;
NutLeft=BoltLeft*2;

module BoltThread(){
  thread_helix(
    d=BoltThreadDiameter,
    pitch=Pitch,
    thread_depth=Depth,
    flank_angle=Angle,
    higbee=HigbeeLength,
    turns=Turns
  );
}

module NutThread(){
  thread_helix(
    d=NutThreadDiameter,
    pitch=Pitch,
    thread_depth=Depth,
    flank_angle=Angle,
    higbee=HigbeeLength,
    internal=true,
    turns=Turns
  );
}

module ShowHelices(){
  BoltThread();
  up(OffsetUp){
    #NutThread();
  }
}

module Nut(){
  left(NutLeft){
    #tube(
      id=NutInnerDiameter,
      od=NutOuterDiameter,
      h=Length
    );
    NutThread();
  }
}

module Bolt(){
  left(BoltLeft){
    cyl(
      d=BoltThreadDiameter,
      h=Length
    );
    BoltThread();
  }
}

ShowHelices();
Nut();
Bolt();

[dr-occams-r]

To answer @adrianVmariano's question:

...was also wondering about how higbee interacts with chamfering at the end. It seems like the chamfer could obliterate the higbee....

Chamfering a thread results in self-threading start. It is the lazy way for a machinist to finish a thread and results in serious problems when used, which was the original motivation for the Higbee thread. Thus, chamfering and threading should be kept separate. By offsetting the start/end of threads from the end of the part, it leaves space for chamfering/rounding without touching the Highbee ends.

A simple way to deal with this is to always leave a half-pitch each end of the thread for both the nut and the bolt. See my example Turns=Length/Pitch-1; . Then add extra required space for the chamfering.

For the nut thread cutout end : When a bolt threads into a capped nut or a threaded hole, the thread should never go to the bottom, the bolt should never touch the bottom and the thread should not have the cutout profile butt end of the thread which would cause the turning to be stopped by the thread itself. There may be dirt at the bottom of the hole, 3D Printing artifacts, the bolt might stretched a bit when being tightened and it would be rare that the desired pressure point is the bottom of the hole or end of the thread. Normally, the bolt is clamping something down with it's head, so the bottom of the hole itself and the thread at the bottom of the hole needs to have some working space (tolerance).

[adrianVmariano]

There are two different sets of threading code. The code you're using was intended for the plastic threads on bottles. The other code was intended for other types of threading. I rewrote generic_threaded_rod so that it generates correct higbee ends, I think. That code is faster than using thread_helix(). I renamed the higbee arg to thread_helix to taper, since it isn't actually doing higbee.

Note that in principle, tolerance and $slop are two different ideas. Tolerance is needed so that the screw and hole can theoretically interface, which requires some gap, whereas $slop is meant to handle fabrication error. If you look at screws.scad it manages screws in such a way that you can make a matching nut as the child of its screw (and vice versa) or save it's characteristics in a variable for later use, so that you don't have to repeat parameters. But there's no general mechanism to do this for other kinds of threading. You could presumably make a module that holds the desired threading parameters, maybe just passing internal.

The higbee parameter will let you stop the thread before the bottom of a hole if you want to do that. But really, it hardly matters if the thread goes to the bottom. What matters is that the hole is deeper than the bolt, so the bolt doesn't hit the bottom of the hole.

Right now I think bevel is on by default for threaded rods and as I noted, this isn't good for higbee. I'm not sure if beveling should just be forced off, or if the beveling should bevel just the internal section. (The problem with the latter case is that it will kind of fail if the user specifies too small of a higbee amount---the undersized bevel will cut a groove.)

[dr-occams-r]

Thank you for your responses and for working on this. Generally, the flat higbee as proposed by the current bugfix (also now in the current wiki for both bolt and nut) look good in virtual models.

However, in the physical world, and in particular when 3D Printing, they will also be less than ideal. The most problematic situation is when 3D printing, there are always printing artifacts, clumps, and other deformations, in particular on corners. When the nozzle goes over a corner in particular, there are more often deformations. Additionally, corners are often start and end points for the printing path. There are slicer adjustments to deal with that, but that requires tuning and on complex parts, might not be trivial to sort out.

These corner deformations mean that when trying to thread a 3D printed bolt in to a 3D printed nut with the flat higbee, the two starting plates might not pass each other, even if the rest of the thread fits perfectly. Of course, tolerance and printing quality can be increased or post-printing processing can be performed.

But all of this essentially means that the flat higbee is not a robust solution overall. Especially since the rounded higbee is already there and threads are often part of complex and often critical parts, I feel that having a good and robust higbee is more important than faster processing time. 3D Printing time is way slower than OpenSCAD processing times, so I rather longer processing than a non-functional print that requires various tuning and a re-print.

I had previously stopped using the BOSL (1st gen) for threads because the starts (raw, taper, higbee) would cause the 3D printed threads to self-thread and the parts would quickly lockup crooked unless extreme care was taken when threading. This was not a robust thread solution. Now with the BOSL2 thread_helix rounded higbees (as in my demo above), 3D printed threaded parts are working absolutely amazing. I have attached a closeup photo of the threads of a 3D printed cap/bottle pair using the same type of thread configuration that I put in my demo above. This photo shows the various artifacts that occurs with 3D printing threads, but also shows that my comments are based on full cycle design-print-use experiments.

I don't mind continuing to use the thread_helix, however, if it was removed, changed or if the only higbee option was the new flat one, I would have to use alternative threading library. None of the existing higbee options (other than thread_helix) are robust for actual physical parts in my opinion.

Also, I think that for many thread users, a default rounded higbee at the start and end of any thread with a default length of higbee=max(pitch/2, thread_depth) would give nice working threads by default (as in my previously posted example).

[adrianVmariano]

If there is a compelling argument that only thread_helix is good, then we should presumably eliminate the other code. But the argument that printing takes longer than openscad carries little weight when I'm waiting 5 minutes to preview my model in a design cycle. That time is time actively being annoyed by the wait, whereas printing time is while I'm asleep. And if I have 50 design cycles, where I'm waiting for preview, that's 250 minutes, which could compete with print time.

There is no plan to remove thread_helix, though I did change higbee to taper, since based on the patent reference, it's not a correct higbee.

If I changed higbee in regular threading to apply a ramp over 1/12 of a turn (what your formula gave for higbee length) would that produce a good result? Or you think the vertical taper is the key feature? That's definitely not higbee. It's the thread form used in plastic bottles.

[dr-occams-r]

I don’t know why you says “...it’s not a correct higbee…”? The previous thread_helix() higbee was exactly the ideal description in the patent: “...a Fig. 1, is a cylindrical extension of the internal diameter of the nut-thread between the thread end a and the bolt end a….”. It was in 1891, so they didn’t have computers, 3d modeling, precision machining, etc… so the patent described other alternatives, yours is similar to fig. 5. The general concept of the higbee is well known, and if theoretically possible, the thread should be rounded down equally from it’s profile to the center line.

To reiterate, thethread_helix() higbee as it was when I posted the above demo, was perfect. I have been saying that multiple times, not only in writing, but with demo code, screenshot and photo of a 3d print. I am spending time on this, trying to help, so I don’t understand why we got to this point of having a regression on the exact thing that I said was perfect?

I understand if thread_helix() is slower and you don't want to use that code for all threading, that is fine. I thought there would have been a way to use the rounded higbee start/end of the thread code from the thread_helix() without imposing the complete thread_helix() code into the full threading library. Seems like just a thread profile then arc sweep scale down to single flat point on the thread center-line, or simply arc down into the rod until the profile disappears. Thus additional computations at the two ends of the thread, not the whole length.

But if that can’t be done now, then that is ok. Keep thread_helix() with the rounded higbee as before, nothing to change. Then put a flat higbee on the general threading, and make that parameters compatible to work that same for an eventual rounded higbee. Meaning have higbee length parameters, straight flat taper for now, then upgrade to rounded later.

Threadlib does a partially rounded higbee, but not as clean and good as the previous thread_helix(). Also see three images below from threadlib, one if from the code below. https://github.com/adrianschlatter/threadlib https://github.com/adrianschlatter/threadlib/blob/develop/docs/imgs/bolt-M4.png

use <threadlib/threadlib.scad>
bolt("M4", turns=5, higbee_arc=75);

Other references, see images below, Unified Thread higbee from Machinery’s Handbook, screenshot closeup of higbee patent Fig. 1.

As additional feedback, the flat tapered higbee as now implemented in BOSL2, other than the 3D printing problems, also has the mechanical problem that if forced, it could be forces up the flat slope, the longer the slope, the easier the deformation, there is no leading off to each side to help the threads align. If it's a sharp triangle lead, than it can self-thread. If it's too flat, it can get damaged and widen by repeated knocking.

As for “...apply a ramp over 1/12 of a turn (what your formula gave for higbee length)…”, this is not the same as my proposed default higbee length. The turn or arc does not best determine the lead-in’s requirements, a large diameter rod with a small thread will have too long of a taper and a small rod with the large thread will have too short of a taper. It’s the thread depth that really what defines the higbee length needed as it is this thread depth that is being aligned. You don’t even need to look at the width, simply default the higbee length the be the same as the thread depth. Thus simply higbee=thread_depth is a good default for those want a higbee but don’t want to tune it further.

Assuming that BOSL and OpenSCAD are being used for functional parts (3D printing, CNC machining, etc.) I would definitely suggest working towards having all the threading functions provide the following for ease of use: -Ideal rounded higbee somewhat like the previous helix_thread() and threadlib.
-Default higbee on both ends -Default higbee length = thread depth -Option to extend the bolt/nut beyond the thread, or thread and bolt/nut length separate. The default thread length (centered) would be a pitch less than the straight bolt/nut length (like my example), but could be overridden. -Bevel, although not good in practice, you will probably always have someone asking for it and some specifications require it. Thus with the default extend bolt/nut beyond thread, the bevel will not be in the thread by default. But a user could adjust as desired to cut across the threads, or across higbee threads if they want.

Photo of bevel threads from Machinery's Handbook 30th edition. Thus some people will need/want it.

The bevel is simple compared to the thread, at worse, do the bevel as a separate rod/chamfer intersection with threaded part. Same for any other post-threading dressing up of parts.

By the way, the term taper and thread may lead to confusion as a tapered thread is an actual scaling down of the complete thread and cylinder. NPT National Pipe Tapered vs NPS National Pipe Straight https://en.wikipedia.org/wiki/National_pipe_thread

This is a whole other topic, because I have tried before to have truly tapered threads, with BOSL, other libraries and various transformations, and the only way was incredibly slow and brute force method of reassembling scaled slices of the thread. There is certainly a better way to do it. NPT, Self-Taping Screws and regular wood screws are common examples of tapered threads.

As for computing, OpenSCAD is known to be extremely inefficient, it is very possible that large speedups will come with time. The optimization techniques are known, just not implemented yet. They might be in development at the moment. You can increase your OpenSCAD cache sizes. You can upgrade your hardware. You can render on the cloud or on multiple computers. Hardware gets cheaper and faster every year. You can turn off automatic preview. You can put an option in your code to quickly switch between high and low resolution rendering for previewing, see my snippet of code below:

Smooth = false;
FragmentsSmooth = 50; // 5:1:1000
FragmentsRegular = 10; // 5:1:1000
fnCalc = Smooth ? FragmentsSmooth : FragmentsRegular;
$fn = fnCalc;

References for performance: OpenSCAD 3D rendering just got an order of magnitude faster. Here's how and what may come next. https://ochafik.com/jekyll/update/2022/02/09/openscad-fast-csg-contibution.html

Can anything be done about the rendering speed? https://github.com/openscad/openscad/issues/237

[adrianVmariano]

So an incomplete response to what you wrote because it's late:

1. You keep saying "the previous thread_helix". Did something change? I didn't think anything changed with thread_helix, except the name of the parameter and maybe there were some bugs fixed. You make a valid point that using "taper" could be confusing.
2. Does the tapered thread code in BOSL2 not produce properly formed threads? What's wrong with the NPT code in BOSL2? Why wouldn't you just use that? Or explicitly request tapered threads either with generic_threaded_rod or with thread_helix? Note that I have used the NPT code and my print seemed to mate with commercial NPT threads reasonably, though I didn't test e.g. if it sealed.
3. The code for threaded rod computes the entire screw as one polyhedron. The thread_helix code computes the screw as threads that have to be added onto a cylinder in a union operation, or added in after subtracting to make space. So it's a slower approach, I think. Also preview time is more important than render time, and as I recall, preview was faster for threaded rod.
4. The patent you quoted seemed to identify two characteristics that defined the patented threads. One was that they weren't cut off at the end, so the full width of the thread is present. This was what I thought was your main complaint about the old code. The second statement in the patent is that the threads have "a broad blunt face lying symmetrically on each centerline" and "substantially the same cross section as the thread". The current implementation of higbee with flat ends was specifically chosen to precisely match the patent! And by the patent's definition, the implementation in thread_helix where the threads narrow in width is not compliant with the patent, because the cross section isn't a broad blunt face with the same cross section as the thread. Now its entirely possible (and you seem to be saying) that this tapered thread form is BETTER than what the patent describes, but it seems to create uncertainty about naming. Maybe I could call in lead_in.

[dr-occams-r]

Higbee, higang, higarc is a good term for all parameters that modify the ends of the threads, regardless of if it’s full rounded or flat cutoff. A short rounded end is also blunt and symmetrical. The principle is blunt and symmetrical as opposed to sharp and asymmetrical edges of the thread created when the rod is cutoff straight or when the bevel goes through the thread. Anyone looking for such functionality will look for the term higbee, the concept is broad enough for a wide set of variations. Even for rounded higbee, higang would be the angle of a theoretical straight line from the end of the full thread to the point where the thread disappears.

The renamed parameter “taper” in thread_helix() leads to confusion with NPT tapered threads. Higbee was the correct term. Additionally npt_threaded_rod() has no parameter taper, so it furthers the confusion, and npt_threaded_rod() also doesn’t permit to create arbitrary “tapered smaller upwards” threads. I would avoid using the parameter “taper” for “higbee”. But let’s differ any discussion of npt_threaded_rod() to a separate issue if required to avoid confusion.

Why not just have one code for higbee, like in the previous thread_helix(), but adjust the fragmentation of the higbee to be closer to that of the thread? Meaning that if I set fragments low (eg $fn=5), like in the first example below, the higbee should be more like only three polygons (triangles), thus much closer to the flat higbee, this is what I would have expected from my settings. As fragments are higher, then smoother towards a full curved higbee. This should be code that is more consistent, easier to maintain and gives users a full variety of options, including computation time. The fragmentation of the higbee seems way too high relative to the thread and settings.

include <BOSL2/std.scad>
include <BOSL2/threading.scad>
thread_helix(d=10, pitch=2, thread_depth=0.75, flank_angle=15, turns=1, left_handed=true, taper=3, $fn=5);
down(5){
  thread_helix(d=10, pitch=2, thread_depth=0.75, flank_angle=15, turns=1, left_handed=true, taper=3, $fn=10);
}

down(10){
  thread_helix(d=10, pitch=2, thread_depth=0.75, flank_angle=15, turns=1, left_handed=true, taper=3, $fn=15);
}

down(15){
  thread_helix(d=10, pitch=2, thread_depth=0.75, flank_angle=15, turns=1, left_handed=true, taper=3, $fn=20);
}

Your commit Dec 15th Changed thread_helix()

adrianVmariano committed Dec 15, 2022
commit b4a31b82dee460edd22137dab9bfa2c120513bf1

spiral_sweep didn't actually do left handed when it was requested

changed higbee options to taper options, with negative for tapers
within specified length and positive for tapers extending the length

[dr-occams-r]

Maybe the confusion was with the word "blunt", you seem to take "blunt" to mean "flat", but it actually means "not sharp". Both "rounded" and "flat" are equally "blunt" (aka "not sharp").

https://www.merriam-webster.com/dictionary/blunt "...having an edge or point that is not sharp..."

https://www.britannica.com/dictionary/blunt "...having a thick edge or point : not sharp..."

[adrianVmariano]

On patent terminology, he states that it has the same cross section as the thread, which would appear to ban tapering, since then the cross section of a taper narrows, and hence is no longer the same. I don't want to get wrapped up in this terminology. The problem is I do not know anything about the subject. Presented with the patent, I tried to make the code compliant with what the patent said---and I got no feedback at the time about it. You evidently know a lot more about this topic, so I'm willing to accept your guidance about this.

The one downside of using the term "higbee" is that the 99+% of the rest of us have never heard of it, so it doesn't mean anything to the normal user. I also found it impossible to learn anything significant using google. That was why lead_in was appealing. But I can change "taper" back to "higbee" or something like that in thread_helix(). There probably needs to be some documentation in the manual about what higbee is all about, showing with and without, and explaining the benefits.

One other observation is that actual fabricated threads on plastic bottles often use an asymmetric "higbee" where it tapers in one direction, which clearly violates the symmetry requirement specified in the patent. I wasn't sure if it made sense to try to support this. In thread_helix() it's easy to apply other functions than the one currently used to define the exact shape of the taper. The one in there right now is something I concocted to look like threads I saw on actual SP400 bottles. It has no specific justification of being the "right" pattern.

In threaded rod, it is impossible to refine the fragments to a different size than the size used for the whole screw. In thread_helix() the higbee end section is refined by the hard coded tapersample parameter in spiral_sweep() in skin.scad. This fine refinement is what makes possible the smooth curved end that you like. You can experiment with changing it and see the effect on the end, but I think it needs to be pretty high if you want a really nice looking end. It's currently set to 10. I'm not sure why this is a problem, since it's just a short section at each end of the threads.

With regards to run time, the point is this: suppose you're making a 3 inch long 1/4-20 screw, so you have 60 threads to fabricate. With thread_helix() you first construct the threads and then you have to intersect them with a cylinder, so that's a lot of intersection to compute. With threaded_rod you compute one polyhedron and the only operation is to clip the ends to the right length. That's the situation where thread_helix is notably underperforming threaded_rod. If you have just one turn of threading, I don't think it matters.

Getting back to threaded_rod, I think I can revert the code for threaded_rod to the previous much more complicated method which applied the higbee over several fragments, and scaled in all directions. It sounds like you would consider that an improvement. But it can never produce as nice a rounded result as thread_helix because that oversampling is impossible.

Your diff that you showed of thread_helix() so far shows only bug fixes and the parameter name change. Note that actual thread construction happens in spiral_sweep() which is in skin.scad. I think fixing the bugs did require some pretty significant changes, but those changes should not have changed the thread form at all.

With regards to true tapering threads like with NPT, if you think there's a shortcoming there, open a new issue for that topic. Note that of COURSE there is no argument to control the tapering of NPT threads, because they have a fixed, specified taper required by the NPT standard, so no user face options to control. If you changed the taper angle of the threads, it wouldn't be NPT any more. But all the other threading code allows you to specify a taper by giving d1 and d2 for the threads that are produced, the same way you produce a conical cylinder by giving two diameters. So if there's something wrong there, or if the thread form isn't right, or if there is a way we should improve it, open another issue on that topic.

 trapezoidal_threaded_rod(d1=10,d2=7, l=17, pitch=2, higbee=true, $fn=32); 

[dr-occams-r]

OK: NPT and Tapered Threads, ok, thank you, makes sense. Also agreed, any issues would be separate.

OK: Performance thread_helix() vs *threaded*() family, understood and agreed on the reasons for performance difference. Further discussion of that would be a separate topic.

For the Higbee, this is a threading library and within that domain of engineering, there is extensive information on all things related to threads, and higbee is well known. For your convenience and for the convenience of the project documentation, here is a compilation of references and my comments/suggestions:

Terms: “Higbee”, “Higbee cut”, “Blunt Start”, “Blunt Start Thread”, “Convolution”, are all synonyms. They should all be mentioned in the documentation, but Higbee is clear and distinctive, see further references below for justification.

Parameter name suggestion: higbee (length), higang, higarc would seem best. I would suggest providing all three types of parameters and specific the priority of override if more than one is specified, or give an error. Use these parameters consistently everywhere, although resulting meshes might be a bit difference for performance reasons as you mentioned.

Blunt = NOT sharp. One cut/face is less sharp that the raw edge, but cutting down each new sharpest edge makes it more blunt (less sharp). Thus, the ultimate “Blunt” or “NOT Sharp” is a smoothly rounded shape, thus a mesh of infinite polygons. So anything between one flat cut to infinitely smooth is a “higbee” / “blunt start thread”.

Problems using the following terms (see references below): -Convolution – Not often used and has other meanings -Blunt Start Thread – Long and could be confused with Blunting of other parts and with "Blunt Point", see references below. -Taper – Also multiple meanings, see references below.

Higbee cut - Wikipedia https://en.wikipedia.org/wiki/Higbee_cut

Higbee Patent https://patents.google.com/patent/US447775A

Threalib Thread library for OpenSCAD – Github https://github.com/adrianschlatter/threadlib Threalib thread() functions uses parameter higbee_arc= See screenshot and image below.

Machinery’s Handbook 30th Edition, pages 1860-1861 “Blunt Start Thread: “Blunt start” designates the removal of the incomplete thread at the starting end of the thread. This is a feature of threaded parts that are repeatedly assembled by hand, such as hose couplings and thread plug gauges, to prevent cutting of hands and crossing of threads. It was formerly known as Higbee cut.”

See screenshot below.

Machinery’s Handbook 30th Edition, pages 1767-1767

Blunt Points, Tapers, see two screenshots below.

ASME B1.7 — 2006 https://rathasochenda.com/wp-content/uploads/2020/04/ASME-B1.7-2006.pdf

Thread Check Inc. https://www.threadcheck.com/technical-documents/Custom-Threads-Terms-and-Definitions.pdf “Convolution — Removal of the incomplete thread back to the first full thread. Also known as a “Blunt Start” or “Higbee Cut” per ASME B1.7 — 2006”

“Blunt Point —The removal of a male center point from threads smaller than # 6 (M4). This does not allow the gage to be face ground to within .5P. This is not a Blunt Start. See Convolution below.”

Thomas - Screw Thread Systems - Types, Terminology and Dimensions https://www.thomasnet.com/articles/machinery-tools-supplies/screw-thread-systems-types-terminology-and-dimensions/

“Higbee Cut: See Blunt Start Thread.”

Blunt Start Thread: “Blunt start” designates the removal of the incomplete thread at the starting end of the thread. This is a feature of threaded parts that are repeatedly assembled by hand, such as hose couplings and thread plug gages, to prevent cutting of hands and crossing of threads. It was formerly known as a Higbee cut.

[adrianVmariano]

The various references really focus on avoiding incomplete thread, and don't say anything about the geometry of the "blunt" end that terminates the thread. I understand that among thread experts, this terminology may be well known, and so it's not unreasonable to use it in a threading library. But also, almost none of the users will be thread experts. They nevertheless wish to make some threads, so that creates a kind of conflict. I did also notice that the references all say "formerly" with regards to the term "higbee".

What is the difference between higang and higarc in your proposal?

It seems like there are actually two parameters to fiddle with:

1. How long is the lead-in section, the part that tapers down from full thread to nothing
2. Where exactly does the threading end? In the threaded_rod code I found I had a lot of trouble with a robust answer to this question, even though it seems like it should be simple. So in that code, the higbee parameter controls where the cut occurs so you can adjust it if necessary. I'm not sure if there's a way to avoid this second parameter. Part of the problem is that for an unknown thread profile, you don't know what the profile is doing, so you can't measure with respect to references points on the threads.

Can you tell me why crossthreading happens? Or maybe more basically, what crossthreading actually is? I'm not sure I really understand the failure mode here. Like if I wanted to show a picture in the manual of a screw entering a nut crossthreaded, how would I do that?

[adrianVmariano]

The references repeatedly say that higbee is particularly used when the screw will be unfastened and refastened repeatedly. Why is that? Just simply that you have more chances to screw up if you're doing it a lot? Or is there something else going on?

[adrianVmariano]

I have managed to translate the higbee approach from thread_helix into generic_threaded_rod, so it uses the same higbee geometry.

So then what needs to be nailed down is a good interface. You previously mentioned things like higarc, higang, and so on. Assuming I change taper back to higbee in thread_helix, then higbee is a parameter that specifies low long the higbee section is as a linear distance. Based on what you've said, this is the natural way to do it. (Certainly when I wrote code for SP400 bottle threading it seemed like that was the natural approach.)

You suggested that the default should be max(pitch/2,thread_depth). Using that as the higbee length I get:

If I increase $fn to 128 I get this:

Are those what you would consider perfect higbee?

If I quadruple the length I get this:

The other higbee parameter is the one that determines where, exactly, the thread is cut. Right now the "higbee" parameter is doing this, but that is inconsistent with thread_helix. So I can introduce a new parameter, perhaps thread_end, that adjusts the amount of thread by an angle.

[adrianVmariano]

I'm going to say that the latest round of updates fix this issue.