Creation of Splines?

[goldfish1974]

Hi,

Great library. I was wondering how I could also use this library to create splines (e.g. Gear on a shaft, not the Gfx construct of a Spline.)

I saw on Issue 4, a question about exposing the tooth profile. If there are not a suitable set of parameters, then would the optionally exposing of a an array that allows the tooth profile to be passed in, along with the default array calculation (much like the herringbone() function does for the helix) be a suitable way this could be implemented?

I'm happy enough to take a look at this an refactor the code. A bit of guidance would be helpful as to the location where the tooth profile is calculated.

I've forked your repo in preparation of getting this done.

Thanks

[dpellegr]

Hi,

the motivation for writing PolyGear came from the handling of involute curves which is absent in native OpenSCAD.
To my knowledge splicing only requires rectangular (or trapezoidal) teeth which are pretty straightforward to create in OpenSCAD, for instance:

use <shortcuts.scad>

linear_extrude(5) rotN(N=12, r=0) MKy() polygon([[4,0],[4,1],[6,0.5],[6,0]]);
cylinder(r=5,h=5);

This may already save your day, but the actual answer to your question is below.

PolyGear is a proxy to OpenSCAD's polyhedron function which takes a list of points and a list of facets to construct a solid. All that PolyGear does is providing these two lists.
The list of points is arranged as sections of the gear perpendicular to the axis. For zero-helix gears only two sections are necessary (top and bottom) but for the general case there will be more.
The function that spits out a section (as a list of points) is:

PolyGear/PolyGearBasics.scad

Line 28 in 777a046

function gear_section (

That is the one that you will need to rewrite (or extend) to implement non-involute profiles.

For debugging purposes this module is also very useful:

PolyGear/PolyGearUtils.scad

Line 117 in 777a046

module draw(pts, size = 0.1) {

as it allows plotting labelled point lists with zero effort, for instance, using all default values:

use <PolyGear.scad>
draw(gear_section());

As a closing remark I would add that I think that modifying the library just to accomplish straight teeth (which can be easily done in OpenSCAD) seems an overkill. However, if done properly, such effort would definitely not be wasted as it would open up the way to implement multiple profiles, some of which could be non trivial, for instance cycloids.

[goldfish1974]

That'll be really helpful info. Thanks for that.

Like all things in life, there are multiple variations of splines. There's the basic straight tooth method you mention above (parallel key spline), but there is also involute splines and helical splines.

The main reason for involute splines is that it distributes the stresses across the tooth. This project seems like a nice logical home for involute and helical spline generation as the current generation of helix profiles and involute curves seems like a great start. The main difference with the involute spline is slight differences at the root and tip of the teeth, along with the matching mating surfaces.

I plan on using this in a 3d Printed project and since the print time will remain the same for any form of spline, why not!

A quick summary can be found on Wikipedia: https://en.wikipedia.org/wiki/Spline_(mechanical)

P.S. I printed a few sample herringbone gears with different module values. Very nice meshing.

[goldfish1974]

I have a working version of the functions within PolyGear.scad that allows for the optional injection of a function that provides the tooth profile.

I added a parameter that defaults to undef (to spur_gear/bevel_gear/bevel_pair) and if no override function is passed the code falls back on gear_section() to construct the profile.

The implementation required OpenSCAD 2021.1 to work though as it relies on function literals. I don't think this could be implemented prior to this version. More info here: https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules#Function_Literals

There is also (what appears to be) as bug in the implementation of closures as the parameter names of the plugin function needs to have the same name as those used within the functions of PolyGear.scad. I presume this has something to do with the way OpenSCAD is searching the scopes of the calls looking for parameter names OR the way that OpenSCAD compiles the file into the final form. There is info about the last value that a parameter is set is the value used at runtime in the OpenSCAD docs.

Before I prep a pull request for these changes, I'll implement a "cycloids" function. I'll implement this and then update the PGDemo() call at the top of the PolyGears.scad file as a suitable demo it it's use.

Once I've addressed the override of gear profiles, I'll move onto adding the needed bits for construction of different splines.

Do you have any objections if I add these as top level calls into PolyGears.scad as there may be some differing parameters to define each of the different styles of splines?

[dpellegr]

I added a parameter that defaults to undef (to spur_gear/bevel_gear/bevel_pair) and if no override function is passed the code falls back on gear_section() to construct the profile.

Looks like the way of doing it! We can also rename gear_section() to involute_gear_section() in case more of them get added.

The implementation required OpenSCAD 2021.1 to work though as it relies on function literals. I don't think this could be implemented prior to this version. More info here: https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules#Function_Literals

Oh, they added lambdas, nice! Yes, if the implementation benefits from new features of the language, I am always prone to adopt them to keep the code base as simple as possible.

Before I prep a pull request for these changes, I'll implement a "cycloids" function. I'll implement this and then update the PGDemo() call at the top of the PolyGears.scad file as a suitable demo it it's use.
Once I've addressed the override of gear profiles, I'll move onto adding the needed bits for construction of different splines.

This would be super nice, but if your priorities are particular profiles for splines you can just focus on that.

Do you have any objections if I add these as top level calls into PolyGears.scad as there may be some differing parameters to define each of the different styles of splines?

As the splines are somewhat a special case/application I think it would be cleaner have them in a new file which can use or include PolyGears.scad. This will help readability, especially if you adopt the format that I used in PolyGears.scad where the top level modules self-document and come with a whole new set of default values for the most common applications.