The MCAD library that is part of OpenSCAD is not a bad place to start
(https://github.com/openscad/MCAD).  I've found a few bugs (and
submitted a few patches :-) in it (specific issue about pitch diameter
being calculated incorrectly) but largely works for me (TM).

Hope that helps,

• Rob
  .

On Thu, May 30, 2019 at 9:42 PM jon jon@jonbondy.com wrote:

Rob:

Thanks!

When I specify gear(800 teeth, 5 pitch, and 3.5 clearance), I get a gear
that is only about 20 mm in diameter.  800x5 implies a circumference of
about 4 meters.  I must be misunderstanding the parameters

Jon

On 5/31/2019 1:36 AM, Rob Sherwood wrote:

"official" library.

It seems like doing a "proper" gear library would require going through
something like Machine's Handbook for guidance on clearance calculations and
such.

--
Sent from: http://forum.openscad.org/

Fwiw, with the proper bug fixes in place, I've been able to properly mesh
the involute gears printed with the MCAD library with gears printed from
other tools (e.g., Fusion 360's gear library).  See
https://github.com/openscad/MCAD/pull/29 for an important stack of bug
fixes which would be nice to be merged :-/

But at least for my own work, I hack (sigh) around this issues by adding a
wrapper function that undoes the bugs (and a fix to properly calculate
helix angle to the gears).  See the note below in my example code, but you
should be able to get correct gear sizes by multiplying the pitch by 180/PI
to fix the long standing bug.

As for using the calculations from a solid reference, that's effectively
what the gear library does... except there's a bug.

Also see my question about a maintainer for MCAD libraries :-)
https://github.com/openscad/MCAD/issues/32  Maybe with the new release
(whoo!) of openscad, it's time to clean up the MCAD libraries too?  I can
try to help a bit..

Hope this helps,

• Rob
  .

use <MCAD/involute_gears.scad>  // for involute_gear()

module robs_gear(number_of_teeth,        // must specify
modulus,                // must specify, SI units for pitch
// my defaults
backlash=default_backlash,
gear_thickness=5,
bore_diameter=0,
left_gear = false) {
twist_dir = left_gear? 1 : -1;
// 'twist' adjusts the angle with the height, while helix_angle
// is a constant angle.  Use this formula to translate.
opposite =  tan(helix_angle) * gear_thickness;  // opposite of triangle
diameter = number_of_teeth * modulus * pi;      // pitch diam of gear
// ratio of opposite / diameter = twist / 360
// solve for the twist gets you...
twist_refactor = twist_dir * 360 * opposite/ diameter;
;
// call the library from MCAD/involute_gears
gear(number_of_teeth=number_of_teeth,

•     // this library incorrectly divides by 180 instead of pi in a
  

  // critical calculation.  If broken_gear_lib is 1, then reverse this!
  circular_pitch=(modulus * pi * broken_gear_lib * 180/pi ),*
  twist=twist_refactor,
  backlash=backlash,
  gear_thickness=gear_thickness,
  rim_width=100,  // TODO: figure out how to make this go away always
  rim_thickness=gear_thickness,
  hub_diameter=0,
  hub_thickness=0,
  bore_diameter=bore_diameter
  );
  }

On Sat, Jun 1, 2019 at 3:44 AM NateTG nate-openscadforum@pedantic.org
wrote:

capveg wrote

The MCAD libraries need more than a "clean up" to be a valuable tool.  When
I came to OpenSCAD I asked the question here, "where are the libraries" and
the prevailing answer from the vocal responders was "We don't need
libraries.  Just write stuff yourself."  Maybe this explains the dismal
state of libraries for OpenSCAD.  What OpenSCAD needs (for the rest of us
who want to use a library) is a well written, well organized library that
extends its capabilities.  MCAD is a disorganized amalgamation of a bunch of
random stuff, not a coherent and complete extension of base OpenSCAD.  It
does not seem like a good starting point for coming up with a good library,
and certainly is far from being a good library as it stands.

I surveyed all the libraries I could find and concluded that BOSL was the
library with the most promise.  It tries to do what a basic foundational
library should do, and then adds a bunch of other interesting stuff beyond
that.  It is actively maintained, well documented on its wiki with lots of
examples, and work is underway to make an even better version in BOSL2.  I
suggest that it would be better to take a look at BOSL and help make it
better rather than trying to somehow fix MCAD---I think the latter would be
wasted effort given that a much better option already exists.  (If you find
a bug it actually gets fixed, and if you want to make suggestions for major
additions or changes to BOSL2, the maintainer is listening.)

https://github.com/revarbat/BOSL/wiki

Note that BOSL2 was started to break free from backwards compatibility with
BOSL and it is unstable now, as the interface is being modified to make
things more uniform and to make some new features better integrated.  So
it's the place to look if you're interested in development, and where things
are headed, but not if you want a stable library that will still run your
model next month without changes.  This means that now is the time to make
proposals if you think there's something that should be really different.

https://github.com/revarbat/BOSL2/wiki

--
Sent from: http://forum.openscad.org/

I'm all for trying to find the Right Thing and am happy to apply my own
personal elbow grease to what ever the consensus happens to be.

That said, if folks follow the thread in the
https://github.com/openscad/MCAD/issues/32 issue task, a few meta issues
came up:

1. If we do libraries, do we need to also do package management?
2. What is the right way to create an automated test to verify that the
   library is doing what it claims (e.g., is the generated gear the correct
   size)?
3. [didn't come up, but should have] How do we do name spacing, e.g., so
   that my library doesn't use names that conflict with your library?

My take is a lot of these problems seem like re-inventing the wheel to me
and may be harder to solve in openscad than is worth investigating, but I'm
happy to be proven wrong.

• Rob
  .

On Sat, Jun 1, 2019 at 3:54 PM adrianv avm4@cornell.edu wrote:

On 01.06.19 14:53, adrianv wrote:

How about we stop throwing around all those negative claims of
things supposedly being useless or wasted effort? That includes
your dismissal of MCAD in a voice that is probably offending a
bit to those who wrote some of the scripts maybe 10 years ago
when OpenSCAD was still in its infancy and are still around here
reading those statement. Do you think that gets anyone motivated
improving things?

MCAD was abandoned years ago and for some time is now slowly
maintained by hyperair, but one person can do only so much.
Getting this kind of "support" I see here lately is not likely
to provide much motivation to improve things.
I certainly appreciate whatever time is spend on improving
things even if it goes slowly. And there are fixes getting in
in both MCAD-master and also the development version which tries
to improve in a more general way.
https://github.com/openscad/MCAD/commits/master
https://github.com/openscad/MCAD/commits/dev

So what I'm asking is simply to not bash things one does not prefer
to use. A question of "can you suggest a library" does NOT need
to start with "MCAD is crap, ... use ...". Praising the nice lib
will give anyone reading that (maybe much later on the forum) the
same information without the negative comments littered around.

That said there are awesome newer libraries around that are nicely
documented and maintained. That includes BOSL and also dotSCAD and
maybe (hopefully) BOLTS which seems to get some updates again.

To bring that rant to end with a hopefully positive note, let me
also ask for other libs that fit the "very useful and well documented"
label and I will put together a list to put on the OpenSCAD website
(Note: Initially I'm only interested in libraries with a FLOSS
license). I'll create a new topic for that, lets see if we can
collect some that are not yet widely known.

ciao,
Torsten.

On 01.06.19 15:09, Rob Sherwood wrote:

Why concensus? I don't believe that is need and I suspect it will
not be possible to get everyone to agree anyway.
I think it's great to have multiple options with maybe slightly
or very much different focus to select from. This also ensures a
more stable eco-system in general.

I'd say have a look at the different options and go with the one
you like best. That usually is also a good base for more long term
motivation.

Yes, I think we do.

MCAD uses pytest to do some simple verification, OpenSCAD has the
graphics output based test framework. Both together could be a
very powerful tool. Right now it's not written to be used in some
different project, but that is certainly a possibility.

I have not seen any common way to do that yet. Some libs use a
simple prefix. The solution mid/long term is certainly to support
namespace in the language but so far there's not much detailed
discussion how to do that in compatible way.

I'd agree with that in general. However there might be always
some incentive to re-invent the wheel as can be seen in other
similar areas too (like ECAD symbol/footprint libraries). This
does depend on the setting the things are used in. For an EE
professional it's sensible to create their own symbol/footprint
libraries along the way as they then have only themselves to
blame if things go wrong. For the casual KiCAD user like me the
nice included libs are very welcome.

ciao,
Torsten.