new harmonic drive v2.xxxxxx
Greetings to all the math wizards here;
I have redesigned this to use the elipse of the internal rotor as the
shaping ring driver. Interposing 3 ball bearing assemblies to make the
tooth bearing ring into the elipse desired
But I am seeing, when I hold the parts up to the light to gauge the
engagement, that the tipping of the teeth by 6 degrees a tooth as a
circle of 60 are composed, the effects on the effective shape of the
tooth, placing the tips of the teeth faceing out at a wider spacing than
those facing inward, than the outer rings corresponding teeth facing
inward, and this is creating a condition where the teeth do not slide on
their mating faces, but the tips contact first, creating a high
pressure, rapid wear point. A wear point that will, as it wears in,
create undesirable backlash in the assembly. So the equilateral
triangles I'm using aren't quite the ideal shape.
In composing the tooth, I'm doing it at 10x x-y then scaling it .1 x-y to
generate the tooth. That "scale" statement then is the ideal place to
put the correction values. My question then is how much correction would
be mathematically correct given that each tooth needs only the x tweek,
the rotation is later. For rotation angles of 6 degrees for 60 teeth,
and 5.8064516129 degrees for the 62 tooth, thereby restoring the
equalatteraly that the triangles rotation destroys. FWIW. all rotations
re done on center=true
And equal but opposite would apply when the tooth is rotated 180 degrees
to make its facing mate. So I'd need some +x for the teeth facing out
and some -x for the teeth facing in. But is it that simple? IDK.
Thanks for any insight.
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page http://geneslinuxbox.net:6309/gene
A Google of gear tooth design displayed a link to
https://www.engineersedge.com/gear_formula.htm
Does this help?
On 2021-05-06 10:12 a.m., Gene Heskett wrote:
Greetings to all the math wizards here;
I have redesigned this to use the elipse of the internal rotor as the
shaping ring driver. Interposing 3 ball bearing assemblies to make the
tooth bearing ring into the elipse desired
But I am seeing, when I hold the parts up to the light to gauge the
engagement, that the tipping of the teeth by 6 degrees a tooth as a
circle of 60 are composed, the effects on the effective shape of the
tooth, placing the tips of the teeth faceing out at a wider spacing than
those facing inward, than the outer rings corresponding teeth facing
inward, and this is creating a condition where the teeth do not slide on
their mating faces, but the tips contact first, creating a high
pressure, rapid wear point. A wear point that will, as it wears in,
create undesirable backlash in the assembly. So the equilateral
triangles I'm using aren't quite the ideal shape.
In composing the tooth, I'm doing it at 10x x-y then scaling it .1 x-y to
generate the tooth. That "scale" statement then is the ideal place to
put the correction values. My question then is how much correction would
be mathematically correct given that each tooth needs only the x tweek,
the rotation is later. For rotation angles of 6 degrees for 60 teeth,
and 5.8064516129 degrees for the 62 tooth, thereby restoring the
equalatteraly that the triangles rotation destroys. FWIW. all rotations
re done on center=true
And equal but opposite would apply when the tooth is rotated 180 degrees
to make its facing mate. So I'd need some +x for the teeth facing out
and some -x for the teeth facing in. But is it that simple? IDK.
Thanks for any insight.
Cheers, Gene Heskett
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
Are you using the involute gear code available with the BOSL2 package?
https://github.com/revarbat/BOSL2/wiki/gears.scad
https://github.com/revarbat/BOSL2/wiki/gears.scad
On 5/6/2021 7:12 AM, Gene Heskett wrote:
Greetings to all the math wizards here;
I have redesigned this to use the elipse of the internal rotor as the
shaping ring driver. Interposing 3 ball bearing assemblies to make the
tooth bearing ring into the elipse desired
But I am seeing, when I hold the parts up to the light to gauge the
engagement, that the tipping of the teeth by 6 degrees a tooth as a
circle of 60 are composed, the effects on the effective shape of the
tooth, placing the tips of the teeth faceing out at a wider spacing than
those facing inward, than the outer rings corresponding teeth facing
inward, and this is creating a condition where the teeth do not slide on
their mating faces, but the tips contact first, creating a high
pressure, rapid wear point. A wear point that will, as it wears in,
create undesirable backlash in the assembly. So the equilateral
triangles I'm using aren't quite the ideal shape.
In composing the tooth, I'm doing it at 10x x-y then scaling it .1 x-y to
generate the tooth. That "scale" statement then is the ideal place to
put the correction values. My question then is how much correction would
be mathematically correct given that each tooth needs only the x tweek,
the rotation is later. For rotation angles of 6 degrees for 60 teeth,
and 5.8064516129 degrees for the 62 tooth, thereby restoring the
equalatteraly that the triangles rotation destroys. FWIW. all rotations
re done on center=true
And equal but opposite would apply when the tooth is rotated 180 degrees
to make its facing mate. So I'd need some +x for the teeth facing out
and some -x for the teeth facing in. But is it that simple? IDK.
Thanks for any insight.
Cheers, Gene Heskett
On Thursday 06 May 2021 15:25:57 Jeff Meeks wrote:
Are you using the involute gear code available with the BOSL2 package?
https://github.com/revarbat/BOSL2/wiki/gears.scad
https://github.com/revarbat/BOSL2/wiki/gears.scad
Not that I know of. Its all self contained in the .scad file, one of
which I'll attach. This one generates a 60 tooth spline, but changing
the comment markers of the for loops will generate either a 62 or a 58
tooth version.
On 5/6/2021 7:12 AM, Gene Heskett wrote:
Greetings to all the math wizards here;
I have redesigned this to use the elipse of the internal rotor as
the shaping ring driver. Interposing 3 ball bearing assemblies to
make the tooth bearing ring into the elipse desired
But I am seeing, when I hold the parts up to the light to gauge the
engagement, that the tipping of the teeth by 6 degrees a tooth as a
circle of 60 are composed, the effects on the effective shape of the
tooth, placing the tips of the teeth faceing out at a wider spacing
than those facing inward, than the outer rings corresponding teeth
facing inward, and this is creating a condition where the teeth do
not slide on their mating faces, but the tips contact first,
creating a high pressure, rapid wear point. A wear point that will,
as it wears in, create undesirable backlash in the assembly. So the
equilateral triangles I'm using aren't quite the ideal shape.
In composing the tooth, I'm doing it at 10x x-y then scaling it .1
x-y to generate the tooth. That "scale" statement then is the ideal
place to put the correction values. My question then is how much
correction would be mathematically correct given that each tooth
needs only the x tweek, the rotation is later. For rotation angles
of 6 degrees for 60 teeth, and 5.8064516129 degrees for the 62
tooth, thereby restoring the equalatteraly that the triangles
rotation destroys. FWIW. all rotations re done on center=true
And equal but opposite would apply when the tooth is rotated 180
degrees to make its facing mate. So I'd need some +x for the teeth
facing out and some -x for the teeth facing in. But is it that
simple? IDK.
Thanks for any insight.
Thanks, Jeff Meeks
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page http://geneslinuxbox.net:6309/gene
Hi,
I'm no math wizard, but the code you show seems confused. (but probably due
to your extracting the vital part from bigger code). A few general points,
which have more to do with "good Programming Practice/Style" rather than
the problem you have.
Firstly, and I'm probably exposing my ignorance here, why put a "$" in
front of variables? Totally not needed. The "special" variables like $fn,
$t and so on have the $ to show they are special, in the sense they are
part of the OpenSCAD core.
Several times your comment says variables do not work - I can not see what
didn't work. Variables work fine for me, especially the type that just is
declared at the top.
Line 27: "0.000000" : It does not become more accurate, with many trailing
zeros. rotate [0,0, ... is just as accurate as rotate[0.000000, 0.000000
.... I have not had rounding errors after several years of use, so $fx = ([
360.00000000 / 60.00000000 ] or $fx = [ 360/60 ] gives the same result.
BTW, you do not use this $fx elsewhere. OpenSCAD will make everything float
so you do not get truncation of dividing "integers". But tastes differ, you
might feel that it looks cleaner (lines up easier, used to reading
engineering diagrams...) with "0.00000"
Your mail states you "design" in 10-times scale and then scale down. It
makes absolutely no difference to the final accuracy. It might make things
more readable, if your "design" bit was in nice simple integers. I've done
it that way myself.
I do not know if you have a high vacuum metal deposition 3D printer. I have
the ordinary plastic kind and accuracy is 0.1mm on a good day, so at my
maximum bed size 3 significant digits is enough for any variable.
Line 10: Why did you make that an array? You overwrite it later. AFAIK
there is no need to worry about variable memory allocation that your
comment alludes to. (Yes, that variables are not "variables" in OpenSCAD
but more like "defines" is a troublesome concept if you are used to
procedural languages. OpenSCAD is a declarative language, it describes a
static object,not a run time execution)
Line 20: citing various odd values... if it is the result of a calculator,
put the calculation there, like 360/62 instead of 5.860... Internally it
will be even more precise than what you write.
Also, I have found that when I do things on a circle (like teeth on a gear)
I do NOT go from 0 to 360. 360 and 0 are the same position, i.e. that tooth
is created twice. I typically do for (i=[0:5:359])so in your case
for(i=[0:360/62:359]).
Now as you want to make several gears, instead of 5+ comments for optional
code it just is: for ([i=[0:360/N:359]) where N is the number of teeth
desired
Line 31: The magic "54.05". I've done this myself, tweaking something until
it fits. Then when I want to reuse the model 3 months later, with a bigger
gear, f.ex, I can't get it to work, because I can't remember why the
"54.05" was there, or what it represents. Here I can surmise it is the
offset from center to the edge of the ring. I tried translate([InnerDia/2,
0, 0]) but that was too far. Then I realized that I had to move it inward
by the radius of the tooth. But that was too far inwards. And then I
realized that because you create a triangle of a circle (with the $fn=3)
the base of the triangle is inside the circle and I got tired of working
out where the edge of an equilateral triangle is in terms of the radius
when inscribed in a circle. Nor did you, so you just nudged it around until
it touched the surface the way you wanted it. Works, but is hellishly hard
to handle when sizes change.
Back to the drawing board. Here you too might find the solution to your
problem ... you do not want equilateral triangle teeth, but isosceles -
which you realized yourself already as you ask for how much to squeeze the
equilateral triangle, thus making it an isosceles one. Using
linear_extrude(height=ToothHeight) { Polygon= [ [-TW,0], [TW,0],
0,ToothHeight] ] ) ; } to generate a triangle of the right shape instead of
the cylinder ( ..$fn=3). Now that the baseline of the triangle is known,
the magic translation "54.05" can be replaced by translate([InnerDia,0,0]).
"TW" for ToothWidth is the circumference of your inner surface divided by
the number of teeth and then - and that was your question, I think - scale
it a tiny amount to give you the clearance you want.
I attach my mangled version of your code. You can change ToothCount and
everything else falls into place. You can change the ToothHeight and it
will NOT affect ToothWidth. ToothWidth I have "tweaked" with 0.95 - remove
it or change to suit.
Note that all changes are just "better programming", not lots of math
(apart from calculating the tooth width to fit to the circle). Your
fundamental problem is using triangle teeth. Involute tooth shapes are
better, they "roll", not "slide". Triangular teeth work if there is
enough clearance and you're not transmitting lots of force. It is easy to
change the polygon shape to something that approximates a involute tooth,
f.ex just make it a trapezoid (chop of the tip of triangle), and that would
be a large improvement.
Well, that escalated quickly. I just want to write a few notes, but now
I've spent (an enjoyable) 2 hours with this post. Hope it helps.
Msquare
// new example, using a low ratio harmonic drive floating
// splined belt with 60 teeth.
// s/b 30/1 when finished.
InnerDia=111.4 ;
OuterDia=117.8;
ToothCount=58;
ToothHeight=6.95; // was 69.00000000 a blond one too big
ToothWidth = InnerDia*PI/ToothCount *0.95 ; // the "0.95" is a fudge to
give clearance
GearHeight=9.75 ;
// overall span of armature plus bearings equals 96.6mm's
// Ring part
difference() { // the outside smoother
cylinder(d=OuterDia, h=GearHeight, $fn=360); //outer is fussy
cylinder(d=InnerDia, h=GearHeight, $fn=180); //but the inner isn't
};
// Teeth
for( TP = [ 0: 360/ToothCount : 359 ]) {
//cylinder(h=11.75, d=8, center=true);
rotate([0,0, TP]) // position of tooth round ring
translate([InnerDia/2, 0, 0]) // mv x only
linear_extrude(height=GearHeight) {
polygon( [ [0,-ToothWidth/2],
[0,ToothWidth/2],
[-ToothHeight,0] ] ) ; }// make thick triangle
}; // switch h=9.500 for outer rings
On Thu, 6 May 2021 at 23:40, Gene Heskett gheskett@shentel.net wrote:
On Thursday 06 May 2021 15:25:57 Jeff Meeks wrote:
Are you using the involute gear code available with the BOSL2 package?
https://github.com/revarbat/BOSL2/wiki/gears.scad
https://github.com/revarbat/BOSL2/wiki/gears.scad
Not that I know of. Its all self contained in the .scad file, one of
which I'll attach. This one generates a 60 tooth spline, but changing
the comment markers of the for loops will generate either a 62 or a 58
tooth version.
On 5/6/2021 7:12 AM, Gene Heskett wrote:
Greetings to all the math wizards here;
I have redesigned this to use the elipse of the internal rotor as
the shaping ring driver. Interposing 3 ball bearing assemblies to
make the tooth bearing ring into the elipse desired
But I am seeing, when I hold the parts up to the light to gauge the
engagement, that the tipping of the teeth by 6 degrees a tooth as a
circle of 60 are composed, the effects on the effective shape of the
tooth, placing the tips of the teeth faceing out at a wider spacing
than those facing inward, than the outer rings corresponding teeth
facing inward, and this is creating a condition where the teeth do
not slide on their mating faces, but the tips contact first,
creating a high pressure, rapid wear point. A wear point that will,
as it wears in, create undesirable backlash in the assembly. So the
equilateral triangles I'm using aren't quite the ideal shape.
In composing the tooth, I'm doing it at 10x x-y then scaling it .1
x-y to generate the tooth. That "scale" statement then is the ideal
place to put the correction values. My question then is how much
correction would be mathematically correct given that each tooth
needs only the x tweek, the rotation is later. For rotation angles
of 6 degrees for 60 teeth, and 5.8064516129 degrees for the 62
tooth, thereby restoring the equalatteraly that the triangles
rotation destroys. FWIW. all rotations re done on center=true
And equal but opposite would apply when the tooth is rotated 180
degrees to make its facing mate. So I'd need some +x for the teeth
facing out and some -x for the teeth facing in. But is it that
simple? IDK.
Thanks for any insight.
Thanks, Jeff Meeks
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page http://geneslinuxbox.net:6309/gene
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I'm on my phone, so will limit my comment to one point. The $ in front of
variables has significant effect on how variables are treated in the
language. They can be set in a scope, and subscopes (functions and modules
called by the scope) inherit the value. They can even be passed as an
argument to only set the value in the context of that call. Normal
variables don't work like that at all...
On Thu, 6 May 2021, 19:51 Michael Möller, private2michael@gmail.com wrote:
Hi,
I'm no math wizard, but the code you show seems confused. (but probably
due to your extracting the vital part from bigger code). A few general
points, which have more to do with "good Programming Practice/Style" rather
than the problem you have.
Firstly, and I'm probably exposing my ignorance here, why put a "$" in
front of variables? Totally not needed. The "special" variables like $fn,
$t and so on have the $ to show they are special, in the sense they are
part of the OpenSCAD core.
Several times your comment says variables do not work - I can not see what
didn't work. Variables work fine for me, especially the type that just is
declared at the top.
Line 27: "0.000000" : It does not become more accurate, with many trailing
zeros. rotate [0,0, ... is just as accurate as rotate[0.000000, 0.000000
.... I have not had rounding errors after several years of use, so $fx = ([
360.00000000 / 60.00000000 ] or $fx = [ 360/60 ] gives the same result.
BTW, you do not use this $fx elsewhere. OpenSCAD will make everything float
so you do not get truncation of dividing "integers". But tastes differ, you
might feel that it looks cleaner (lines up easier, used to reading
engineering diagrams...) with "0.00000"
Your mail states you "design" in 10-times scale and then scale down. It
makes absolutely no difference to the final accuracy. It might make things
more readable, if your "design" bit was in nice simple integers. I've done
it that way myself.
I do not know if you have a high vacuum metal deposition 3D printer. I
have the ordinary plastic kind and accuracy is 0.1mm on a good day, so at
my maximum bed size 3 significant digits is enough for any variable.
Line 10: Why did you make that an array? You overwrite it later. AFAIK
there is no need to worry about variable memory allocation that your
comment alludes to. (Yes, that variables are not "variables" in OpenSCAD
but more like "defines" is a troublesome concept if you are used to
procedural languages. OpenSCAD is a declarative language, it describes a
static object,not a run time execution)
Line 20: citing various odd values... if it is the result of a calculator,
put the calculation there, like 360/62 instead of 5.860... Internally it
will be even more precise than what you write.
Also, I have found that when I do things on a circle (like teeth on a
gear) I do NOT go from 0 to 360. 360 and 0 are the same position, i.e. that
tooth is created twice. I typically do for (i=[0:5:359])so in your case
for(i=[0:360/62:359]).
Now as you want to make several gears, instead of 5+ comments for optional
code it just is: for ([i=[0:360/N:359]) where N is the number of teeth
desired
Line 31: The magic "54.05". I've done this myself, tweaking something
until it fits. Then when I want to reuse the model 3 months later, with a
bigger gear, f.ex, I can't get it to work, because I can't remember why the
"54.05" was there, or what it represents. Here I can surmise it is the
offset from center to the edge of the ring. I tried translate([InnerDia/2,
0, 0]) but that was too far. Then I realized that I had to move it inward
by the radius of the tooth. But that was too far inwards. And then I
realized that because you create a triangle of a circle (with the $fn=3)
the base of the triangle is inside the circle and I got tired of working
out where the edge of an equilateral triangle is in terms of the radius
when inscribed in a circle. Nor did you, so you just nudged it around until
it touched the surface the way you wanted it. Works, but is hellishly hard
to handle when sizes change.
Back to the drawing board. Here you too might find the solution to your
problem ... you do not want equilateral triangle teeth, but isosceles -
which you realized yourself already as you ask for how much to squeeze the
equilateral triangle, thus making it an isosceles one. Using
linear_extrude(height=ToothHeight) { Polygon= [ [-TW,0], [TW,0],
0,ToothHeight] ] ) ; } to generate a triangle of the right shape instead of
the cylinder ( ..$fn=3). Now that the baseline of the triangle is known,
the magic translation "54.05" can be replaced by translate([InnerDia,0,0]).
"TW" for ToothWidth is the circumference of your inner surface divided by
the number of teeth and then - and that was your question, I think - scale
it a tiny amount to give you the clearance you want.
I attach my mangled version of your code. You can change ToothCount and
everything else falls into place. You can change the ToothHeight and it
will NOT affect ToothWidth. ToothWidth I have "tweaked" with 0.95 - remove
it or change to suit.
Note that all changes are just "better programming", not lots of math
(apart from calculating the tooth width to fit to the circle). Your
fundamental problem is using triangle teeth. Involute tooth shapes are
better, they "roll", not "slide". Triangular teeth work if there is
enough clearance and you're not transmitting lots of force. It is easy to
change the polygon shape to something that approximates a involute tooth,
f.ex just make it a trapezoid (chop of the tip of triangle), and that would
be a large improvement.
Well, that escalated quickly. I just want to write a few notes, but now
I've spent (an enjoyable) 2 hours with this post. Hope it helps.
Msquare
// new example, using a low ratio harmonic drive floating
// splined belt with 60 teeth.
// s/b 30/1 when finished.
InnerDia=111.4 ;
OuterDia=117.8;
ToothCount=58;
ToothHeight=6.95; // was 69.00000000 a blond one too big
ToothWidth = InnerDia*PI/ToothCount *0.95 ; // the "0.95" is a fudge to
give clearance
GearHeight=9.75 ;
// overall span of armature plus bearings equals 96.6mm's
// Ring part
difference() { // the outside smoother
cylinder(d=OuterDia, h=GearHeight, $fn=360); //outer is fussy
cylinder(d=InnerDia, h=GearHeight, $fn=180); //but the inner isn't
};
// Teeth
for( TP = [ 0: 360/ToothCount : 359 ]) {
//cylinder(h=11.75, d=8, center=true);
rotate([0,0, TP]) // position of tooth round ring
translate([InnerDia/2, 0, 0]) // mv x only
linear_extrude(height=GearHeight) {
polygon( [ [0,-ToothWidth/2],
[0,ToothWidth/2],
[-ToothHeight,0] ] ) ; }// make thick triangle
}; // switch h=9.500 for outer rings
On Thu, 6 May 2021 at 23:40, Gene Heskett gheskett@shentel.net wrote:
On Thursday 06 May 2021 15:25:57 Jeff Meeks wrote:
Are you using the involute gear code available with the BOSL2 package?
https://github.com/revarbat/BOSL2/wiki/gears.scad
https://github.com/revarbat/BOSL2/wiki/gears.scad
Not that I know of. Its all self contained in the .scad file, one of
which I'll attach. This one generates a 60 tooth spline, but changing
the comment markers of the for loops will generate either a 62 or a 58
tooth version.
On 5/6/2021 7:12 AM, Gene Heskett wrote:
Greetings to all the math wizards here;
I have redesigned this to use the elipse of the internal rotor as
the shaping ring driver. Interposing 3 ball bearing assemblies to
make the tooth bearing ring into the elipse desired
But I am seeing, when I hold the parts up to the light to gauge the
engagement, that the tipping of the teeth by 6 degrees a tooth as a
circle of 60 are composed, the effects on the effective shape of the
tooth, placing the tips of the teeth faceing out at a wider spacing
than those facing inward, than the outer rings corresponding teeth
facing inward, and this is creating a condition where the teeth do
not slide on their mating faces, but the tips contact first,
creating a high pressure, rapid wear point. A wear point that will,
as it wears in, create undesirable backlash in the assembly. So the
equilateral triangles I'm using aren't quite the ideal shape.
In composing the tooth, I'm doing it at 10x x-y then scaling it .1
x-y to generate the tooth. That "scale" statement then is the ideal
place to put the correction values. My question then is how much
correction would be mathematically correct given that each tooth
needs only the x tweek, the rotation is later. For rotation angles
of 6 degrees for 60 teeth, and 5.8064516129 degrees for the 62
tooth, thereby restoring the equalatteraly that the triangles
rotation destroys. FWIW. all rotations re done on center=true
And equal but opposite would apply when the tooth is rotated 180
degrees to make its facing mate. So I'd need some +x for the teeth
facing out and some -x for the teeth facing in. But is it that
simple? IDK.
Thanks for any insight.
Thanks, Jeff Meeks
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page http://geneslinuxbox.net:6309/gene
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On Thursday 06 May 2021 19:51:13 Michael Möller wrote:
Hi,
I'm no math wizard, but the code you show seems confused. (but
probably due to your extracting the vital part from bigger code). A
few general points, which have more to do with "good Programming
Practice/Style" rather than the problem you have.
Firstly, and I'm probably exposing my ignorance here, why put a "$" in
front of variables? Totally not needed. The "special" variables like
$fn, $t and so on have the $ to show they are special, in the sense
they are part of the OpenSCAD core.
Several times your comment says variables do not work - I can not see
what didn't work. Variables work fine for me, especially the type that
just is declared at the top.
Line 27: "0.000000" : It does not become more accurate, with many
trailing zeros.
Thts is a carry over from writing my own gcode for the last 20 years. And
I'm fond of loops. I have a saw blade sharpener routine of 80 lines.
But sharpening a carbide tipped table saw blade is slow work, so it
takes 3 days to run, which takes around .003" off the face of every
tooth of an 80 tooth ATBF blade. Sharpest blade I ever used, it was
nearly 3 years old before it made the first burn mark on some cherry I
was buulding an entertainment center cabinet from.
LinuxCNC's IF/WHILE/REPEAT etc code compares for equality out to about 8
digits right of the decimal when determining equality.
That also is only about the 2nd or third bit of openscad I ever wrote and
there are w/o a doubt, some unused defines in it.
rotate [0,0, ... is just as accurate as
rotate[0.000000, 0.000000 .... I have not had rounding errors after
several years of use, so $fx = ([ 360.00000000 / 60.00000000 ] or
$fx = [ 360/60 ] gives the same result. BTW, you do not use this $fx
elsewhere. OpenSCAD will make everything float so you do not get
truncation of dividing "integers". But tastes differ, you might feel
that it looks cleaner (lines up easier, used to reading engineering
diagrams...) with "0.00000"
Your mail states you "design" in 10-times scale and then scale down.
It makes absolutely no difference to the final accuracy. It might make
things more readable, if your "design" bit was in nice simple
integers. I've done it that way myself.
I do not know if you have a high vacuum metal deposition 3D printer. I
have the ordinary plastic kind and accuracy is 0.1mm on a good day, so
at my maximum bed size 3 significant digits is enough for any
variable.
So I have observed, and changing printers is a no-no as I'm finding parts
made on printer D don't fit parts made on printer A, B, or C often by
more than 2 percent.
Line 10: Why did you make that an array? You overwrite it later. AFAIK
there is no need to worry about variable memory allocation that your
comment alludes to. (Yes, that variables are not "variables" in
OpenSCAD but more like "defines" is a troublesome concept if you are
used to procedural languages.
It has taken some getting used to.
OpenSCAD is a declarative language, it
describes a static object,not a run time execution)
Line 20: citing various odd values... if it is the result of a
calculator, put the calculation there, like 360/62 instead of 5.860...
Internally it will be even more precise than what you write.
I actually tried that, but the syntax diffs, whupped me.
Also, I have found that when I do things on a circle (like teeth on a
gear) I do NOT go from 0 to 360. 360 and 0 are the same position, i.e.
that tooth is created twice. I typically do for (i=[0:5:359])so in
your case for(i=[0:360/62:359]).
Good Point. Thanks.
Now as you want to make several gears, instead of 5+ comments for
optional code it just is: for ([i=[0:360/N:359]) where N is the
number of teeth desired
I'm learning.
Line 31: The magic "54.05". I've done this myself, tweaking something
until it fits. Then when I want to reuse the model 3 months later,
with a bigger gear, f.ex, I can't get it to work, because I can't
remember why the "54.05" was there, or what it represents. Here I can
surmise it is the offset from center to the edge of the ring. I tried
translate([InnerDia/2, 0, 0]) but that was too far. Then I realized
that I had to move it inward by the radius of the tooth.
yes, the tooth is center=true.
But that was
too far inwards. And then I realized that because you create a
triangle of a circle (with the $fn=3) the base of the triangle is
inside the circle and I got tired of working out where the edge of an
equilateral triangle is in terms of the radius when inscribed in a
circle. Nor did you, so you just nudged it around until it touched the
surface the way you wanted it. Works, but is hellishly hard to handle
when sizes change.
yes, dd1 and dd2 could be an automatic, The larger fits inside the output
cup, held in place by friction of a snug fit and some goop. The innerrd
could be expanded to divorce the ring from the teeth, but is sized to
just include the base of the tooth via the union. And a third difference
ring could be sized to just clip the inner (or outer) points of the
teeth, which in turn would allow a slightly fatter tooth that actually
meshed better. Such niceties will probably be added in a build about 2
more fine tunings hence to get the finals. As is, the tips of the teeth
are catching hell when the rotational loading is heavy.
Back to the drawing board. Here you too might find the solution to
your problem ... you do not want equilateral triangle teeth, but
isosceles - which you realized yourself already as you ask for how
much to squeeze the equilateral triangle, thus making it an
isosceles one. Using linear_extrude(height=ToothHeight) { Polygon= [
[-TW,0], [TW,0], 0,ToothHeight] ] ) ; } to generate a triangle of the
right shape instead of the cylinder ( ..$fn=3). Now that the baseline
of the triangle is known, the magic translation "54.05" can be
replaced by translate([InnerDia,0,0]). "TW" for ToothWidth is the
circumference of your inner surface divided by the number of teeth and
then - and that was your question, I think - scale it a tiny amount to
give you the clearance you want.
I attach my mangled version of your code. You can change ToothCount
and everything else falls into place. You can change the ToothHeight
and it will NOT affect ToothWidth. ToothWidth I have "tweaked" with
0.95 - remove it or change to suit.
Thank you very much.
Note that all changes are just "better programming", not lots of math
(apart from calculating the tooth width to fit to the circle). Your
fundamental problem is using triangle teeth. Involute tooth shapes are
better, they "roll", not "slide". Triangular teeth work if there is
enough clearance and you're not transmitting lots of force. It is easy
to change the polygon shape to something that approximates a involute
tooth, f.ex just make it a trapezoid (chop of the tip of triangle),
and that would be a large improvement.
Something I've considered, but not done yet.
Well, that escalated quickly. I just want to write a few notes, but
now I've spent (an enjoyable) 2 hours with this post. Hope it helps.
It does indeed.
Msquare
// new example, using a low ratio harmonic drive floating
// splined belt with 60 teeth.
// s/b 30/1 when finished.
InnerDia=111.4 ;
OuterDia=117.8;
ToothCount=58;
ToothHeight=6.95; // was 69.00000000 a blond one too big
ToothWidth = InnerDia*PI/ToothCount *0.95 ; // the "0.95" is a fudge
to give clearance
GearHeight=9.75 ;
// overall span of armature plus bearings equals 96.6mm's
// Ring part
difference() { // the outside smoother
cylinder(d=OuterDia, h=GearHeight, $fn=360); //outer is fussy
cylinder(d=InnerDia, h=GearHeight, $fn=180); //but the inner isn't
};
// Teeth
for( TP = [ 0: 360/ToothCount : 359 ]) {
//cylinder(h=11.75, d=8, center=true);
rotate([0,0, TP]) // position of tooth round ring
translate([InnerDia/2, 0, 0]) // mv x only
linear_extrude(height=GearHeight) {
polygon( [ [0,-ToothWidth/2],
[0,ToothWidth/2],
[-ToothHeight,0] ] ) ; }// make thick triangle
}; // switch h=9.500 for outer rings
I'll give this a shot, after setting the latest sizes or corrections
based on the half finished one on the build plate now.
On Thu, 6 May 2021 at 23:40, Gene Heskett gheskett@shentel.net wrote:
On Thursday 06 May 2021 15:25:57 Jeff Meeks wrote:
Are you using the involute gear code available with the BOSL2
package? https://github.com/revarbat/BOSL2/wiki/gears.scad
https://github.com/revarbat/BOSL2/wiki/gears.scad
This I downloaded, but there is no INSTALL or README, so I wasn't able to
make openscad AppImage aware of it. A question I've been meaning to ask.
Not that I know of. Its all self contained in the .scad file, one of
which I'll attach. This one generates a 60 tooth spline, but
changing the comment markers of the for loops will generate either a
62 or a 58 tooth version.
On 5/6/2021 7:12 AM, Gene Heskett wrote:
Greetings to all the math wizards here;
I have redesigned this to use the elipse of the internal rotor
as the shaping ring driver. Interposing 3 ball bearing
assemblies to make the tooth bearing ring into the elipse
desired
But I am seeing, when I hold the parts up to the light to gauge
the engagement, that the tipping of the teeth by 6 degrees a
tooth as a circle of 60 are composed, the effects on the
effective shape of the tooth, placing the tips of the teeth
faceing out at a wider spacing than those facing inward, than
the outer rings corresponding teeth facing inward, and this is
creating a condition where the teeth do not slide on their
mating faces, but the tips contact first, creating a high
pressure, rapid wear point. A wear point that will, as it wears
in, create undesirable backlash in the assembly. So the
equilateral triangles I'm using aren't quite the ideal shape.
In composing the tooth, I'm doing it at 10x x-y then scaling it
.1 x-y to generate the tooth. That "scale" statement then is
the ideal place to put the correction values. My question then
is how much correction would be mathematically correct given
that each tooth needs only the x tweek, the rotation is later.
For rotation angles of 6 degrees for 60 teeth, and 5.8064516129
degrees for the 62 tooth, thereby restoring the equalatteraly
that the triangles rotation destroys. FWIW. all rotations re
done on center=true
And equal but opposite would apply when the tooth is rotated 180
degrees to make its facing mate. So I'd need some +x for the
teeth facing out and some -x for the teeth facing in. But is it
that simple? IDK.
Thanks for any insight.
Thanks, Jeff Meeks
Take care and stay well Jeff Meeks.
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page http://geneslinuxbox.net:6309/gene
On Thursday 06 May 2021 19:51:13 Michael Möller wrote:
I guess you will have to teach me how to use a library function from
BOSL2.
I have included:
include <BOSL2/std.scad>
include <BOSL2/rounding.scad>
near the top of my file, and I gotten rid of the 10x render then scale,
so I'm generating a regular triangle and it looks as good as ever.
And I've tried to clip the outer tips with a round cylinder but seem to
get unions in that the cylinder covers the triangle leaving the tips
stickiong out. odd.
So now I'm trying to use the BOSL2 library. But on inspection of
the .local/share/OpenSCAD/libraries path, discovered that my
installation was missing large parts of the .zip. fixed that, restarted
OpenSCAD but apparently I don't understand the syntax example.
I am getting a render abort blaming line 29, but the red dot is on line
28 for this code:
for($fr=[ 0: 6 : 359 ]){
rotate([0, 0, $fr]) translate([toothcirc, 0, 0])
// now lets try BOSL2. this comment Is line 28. has RED dot
rounded_path=round_corners(cut=0.5) // worx w/o this line
cylinder(d=toothdia, h=height, $fn=3, center=true);
// make tall triangle
};
from console window:
Parsing design (AST generation)...
ERROR: Parser error: syntax error in file final8-Loose_60T-inner.scad,
line 29
What am I doing wrong?
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page http://geneslinuxbox.net:6309/gene
You need a semicolon at the the end of this statement
rounded_path=round_corners(cut=0.5) // worx w/o this line
should be
rounded_path=round_corners(cut=0.5); // worx w/o this line
Gene Heskett wrote
I guess you will have to teach me how to use a library function from
BOSL2.
I am getting a render abort blaming line 29, but the red dot is on line
28 for this code:
for($fr=[ 0: 6 : 359 ]){
rotate([0, 0, $fr]) translate([toothcirc, 0, 0])
// now lets try BOSL2. this comment Is line 28. has RED dot
rounded_path=round_corners(cut=0.5) // worx w/o this line
cylinder(d=toothdia, h=height, $fn=3, center=true);
// make tall triangle
};
--
Sent from: http://forum.openscad.org/
On Friday 07 May 2021 14:33:05 lar3ry wrote:
You need a semicolon at the the end of this statement
rounded_path=round_corners(cut=0.5) // worx w/o this line
should be
rounded_path=round_corners(cut=0.5); // worx w/o this line
Made no difference. Same exact error. Besides the semi-colon is the end
of the chain marker for all the other keywords. AIUI of course.
Gene Heskett wrote
I guess you will have to teach me how to use a library function from
BOSL2.
I am getting a render abort blaming line 29, but the red dot is on
line 28 for this code:
for($fr=[ 0: 6 : 359 ]){
rotate([0, 0, $fr]) translate([toothcirc, 0, 0])
// now lets try BOSL2. this comment Is line 28. has RED dot
rounded_path=round_corners(cut=0.5) // worx w/o this line
cylinder(d=toothdia, h=height, $fn=3, center=true);
// make tall triangle
};
--
Sent from: http://forum.openscad.org/
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page http://geneslinuxbox.net:6309/gene