new harmonic drive v2.xxxxxx

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

new harmonic drive v2.xxxxxx

Gene Heskett
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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ***UNCHECKED*** new harmonic drive v2.xxxxxx

OpenSCAD mailing list-2
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
[hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

JeffMeeks12
In reply to this post by Gene Heskett
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
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

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>

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

Outer2-60T-spline.scad (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

Msquare
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 <[hidden email]> 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 [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
+--+
| M |
+--+
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

acwest
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, <[hidden email]> 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 <[hidden email]> 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 [hidden email]
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

Gene Heskett
In reply to this post by Msquare
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 <[hidden email]> 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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

Gene Heskett
In reply to this post by Gene Heskett
On Thursday 06 May 2021 19:51:13 Michael Möller wrote:
resend, I credited the wrong contributor.

> 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 <[hidden email]> 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 Michael Möller.

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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

adrianv
If you have the full BOSL2 distribution you should have README.md at the top level, which contains installation instructions.  

Gene Heskett 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.


Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

Gene Heskett
On Thursday 06 May 2021 22:08:34 adrianv wrote:

> If you have the full BOSL2 distribution you should have README.md at
> the top level, which contains installation instructions.
>
I must have gotten the wrong stuff, its named MCAD-master

>
> Gene Heskett wrote
>
> >> > > Are you using the involute gear code available with the BOSL2
> >> > > package? https://github.com/revarbat/BOSL2/wiki/gears.scad
> >> > > &lt;https://github.com/revarbat/BOSL2/wiki/gears.scad&gt;
> >
> > 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.
>
> --
> 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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

Gene Heskett
In reply to this post by adrianv
On Thursday 06 May 2021 22:08:34 adrianv wrote:

> If you have the full BOSL2 distribution you should have README.md at
> the top level, which contains installation instructions.
>
>
> Gene Heskett wrote
>
> >> > > Are you using the involute gear code available with the BOSL2
> >> > > package? https://github.com/revarbat/BOSL2/wiki/gears.scad
> >> > > &lt;https://github.com/revarbat/BOSL2/wiki/gears.scad&gt;
> >
> > 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.
>
found it at the first link, put it away like it said, looks like it
worked.  Thank you Adrian

> --
> 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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

lar3ry
In reply to this post by Gene Heskett
Here's the link for BOSL2.

https://github.com/revarbat/BOSL2

Once you're there, click on 'Wiki" and bookmark it. There are a ton of great explanations and examples.

Then download and install the code according to the README.md

Gene Heskett wrote
On Thursday 06 May 2021 22:08:34 adrianv wrote:

> If you have the full BOSL2 distribution you should have README.md at
> the top level, which contains installation instructions.
>
I must have gotten the wrong stuff, its named MCAD-master


Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

Gene Heskett
On Friday 07 May 2021 00:23:17 lar3ry wrote:

> Here's the link for BOSL2.
>
> https://github.com/revarbat/BOSL2
>
> Once you're there, click on 'Wiki" and bookmark it. There are a ton of
> great explanations and examples.
>
> Then download and install the code according to the README.md
>
WoW!  Just rounding is many many pages.  Sweet.  Thank you.

>
> Gene Heskett wrote
>
> > On Thursday 06 May 2021 22:08:34 adrianv wrote:
> >> If you have the full BOSL2 distribution you should have README.md
> >> at the top level, which contains installation instructions.
> >
> > I must have gotten the wrong stuff, its named MCAD-master
>
> --
> 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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

Gene Heskett
In reply to this post by Msquare
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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

lar3ry
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 the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

Gene Heskett
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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

pbruske234
I did this and it seems to have worked. 

Clicked on line 40 to highlight. Then clicked on Edit -> Comment. Clicked on line 41 to highlight. Clicked Edit -> Comment. Clicked Design -> Render

I can now see an image. Trying to edit dimensions now. 

On Fri, May 7, 2021 at 3:40 PM Gene Heskett <[hidden email]> wrote:
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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

Gene Heskett
In reply to this post by lar3ry
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
>
in the docs, the shorthand example says:
rounded_path = round_corners(path, <method>, <radius=>, <cut=>, <joint=>,
<closed=>, <verbose=>);

and "path" is not surrounded by a set of <>, what does that mean?  
Everything else is an option and has a default? I don't see where path
is defined by an example. A list of corners to round? Possibly in xyz
order?, also tried and failed.  

>
> 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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

adrianv
Yes, the argument not in <> is required.  Arguments in <> are optional, though in the case of round_corners you have to give one of radius, cut or joint to tell it how much to round.  

Note that because OpenSCAD doesn't give user code access to geometry, user code (libraries) have to work differently, meaning you have to supply a list of points you want to round, as shown in the examples in the wiki. Path is the first argument to round_corners, so if you write round_corners([[3,4],[5,6],...],...) that gives the path.  

include <BOSL2/std.scad>
include <BOSL2/rounding.scad>
$fn=36;
shape = [[0,0], [10,0], [15,12], [6,6], [6, 12], [-3,7]];  // List of points here !!!
polygon(round_corners(shape, cut=1));   // shape is the first arg to round corners, so it is the "path"

I think that the person who suggested BOSL2 thought you should use it for gears.scad which has implementations of gears already done.  

Gene Heskett wrote
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
>
in the docs, the shorthand example says:
rounded_path = round_corners(path, <method>, <radius=>, <cut=>, <joint=>,
<closed=>, <verbose=>);

and "path" is not surrounded by a set of <>, what does that mean?  
Everything else is an option and has a default? I don't see where path
is defined by an example. A list of corners to round? Possibly in xyz
order?, also tried and failed.  

>
> 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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]


Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: new harmonic drive v2.xxxxxx

Gene Heskett
On Friday 07 May 2021 16:42:00 adrianv wrote:

> Yes, the argument not in <> is required.  Arguments in <> are
> optional, though in the case of round_corners you have to give one of
> radius, cut or joint to tell it how much to round.
>
> Note that because OpenSCAD doesn't give user code access to geometry,
> user code (libraries) have to work differently, meaning you have to
> supply a list of points you want to round, as shown in the examples in
> the wiki. Path is the first argument to round_corners, so if you write
> round_corners([[3,4],[5,6],...],...) that gives the path.
>
> include <BOSL2/std.scad>
> include <BOSL2/rounding.scad>
> $fn=36;
> shape = [[0,0], [10,0], [15,12], [6,6], [6, 12], [-3,7]];  // List of
> points here !!!
> polygon(round_corners(shape, cut=1));   // shape is the first arg to
> round corners, so it is the "path"

Aha!

That clarifies that but leave me learning how to spec a polygon.
Is there a tut for that?

> I think that the person who suggested BOSL2 thought you should use it
> for gears.scad which has implementations of gears already done.

but gears has nothing for splines that I could find.

Making lots of duff plastic but getting closer all the time. :)
>
Thank you folks. Take care and stay well now.

> Gene Heskett wrote
>
> > 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
> >
> > in the docs, the shorthand example says:
> > rounded_path = round_corners(path,
> > <method>
> > , &lt;radius=&gt;, &lt;cut=&gt;, &lt;joint=&gt;,
> > &lt;closed=&gt;, &lt;verbose=&gt;);
> >
> > and "path" is not surrounded by a set of <>, what does that mean?
> > Everything else is an option and has a default? I don't see where
> > path is defined by an example. A list of corners to round? Possibly
> > in xyz order?, also tried and failed.
> >
> >> 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 &lt;http://geneslinuxbox.net:6309/gene&gt;
> > _______________________________________________
> > OpenSCAD mailing list
> > To unsubscribe send an email to
> >
> > discuss-leave@.openscad
>
> --
> 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>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
12