I have posted my explanation here:
https://github.com/sprabhakar2006/openSCAD/blob/main/explanation%20of%20approaches/explanation%20hirth%20coupling.pdf

because the file size became 1.5 mb

On Mon, 4 Nov 2024 at 07:38, Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:

And the YouTube video is here in case anyone is interested :
https://youtu.be/Wp8q71eMqrE?si=fY1AxbXp8itbZRm7

On Mon, 4 Nov 2024, 08:10 Sanjeev Prabhakar, sprabhakar2006@gmail.com
wrote:

A lot of discussion but it doesn't look like a useful coupling to me as it
will always try to force itself apart. Wouldn't straight sided teeth with a
chamfer to aid initial engagement be better.

On Mon, 4 Nov 2024 at 02:47, Sanjeev Prabhakar via Discuss <
discuss@lists.openscad.org> wrote:

I think the point is that it wedges together with good alignment and no
slop. Square teeth would need a clearance gap and then there would be
backlash.

On Mon, Nov 4, 2024 at 04:49 nop head via Discuss <
discuss@lists.openscad.org> wrote:

@nop head nop.head@gmail.com
, these type of joints are typically loaded, so they cannot just pop off.

Another take on the theme, if someone develops a profile they like on one
side, they should be able to use a geometrical diff operation to form the
mating surface without slop. That said, the profile has to be symmetric to
accommodate the adjustment.

Hope this helps.

On Mon, Nov 4, 2024 at 8:24 AM Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:

Hi Adrian,

the rounding of the valleys is a manufacturing requirement, (couldn't
get long lasting grinding disks with sharp corners) the flat tops to the
crests, is so they don't bottom out.

The initial code I submitted worked fine with the parameters I gave, but
no others.

My second, version, which I used to generate the images, worked fine as
parametric, but I have not been on line for a day or so, and I am
reconstructing that code, having not saved it, and it seems file history
is not working.

If you can generate bevel gears, then you should be able to make Curvic
couplings.

On 04/11/2024 02:07, Adrian Mariano via Discuss wrote:

@Raymond West raywest@raywest.com, actually, I think the rounded corners
is generally an engineering requirement.  Sharp edges are stress-risers,
causing cracks and breaks.  That said, not having to grinding into a
sharp corner makes things a LOT easier ;-)

On Mon, Nov 4, 2024 at 11:41 AM Raymond West via Discuss <
discuss@lists.openscad.org> wrote:

found it-

// clutch.scad

ind = 50;  // overall diameter
num = 46;  // number of teeth
back = 5; //thickness of back
bore = 8.3; // diameter of hole
recess = 30;// diameter of recess in centre
////////////////////////////////////////////

diam  = ind/cos (180/num);
chord = diam*sin(180/num);

ridge= chord sqrt(3)/4;  // or set to whatever
// Basic parameters
radius = diam / 2;
angle_per_tooth = 360 / num;
yp =radius * tan(angle_per_tooth / 2);
rp = sqrt((ypyp)+(radius*radius)); //radius to point

points = [
    [0, 0, ridge / 2],    // Center
    [radius, -yp, 0],     // Left base
    [radius, yp, 0],      // Right base
    [radius , 0, ridge]   // Peak of the ridge
];

 faces=[
 [0,1,2],
 [0,1,3],
 [0,2,3],
 [1,2,3]
 ];

 module wedge(){
   polyhedron(points,faces,convexity=10);
 }

 //rotate wedge
 module clutch(){

 difference(){
 intersection(){
     translate([0,0,-back])
       cylinder(d=ind,h=200,$fn=100);
        union(){
             for (j=[0:1:num-1])
              rotate([0,0,j360/num]) wedge();
                      rotate([0,0,180/num])
                    cylinder(r1=rp,r2=0,h=ridge/2,$fn=num);
                    translate([0,0,-back])
                     cylinder(d=diam,h=back,$fn=num);
     }
 }
   cylinder(d=recess,h=ridge3);
   translate([0,0,-back-ridge])
   cylinder (d=bore,h=(back+ridge)*3);

 }
 }
 $fn=100;
 clutch();

 /*
 translate([50,0,0])
// rotate([0,180,360/(num*2)])
 import("P:/Docs/openscad/clutch.stl");

cube(ind,true);

 */

On 04/11/2024 16:41, Raymond West via Discuss wrote:

You have a steeper angle, and higher tension on the centre fixing to
improve grip, I guess. The idea of the tapered sides is for ease of
manufacturing. To get vertical sides, then it would involve more passes
of the grinding wheel/mill. With a 'V' shape, you get more strength at
the root, compared to square, (acme thread is stronger than square, plus
can use a split nut - not relevant in this case).

On 04/11/2024 09:48, nop head via Discuss wrote:

I had been using spherical coordinates and that made it very easy to construct the part using only the 3 angles, groove angle, ridge angle and tooth angle (radial between teeth). Since I have been specifying the chamfer as a percentage of the tooth height, I realized that finding the angles for the chamfers was easy too since everything is proportional including the angles.

The final realization I had though is that normal spherical coordinates did not produce quite the right result as the radii I know are the inner and outer ones. These lie on a cylinder not a sphere. I looked into cylinder_to_xyz in BOSL2 and found that it uses (r, theta, z), spherical uses (r, theta, phi). I needed something else. I created sperical2_to_xyz(r, theta, phi). This is the same as spherical but r is the radius in the XY plane, not in XYZ. It was quite easy to alter the spherical_to_xyz code to get what I wanted.

Here is just a code fragment but it gets the point across.

IR = _ir(hs);
OR = _or(hs) / cos(180/_n(hs)); // OR is the radius of the circumscribing polygon of N

// Ridge Chamfer
thetaCA2 = _toothAngle(hs) * _chamfer(hs)/200;
phiCA   =  (_grooveAngle(hs) -_ridgeAngle(hs)) * _chamfer(hs)/100;

function profileToooth(r) =
     [spherical2_to_xyz(r,  thetaCA2,          _ridgeAngle(hs) + phiCA),
      spherical2_to_xyz(r,  _toothAngle(hs)/2, _grooveAngle(hs)),
      spherical2_to_xyz(r, -_toothAngle(hs)/2, _grooveAngle(hs)),
      spherical2_to_xyz(r, - thetaCA2,         _ridgeAngle(hs) + phiCA)
      ];

It works down to N = 3 and could work for N = 2 if the profile were changed to a half tooth. I used skin at first but that breaks down at low tooth counts. I also found that using the tooth profile to produce the groove chamfer didn’t work very well with skin or hull, so I now do that as part of adding the base. I’ll post more complete code soon as I can.

-Bob



I've modified it slightly, to allow the tooth angle to be set - In
manufacturing, most likely a 60 or 90 degree angle. I've also included
the angle to set the rotary table, and added a method of flattening the
tips. I think this could 3d printed OK, I've yet to test. The stl would
not be used in any other manufacturing process, afaik. For machining, It
could be set up directly from the parameters. I've attached the code
below. The flattening of the peaks give a slight taper. Adding an extra
triangle to the polyhedron, could generate a more tapered width to the
flat top, but for whatever use I may put this too, if any, it is
unlikely to make much difference.

The code will produce a viable stl, for any number of teeth, including
three and upwards, and it f6 renders fast enough.

Here is a link to some curvic coupling design, which is a bit more
involved to generate -
https://www.geartechnology.com/articles/20867-curvic-coupling-design.

On 04/11/2024 17:05, Raymond West via Discuss wrote:

Ray, I tried your code and (1) preview is very very slow on my machine and
(2) render gives

Rendering Polygon Mesh using CGAL...

ERROR: The given mesh is not closed! Unable to convert to
CGAL_Nef_Polyhedron.

ERROR: The given mesh is not closed! Unable to convert to
CGAL_Nef_Polyhedron.

ERROR: The given mesh is not closed! Unable to convert to
CGAL_Nef_Polyhedron.

ERROR: The given mesh is not closed! Unable to convert to
CGAL_Nef_Polyhedron.

ERROR: The given mesh is not closed! Unable to convert to
CGAL_Nef_Polyhedron.

Geometries in cache: 9903

I'm now convinced that Bob has the right basic approach. The key thing is
the idea of projecting onto a cylinder. Working in spherical coordinates
never made sense to me, but for some reason the idea of just projecting
points onto a cylinder didn't occur to me. (At one point I thought about
doing it, but with equations, not with code, which was a bad idea.) With
this insight I can now make roundings while creating the object as a single
polyhedron:

[image: image.png]

On Tue, Nov 5, 2024 at 12:54 PM Raymond West via Discuss <
discuss@lists.openscad.org> wrote:

I tried it on mine- I'm using version 2024.10.2 git e972ed84e.
F5 takes 0.059 seconds, f6 0.096 seconds.
I get-

"WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh.."

four times, then it continues to render with no further errors. I have just finished printing two of them so I can have a play.

On 2024-11-06 09:27, Adrian Mariano via Discuss wrote:

--
Cheers, Ken
bats059@gmail.com
https://vk7krj.com
https://vk7krj.com/running.html

A baby can be defined as an ego with a noise at one end and a smell at the other.
Your job as parents is to teach them to control all three.
My job as a grandad is to tell you how you are doing it all wrong!

Hi Ray
I tried your code and it is almost instant render and there are no issues
in the manifold which I use during f6 render. There are some warnings but
that's fine

On Tue, 5 Nov 2024 at 23:24, Raymond West via Discuss <
discuss@lists.openscad.org> wrote:

I have established that there is an error in the code fragment. The line

Is where the error lies. What should it be? I was assuming that the theta for the chamfer “shoulder” point would be proportional to the chamfer but it produces a slight error. It is barely noticeable but gets more blatant at low tooth counts and high conic.

Anyone see what it should be? I’m guessing there is some trig functions involved,but ...

-Bob

Bob, I did I think exactly the same thing in my code and didn't notice
anything, but now that you mention it, doing chamfers on an angular basis
is of course not going to match doing them on a linear basis.  So that
means the geometry changes a bit if you change the chamfer size.  This
isn't necessarily catastrophic, but is a little unexpected, I suppose.
Generally speaking you can't mate two parts produced with different chamfer
size anyway, so I'm not sure this is crucial to get right.  But in order to
get it right, I think both thetaCA2 and phiCA are going to need to be
computed with trig---either that or there's some complicated way of
computing just one.  The question is whether these two parameters can be
computed independently or are they related in some complicated way.
Treated as a 2d problem you are trying to get the angle that corresponds to
a fraction of a chord of the circle, which is a reasonably straight forward
triangle calculation.  I got atan(chamfer*tan(angle)) where angle is
180/tooth_count for the ridge chamfer.  But the chamfered one still doesn't
align with the unchamfered.  For example:

[image: image.png]

Yellow is unchamfered.  Blue has huge chamfer applied only at ridge (and
slightly larger radius so we can see it clearly).  And we see that the
angle has changed.  I actually got less error with the original
calculation, but that might be because I didn't correct the phi angle only
the theta angle.  (Or maybe I botched the trig.)  So I tried computing a
correction for phi and got ridge_angle-atan(ridge_angle -
chamfer*(tan(ridge_angle)-tan(valley_angle))), but still things don't line
up correctly.  (And the horizontal correction is still worse than not,
which makes me wonder if the horizontal correction needs to take into
account the vertical position of the chamfer somehow.)  Doing the phi
correction alone actually is an improvement over no correction.

Here's my current code (without any chamfer corrections).  It does rounding
and skew teeth.

module hirth(n, ir, or, id, od, tooth_angle=60, cone_angle=0, chamfer,
rounding, base=1, crop=false,skew=0, rot=false, orient,anchor,spin)
{
ir = get_radius(r=ir,d=id);
or = get_radius(r=or,d=od);
dummy = assert(all_positive([ir]), "ir/id must be a positive value")
assert(all_positive([or]), "or/od must be a positive value")
assert(is_int(n) && n>1, "n must be an integer larger than 1")
assert(is_finite(skew) && abs(skew)<=1, "skew must be a number
between -1 and 1")
assert(ir<or, "inside radius (ir/id) must be smaller than outside
radius (or/od)")
assert(all_positive([tooth_angle]) && tooth_angle<360*(n-1)/2/n,
str("tooth angle must be between 0 and ",360*(n-1)/2/n," for spline with
",n," teeth."))
assert(num_defined([chamfer,rounding]) <=1, "Cannot define both
chamfer and rounding")
assert(is_undef(chamfer) || all_nonnegative([chamfer]) &&
chamfer<1/2, "chamfer must be a non-negative value smaller than 1/2")
assert(is_undef(rounding) || all_nonnegative([rounding]) &&
rounding<1/2, "rounding must be a non-negative value smaller than 1/2")
assert(all_positive([base]), "base must be a positive value") ;
tooth_height = sin(180/n) / tan(tooth_angle/2);    // Normalized tooth
height
cone_height = -tan(cone_angle);                        // Normalized
height change corresponding to the cone angle
ridge_angle = atan(tooth_height/2 + cone_height);
valley_angle = atan(-tooth_height/2 + cone_height);
angle = 180/n;    // Half the angle occupied by each tooth going around
the circle

factor = crop ? 3 : 1;  // Make it oversized when crop is true

profile = is_undef(rounding) || rounding==0 ?
let(
chamfer=default(chamfer,0),
vchamf = chamfer*(ridge_angle-valley_angle),
pts = [
[-angle*(1-chamfer/2), valley_angle+vchamf/2],
[-anglechamfer, ridge_angle-vchamf]
],
full = deduplicate(concat(pts, reverse(xflip(pts))))
)
back(valley_angle,
skew(sxy=skewangle/(ridge_angle-valley_angle),fwd(valley_angle,full)))
: let(
vround=rounding*(ridge_angle-valley_angle),
profpts = [
[  -angle, valley_angle+vround/2],
[  -angle*(1-rounding/2),
valley_angle+vround/2],
[  -anglerounding, ridge_angle-vround],
],
segs = max(16,segs(orrounding)),
full = concat(profpts, reverse(xflip(profpts))),
skewed = back(valley_angle,
skew(sxy=skew*angle/(ridge_angle-valley_angle),fwd(valley_angle,full))),
// Using computed values for the joints
lead to round-off error issues
joints = [(skewed[1]-skewed[0]).x,
(skewed[3]-skewed[2]).x/2,
(skewed[3]-skewed[2]).x/2,(skewed[5]-skewed[4]).x ],
roundpts = round_corners(skewed, joint=joints,
closed=false,$fn=segs)
)
roundpts;

// project spherical coordinate point onto cylinder of radius r
cyl_proj = function (r,theta_phi)
[for(pt=theta_phi)
let(xyz = spherical_to_xyz(1,pt[0], 90-pt[1]))
r * xyz / norm(point2d(xyz))];

bottom =
min([tan(valley_angle)ir,tan(valley_angle)or])-base-cone_heightir;
safebottom =
min([tan(valley_angle)ir/factor,tan(valley_angle)orfactor])-base-(crop?1:0)-cone_heightir;
ang_ofs = !rot ? -skewangle
:  n%2==0 ? -(angle-skewangle)  - skewangle
:  -angle*(2-skew)-skewangle;
topinner = down(cone_heightir,[for(ang=lerpn(0,360,n,endpoint=false))
each
zrot(ang+ang_ofs,cyl_proj(ir/factor,profile))]);
topouter = down(cone_heightir,[for(ang=lerpn(0,360,n,endpoint=false))
each
zrot(ang+ang_ofs,cyl_proj(factoror,profile))]);
botinner = [for(val=topinner) [val.x,val.y,safebottom]];
botouter = [for(val=topouter) [val.x,val.y,safebottom]];
vert = [topouter, topinner, botinner, botouter];

anchors = [
named_anchor("teeth_bot", [0,0,bottom], DOWN)
];
attachable(anchor=anchor,spin=spin,orient=orient, r=or,
h=-2*bottom,anchors=anchors){
intersection(){
vnf_polyhedron(vnf_vertex_array(vert, reverse=true, col_wrap=true,
row_wrap=true),convexity=min(10,n));
if (crop)

zmove(bottom)tube(or=or,ir=ir,height=4*or,anchor=BOT,$fa=1,$fs=1);
}
children();
}
}

On Wed, Nov 6, 2024 at 7:55 PM Bob Carlson via Discuss <
discuss@lists.openscad.org> wrote:

I don't think the straight projection on cylinder will work.
The only way I think this can work is if you project using vectors
considering outer race and inner race, projecting outwards and inwards
respectively on outer and inner cylinder.
picture below can make this clear.
magenta lines are the vectors
[image: Screenshot 2024-11-07 at 9.49.27 AM.png]
[image: Screenshot 2024-11-07 at 9.53.29 AM.png]

On Thu, 7 Nov, 2024, 8:12 am Adrian Mariano via Discuss, <
discuss@lists.openscad.org> wrote:

this is the final version (attached is the scad file)
[image: Screenshot 2024-11-07 at 10.26.12 AM.png]

On Thu, 7 Nov 2024 at 09:54, Sanjeev Prabhakar sprabhakar2006@gmail.com
wrote:

very nice!  Thank you for sharing ;-)

On Wed, Nov 6, 2024 at 11:59 PM Sanjeev Prabhakar via Discuss <
discuss@lists.openscad.org> wrote:

I do not understand the pictures.  Or at least the top one is mystifying.
The bottom one looks like it could describe the process: the projection is
along vectors that originate at the origin and yes, you have a separate
projection onto the inner and outer cylinder.

On Wed, Nov 6, 2024 at 11:24 PM Sanjeev Prabhakar sprabhakar2006@gmail.com
wrote:

All the magenta lines are vectors, you can think of them originating from
any side of the line.

Each line intersects a circumscribing cylinder outer or inner and that
forms the circular hirth coupling.

On Thu, 7 Nov, 2024, 4:40 pm Adrian Mariano, avm4@cornell.edu wrote:

Thanks David
That book you share is good,  but it is taking some time to absorb

On Thu, 7 Nov, 2024, 11:53 am John David, ebo.2112@gmail.com wrote:

In the to picture, there is no cylinder pictured, but some complicated
shape with multiple curves, some of which are not even circular arcs.  So I
don't understand that picture.  You can try the code I posted earlier,
which uses the cylinder projection approach.

On Thu, Nov 7, 2024 at 6:23 AM Sanjeev Prabhakar sprabhakar2006@gmail.com
wrote:

Hi Sanjeev,

Thanks for testing it, I get no warnings or errors, unless i use less
than three ridges, or other  inappropriate values. I'm guessing it's an
openscad version difference. I think my geometry is good enough for me,
but probably not bullet proof.

On 06/11/2024 02:21, Sanjeev Prabhakar via Discuss wrote:

Hi Ken,

Thanks for testing, I get no errors with  OpenSCAD version 2024.02.19
(git 5cfd4dbe0), but it may be other reasons. I think my geometry is
good enough with reasonable parameters. However, I expect there is the
usual z fighting taking place, since the various parts probably do not
overlap sufficiently in some cases. I expect, using cadquery (which uses
a different rendering engine) the geometry may work with different errors.

On 05/11/2024 23:32, Ken via Discuss wrote:

Yes sure It works and that's what matters. anyways it's not a fatal error

On Thu, 7 Nov 2024 at 18:03, Raymond West via Discuss <
discuss@lists.openscad.org> wrote:

All errors are fatal when you run with the stop on first warning feature,
which is generally necessary to avoid overwhelming useless cascading error
messages.

Under the stable openscad that I used the model fails to render using the
code exactly as posted. This is because it contains some reversed faces
that can be seen with thrown together. I didn’t know that manifold would
fix those with a warning. I generally prefer to use polyhedron creation
tools to make fully valid face sets.

Even after fixing that problem something else is wrong because I get the
message that the object may not be a valid 2-manifold. I don’t know what
the other problem is. Maybe it’s because wedges touch at their edges?

The problem of sluggish preview also remains.

On Thu, Nov 7, 2024 at 09:19 Sanjeev Prabhakar via Discuss <
discuss@lists.openscad.org> wrote:

I think that to get this right you basically need to take the top point of
the triangle and one of the bottom points of the triangle in their position
projected onto the cylinder, represent in cartesian coordinates, then
interpolate appropriately between them by the chamfer fraction, then
convert back to spherical coordinates to extract the angles.  You can work
through those steps to get some complicated formula, but it looked messy.
I couldn't think of any simpler approach.

On Wed, Nov 6, 2024 at 7:55 PM Bob Carlson via Discuss <
discuss@lists.openscad.org> wrote:

That sounds promising. I tried a lot of stuff but not that and nothing worked quite right. I’ve tweaked my code now to make the chamfer by subtracting later. It’s quite easy. The other thing I did is make 2 half tooth profiles instead of one whole. Now N = 2 works. I also found that skin() did not work at low tooth counts and had to use a combination of skin and hull. If two profiles are very different sizes and far apart, that seemed to be the problem area. I use skin to make thin wafers then hull the wafers together. I suppose some schemes where I generate many profiles close together would work too.

Maybe after I finish this version I’m make one more trial of your idea.

-Bob

I implemented the method I suggested. It was pretty easy to do and works.
I do not understand your problem with skin.  How does it fail?  I construct
mine using vnf_vertex_array which is like skin without fancy point
alignment, and have no issues.  It shouldn’t matter how far apart the
profiles are or how different the scale. Skin just connects the points you
give it to make the polyhedron.

I do have a problem with rounding. The rounding isn’t at the right angle
which leads to a corner where it joins the

I thought the 2 tooth case was working for me but more thorough
investigation revealed problems in the case of skewed teeth. I’ll have to
ponder that.

On Fri, Nov 8, 2024 at 11:39 Bob Carlson bob@rjcarlson.com wrote:

I’ve attached my code that I now believe is debugged and working reliably. It supports all the way down to N=2 (teeth). Depending on N it renders in .25 to .5 s. Preview is similar.

When N = 2 or 3 this is an edge condition that required a lot of testing and work. The other area that caused the most problems was when the “coned” argument was at or around half the tooth height (as measured at the outer radius.) Around this point any auxiliary shapes you use to add a base, add or subtract a chamfer etc, switch from concave to convex or vice versa.

One file is Customizer enabled and serves as the test platform for the second file where all the working code is. The test file also includes some visualization aids that I wrote to help see exactly what is going on.

A note about the anchors. They are all relative to the entire joint. This makes it easier to position both parts in a larger assembly in a way that insures the parts mesh exactly.

-Bob







I forgot something. In _profileU(hs) there is code documented out that causes problems with skin. They show up in the tricky areas like N = 2 and coned = toothHeight/2.

-Bob

If you want to identify a specific case for reproducing a problem with
skin() I can take a look at it, but I couldn't find anything obviously
wrong in a brief bit of fiddling with parameters.

It's interesting how rather different our hirth joints can look for similar
parameters.  For 2 teeth, with no cone angle/distance they are pretty
similar:

[image: image.png]
but with an extreme cone setting (I was trying to set it to the tooth
height to create the problem you described) they are rather different:

[image: image.png]
Note that mine are symmetric in that a single module produces both halves
and you specify conical with an angle, and then use the negative angle to
make the mate.

On Thu, Nov 14, 2024 at 6:35 PM Bob Carlson bob@rjcarlson.com wrote:

Hi Bob
At the trough it should be a fillet rather than chamfer. On the crest it
should be chamfer.

On Fri, 15 Nov, 2024, 4:56 am Bob Carlson via Discuss, <
discuss@lists.openscad.org> wrote:

That’s an interesting exercise. I am playing with another strategy to produce the chamfers that will produce a flat chamfer. My current algorithm produces one that is follows the surface of a cone. Unnoticeable at normal tooth counts, but you can see it with very low tooth counts. I’ll generate some pics of the skin issue, but it won’t be till late today.

Sanjay, you are no doubt correct that the groove should be a fillet, I have no ME background at all. But it seems very difficult to produce. I played around with the math to inscribe a circle into an angle at a specific tangent point, but got tired of the exercise before I solved it. I suspect you can do that off the top of your head. Somewhat arbitrarily I chose to make the groove chamfer 50% of the ridge chamfer. Is there another ratio that is accepted or preferred?

-Bob

I am not sure how you have modeled this but the main point here is that the
teeth should not foul while meshing, if that is not the case in your design
then it should be fine.

On Fri, 15 Nov, 2024, 10:00 pm Bob Carlson via Discuss, <
discuss@lists.openscad.org> wrote:

It turns out that in the previous version I was calculating the phi angle for the chamfers incorrectly, another place where my math intuition failed me. This code gets it right I think. Look for phiCA in hirth.6.. Phi in spherical coordinates is from vertical and I am sometimes using phiCA from the XY plane instead, so -90. So watch out.

-Bob



I think it's tough to tell what the angles are in the fixed view like that
due to the distortion from perspective.  In my code the triangles that form
the teeth are constructed with the specified angle, but then they end up
getting projected at a different angle depending on the cone angle you
pick.  Furthermore, there's the question of where the angle is measured.  I
think the wikipedia page suggested it is measured relative to the cylinder
axis, but I'd normally expect tooth angle to be measured on the tooth,
which means the slope of the tooth will also lead to a change in the
effective angle.  (Maybe this factor is what you're talking about?)  I
decided for my implementation to treat the requested angle as "nominal" and
not worry about these various deviations.  As long as you pick the same
angle (and other parameters) for both sides of the joint, the parts will
mate.  And if you don't like the angle you get---change it.

On Sun, Nov 17, 2024 at 12:15 AM Caddiy via Discuss <
discuss@lists.openscad.org> wrote:

Adrian Mariano wrote:

Immediately after posting, I thought I should have simply said that the angle between the flanks of a spline viewed perpendicular to the axis of the ring of splines is not the same as the angle around the ridge of the spline = on the tooth. So your guess was right. I too would think that the angle on the tooth would be what counts in practise. Unfortunately, Wikipedia is not very clear on that. I wonder what our resident engineer/machinist would say. Or maybe it’s actually the angle of the cutting tool - that would be the angle between the flanks of adjacent splines? Then only one tool would be needed.

Could be of interest for BOSL, as 60° and 90° seem to be the standard angles, so it would be good to know how/where they are measured. With increasing numbers of splines, the discrepancy between the two frames of reference rapidly decreases.

I have a concept that seems promising, but doing the trigonometry is like trying to swing from tree to tree in a dense jungle in a fog, so I have given up for the time being.

I did ponder the idea of trying to compute a correction factor to the tooth
angle, but given the uncertainty about what the right angle actually is,
and also uncertainty on my part about how to actually compute that
correction factor, I didn't pursue this idea.  Wouldn't angle between
adjacent flanks be equivalent to angle on the tooth, which is basically the
other angle between flanks?  In the case of no cone angle these angles
must be the same because the part mates with itself.

Another thing is that my code supports skewing the teeth so you can make
teeth with one face vertical, for example.  This distorts the angle.  I
didn't see a compelling reason the angle needs to be "correct".  Here an
example of what you get if you ask for 60 degrees with maximal skew:

[image: image.png]
If I change the tooth angle to try to achieve actual 60 deg at the tops I
get something like this

[image: image.png]
Note that the tooth height has radically changed.  From a design
perspective, I think it's maybe nicer for a user to be able to skew the
teeth while keeping the tooth height fixed, rather than having these
parameters coupled.

In the case of very high cone angle (here 75 deg), weird stuff happens and
I get shapes like this:

[image: image.png]
where the adjacent teeth flanks become coplanar, and then if I push cone
angle higher (85 deg here) the "valley" between the teeth becomes a second
ridge

[image: image.png]
It's not clear if forms like this are useful for anything.  The
construction still works, producing a mating shape that looks like this:

[image: image.png]
But clearly the tooth angle measured at the tooth ridge or the complement
of the angle between the flanks is wildly different from the requested 60
deg.  I'll note also that the very high cone angles look less weird when
the tooth count is high, though the tooth angle is still wildly different
from what was requested.  This is 75 deg angle with lots of teeth:

[image: image.png]
I'm not going to show another image, but if I line it up along a ridge by
eye the tooth ridge angle looks like around 120 deg.  But note how the
triangles running around the baes actually look like 60 deg triangles.

On Sun, Nov 17, 2024 at 2:38 AM Caddiy via Discuss <
discuss@lists.openscad.org> wrote:

søn. 17. nov. 2024 14.17 skrev Adrian Mariano via Discuss <
discuss@lists.openscad.org>:

søn. 17. nov. 2024 14.22 skrev Michael Möller private2michael@gmail.com:

with 75 deg tooth angle 10 deg cone angle
[image: Screenshot 2024-11-17 at 7.03.48 PM.png]

with 80 deg tooth angle and 10 deg cone angle (lot of distortion)

[image: Screenshot 2024-11-17 at 7.11.04 PM.png]

On Sun, 17 Nov 2024 at 18:47, Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:

Sanjeev, your definition of cone angle is not the same as mine, it would
appear.  I measure cone angle by the line through the center of the
triangle so a zero cone angle is when the mating parts are identical, which
I consider to be the standard joint configuration.  Two parts will mate if
their cone angles are the opposite sign with my approach.

So 60 deg tooth angle, 0 deg cone angle:

[image: image.png]

And the case of 50 teeth, 40 deg cone angle, 75 deg tooth angle for me is
this:

[image: image.png]
Are you constructing your model so that the 75 deg angle is achieved as
measured on the tooth ridge?

On Sun, Nov 17, 2024 at 9:06 AM Sanjeev Prabhakar sprabhakar2006@gmail.com
wrote:

I think the tooth angle is the angle which one side of the tooth makes with
x-y plane
I will check that once again

On Sun, 17 Nov, 2024, 7:52 pm Adrian Mariano, avm4@cornell.edu wrote:

Sanjeev, I didn't see that you stated what your definition of "cone angle"
is.  In my case, it's not an angle you can easily see in the model, since
it is through the CENTER of the tooth.  And yes, the deviation I was
describing with cone angle in my model is due to the effect of compound
angles, that is, if you measure tooth angle as angle between the planes of
the tooth then that changes with rising cone angle because of the compound
angle effect.

Why is 32.5 degrees a magical cone angle for your model?

On Sun, Nov 17, 2024 at 11:13 AM Sanjeev Prabhakar sprabhakar2006@gmail.com
wrote:

Oh I think the explanation I sent earlier had some pictures which exceeded
the acceptable size for mails here and did not reach anyone.

The angle tooth makes with x-y plane is the angle of the tooth.

32.5 is only for the case where tooth angle is 80 degree, number of teeth
are 50 and cone angle if set to 32.5.

For different configurations this might change.

Also I did not try to measure the angle if tooth face is intersected by a
vertical plane perpendicular to tooth line joining the inner and outer
points.

Maybe that would be correct angle. But I am not sure

On Sun, 17 Nov, 2024, 9:57 pm Adrian Mariano, avm4@cornell.edu wrote:

Afaik, The Hirth joint was invented in 1928, and was very simple to
manufacture, with the machinery available at the time. I'm pretty sure,
that none of the detail On Hirth Ring Couplings: Design Principles
Including the Effect of Friction https://www.mdpi.com/2076-0825/7/4/79
for example, was known. I'm not sure why it is being made so complicated
on here.

On 17/11/2024 13:22, Michael Möller via Discuss wrote:

Ray, I have to say that I've found the complexity lurking in this hirth
joint to be kind of baffling.  When I saw Bob's first attempt I
immediately thought Bob was massively overcomplicating things.  But I was
wrong.  It seems like it should be very simple, and yet it seems to be
remarkably subtle and complicated.  We're not "making" it that
way---that's just the way it is. I thought it was trivial and wrote a
straight forward code and then found that it didn't work in various
cases---it was wrong, in other words, and getting it right is hard.  Or at
least I didn't find an easy way to get it right, and neither did Bob.  And
when I say it was wrong, I mean that the joint didn't mate properly.
Clearly something different happens if you approach the design with "I have
a 60 deg milling cutter, how do I cut a 100 tooth hirth joint" than "I want
to construct a mathematical model that makes a generic version of this
joint".  I think another factor is that a lot of the subtlety results in
errors that become small when there are lots of teeth.  I see potential
interesting applications for this joint with small numbers of teeth like
perhaps 8 or 4 to create mechanisms that lock into a small number of
positions, so I don't want to ignore those small tooth count cases.

Regarding tooth angle, I attempted to measure it at the tooth ridge with
nominal tooth angle set to 60 and zero cone angle.  With four teeth I get
76.8 deg instead of 60 deg.  With 44 teeth I get 60.16 deg.  With 144 teeth
it's 60.01 deg.  If I raise the cone angle to 30 deg then I actually get
60.4 in the 4 tooth case, but in the 44 tooth case it's now 65.5 deg and
with 144 teeth it's 66.8 deg.  Why does the 30 deg cone angle make the 4
tooth case so close to the nominal angle?  It's because the tooth ridge in
this case is very close to parallel to the xy plane, which matches the
design angle reference for the construction of the triangle.    Here's a
picture (4 teeth, 30 deg cone angle, 60 deg nominal tooth angle):

[image: image.png]

So it seems like the deviation of tooth angle for small tooth count has to
do with fitting the teeth around a circle.  When you have lots of teeth,
it's approximately like fitting the teeth onto a line and nothing weird
happens, but when you curve just 4 teeth around a circle, the angles no
longer add up as expected for flat geometry, resulting in an alteration of
the actual realized tooth angle.  So to produce teeth that match the
nominal angle there are two corrections needed.  One is a correction for
fitting a linear arrangement of triangles around a circle, with increasing
correction as the number of teeth shrinks.  The other one has to do with
cone angle, and at least for my definition of cone angle, the correction
looks like it gets smaller and then larger again as you increase the cone
angle---at least for the small tooth count case.

On Sun, Nov 17, 2024 at 12:44 PM Raymond West via Discuss <
discuss@lists.openscad.org> wrote:

Hi Adrian,

The code I sent seemed to be OK for anything more than two teeth. Maybe
if I explain how I think it would have been originally made will let you
see where you are getting odd angles. The first requirement would be a
grinding wheel. (I would guess that it was most likely a milling cutter,
and material brass, but never mind, same principle.) The standard angles
for such discs would either be 90 degree or 60 degree (inclusive angle),
others would most likely be more expensive. This would be a disc, with a
v edge (at 90 or 60 degrees). The edge of the disc would be rounded,
since a pointed edge would not last long. This would be used in a
horizontal grinder,  the disc can be raised or lowered, and the bed
traversed backwards and forwards under the wheel. A piece of steel,
fixed to the bed could thus have a v groove ground into it, and the
profile, if no sideways movement, would be the inverse of the grinding
disk, it would have a rounded bottom (fillet) to the groove.

Now, if you have a rotary table, then you can clamp a round piece of
steel to that, and rotate the table a certain part of a revolution. So,
say, move in 30 degree steps, and you will get 6 v grooves, crossing in
the centre of the stock piece (or 12 meeting at the centre...) as you
traverse the piece at  the fixed angle beneath the grinding disc.

Now, wedge up one end of the rotary table. A new piece of stock will
give you 12 v grooves, say, but shallower towards the centre. If you
make it, such that the grooves are at zero depth at the centre, and full
depth at the edge, and there are the correct number of grooves,  then
two such pieces will mesh together, and tend to self centre. Of course,
the bottom of grooves are filleted due to the shape of the grinding
wheel. The fillet will be a constant width. To get two such pieces to
fit together, the peaks need to be rounded over, but flattening them is
simpler, and in some ways better (else the point of the mating ridge
bottoms out on the fillet). The centres of the round stock pieces can be
machined away, since there is little force transmitted there, and for
other reasons. So,  simple calculations can be made, depending on the
tooling available, size of desired coupling joint and number of teeth, etc.

Say we have a work piece diameter 40, and a grinding disc, say, width 8,
and 90 degree angle. We can calculate the minimum number of teeth from
d=40 and chord = 8. The maximum will depend on the radius of the 90
degree edge of the grinding wheel (which creates the fillet - we don't
want all fillet!), but let's say 50. That means the rotary table
increments must be in steps of 360/50 =7.2 degrees. If we were going
full depth of cut, then the maximum depth would be 4 (angle of 90
degrees), and 8 between peaks (but we can't go full depth at 7.2degrees).

So, given the length of chord, and diameter of work, we can find the
number of chords, n,  from d=(chord/ (sin(180/n))) we can solve that for
chord, and then the height of the ridge will be half of the chord length
(90 degree angle to wheel)- the assumption is that the grinding wheel
edge is pointed, not rounded.

Now, we want the grinding wheel to cut the depth calculated at the edge
of the work piece, but just touch the centre of the workpiece, so we can
calculate that we need to fix it at an angle that is
ASIN(ridge_height/2)/diam).

That will give a self centring matching Hirth joints, which afaik
complies with the 1928 original specification.

For the purposes of calculation ignore the radius at the bottom of the
grooves - that will depend on the wheel profile. As to all intents and
purposes, the bottom of the fillet will be parallel to the bottom of the
estimated groove, so the angle to the horizontal will be the same. The
top of the flattened ridge can be wider than the width of the fillet,
but the edges of the flat will be parallel, too.

Like most things, it starts off simple, then gets overcomplicated, to
the state that it becomes difficult to see what was the fundamental
reason for its existence in the first place. I would guess, that Hirth,
being a practical engineer, just made it in the workshop, then decided
to document it afterwards, most likely quicker than calculating angles,
etc., back then.

I think, as soon as you change the design so that the matching parts are
not identical, or do not have straight and flat flanks to the ridges,
then it is no longer a Hirth coupling.

On 17/11/2024 18:46, Adrian Mariano wrote:

Ray, so if I understand your description, you have the blank you're
grinding mounted at an angle and you then use your 60 deg grinding wheel to
grind the groove, which due to the angled mount, tapers from full depth at
the edge to zero depth in the center.  Is that right?  If the answer is
yes, then it appears to me that the result is NOT a 60 deg angle on the
teeth, because the cutter meets the workpiece at an angle, the effective
tooth angle is modified by that angle at which the blank is tilted.

I also found that to get a symmetric self-mating joint I had to "grind" at
half that angle, in effect.  That is, I had to make the centerline of the
teeth intersect each other at the origin, not the teeth tips or the teeth
valleys.  I tried it the other way at first and it didn't work.

On Sun, Nov 17, 2024 at 4:15 PM Raymond West via Discuss <
discuss@lists.openscad.org> wrote:

Adrian Mariano wrote:

That seems to confirm my hunch and it makes sense as then only 60° and 90° tools are required instead of a whole range of different custom-made tools. The resulting splines are then only nominally 60° or 90° while the groove is precisely that angle. Can this be expected to give a proper fit?

The problem for us is also that CAD/3D printing and the machining process work on different principles.

For a little extra complication: what does “fit” mean? To me it means that the flanks must be in contact over the whole area. Even 0.01 mm of clearance means no contact, and no transmission of forces, so that these are concentrated on a small area. It can be seen most clearly in joints with a small number of splines whether full contact is achieved, or not.

However, the discrepancy decreases rapidly with increasing numbers of splines, and even further if the ring of splines is narrow, so that at some point it will become negligible.

I would confirm that, the centreline being at half spline height. But with 3 splines, they only touch in the middle - see screenshot of joint with 90° splines (included angle around the ridge, flank to flank).

BTW Hirth couplings were not at all simple to manufacture, with the machinery available at the time and were a luxury. A crankshaft with Hirth couplings for a Grand Prix racing car cost as much as a house.

I'm not sure what you mean about "with 3 splines they only touch in the
middle".  That's only true if the model is wrong, like so many of my early
attempts.  With a correct model this is not the case, of course.  What
model gave you the behavior in question?  Or do you mean the model
constructed as described by Ray?  It may be the case that an improper fit
was good enough for machinists making these joints with lots of teeth?  For
my current code I get the image below, where I separated the parts by a
tiny amount to show the gap.  I'm pretty sure Bob's model also gives the
same result, namely that parts mate exactly along the entire joint
surface.  Our models are designed mathematically to ensure that they mate
exactly.  I realized that I never really examined Ray's model because I
couldn't get it to render in either OpenSCAD I had (not the stable nor the
dev) and preview was unusably slow on my machine.

[image: image.png]

On Sun, Nov 17, 2024 at 6:47 PM Caddiy via Discuss <
discuss@lists.openscad.org> wrote: