freecad.gears icon indicating copy to clipboard operation
freecad.gears copied to clipboard

gear train (or gearbox module)

Open kcleung opened this issue 8 years ago • 6 comments

It would be great if we can have a gear train / gearbox module, where users can quickly specify:

*the number of gear axles

  • for each axle, number of gear on that axle, and whether the gear is fixed on the axle, slide on the axle on groove, or freely rotating on the axle on a bearing
  • distance between each axle

This would allow a gearbox or at least a gear train to be created very quickly.

kcleung avatar Jun 24 '17 09:06 kcleung

I thought about it already. But I don't know how to handle this. I think it's better to wait for an official assembly module, and see how to best implement something like this.

looooo avatar Jun 24 '17 17:06 looooo

Totally agree. We should wait for an official assembly module. However, as mentioned in issues #8 and #9 , to enable the gear train module to do its work, it is essential to implement internal and external gearing on a single gearwheel, and to enable double helix.

Is double helix the lowest hanging fruit? If so, should we start with double helix first for involute and rack?

kcleung avatar Jun 24 '17 20:06 kcleung

Have you been following the development of the Container data type, which stores a local coordinate system, and allow recursive containers. This will allow subassemblies very easily, and therefore make it possible to implement our gear constraints, and gear assemblies

https://forum.freecadweb.org/viewtopic.php?f=20&t=22077&start=90#p180924

I am in the process of rebasing DeepSOIC's branch

https://github.com/DeepSOIC/FreeCAD-ell ... Container1

to the current master

https://github.com/kcleung/FreeCAD/tree/ActiveContainer

, which he stopped working on it two months ago, and hope to complete the last bit of work and make it ready to be merged into the master, but the rebasing was hampered by some changes in GroupExtension which I don't completely understand, that breaks the recursive nesting and fails the recursive container unit test as described in the above thread. When you have time, could you please have a look?

kcleung avatar Jul 04 '17 10:07 kcleung

Actually I am wondering why you would like to take the container approach. Why not simple use a FeaturePython object and add the gear as a PropertyLink + use the claimChildren method to visually place the gear as a child of the adapter. In my opinion there is always only one gear adopted by one adapter. So no container is needed.

looooo avatar Jul 10 '17 08:07 looooo

Actually, when I wrote the last comment, I had misunderstood the Container. As explained in:

https://forum.freecadweb.org/viewtopic.php?f=20&t=22077&start=100#p181138

Container is merely a wrapper for selecting active items and groups to make the UI more efficient, and has nothing to do with the actual data structure. The relevant data structure for assembly (and our future gear assembly) would be FeaturePython, GeoFeature and GeoFeatureGroupExtension, all of which are already in src/App. Am I correct?

So each instance of a gear will be a Part, and then according to:

https://www.freecadweb.org/wiki/Assembly_Basic_Tutorial

each subassembly will be a Product, though the Product data type doesn't seem to have been implemented yet.

kcleung avatar Jul 12 '17 20:07 kcleung

Dear @looooo and @kcleung I may not know what you are talking about regarding assembly modules, subassemblies, containers, and features.

I am currently considering rebuilding a 3d printable gear for a clock. I have already looked at geargenerator.com by Abel Vincze which has an easy to use interface to create simple 2D gear trains / boxes using some really interesting relationship between individual gears. Usually the half pitch diameters are used for mounting the two gears next to each other.

The relations are simple:

  • parent gear #
  • connection angle
  • axle connection

Though I would probably need some extensions for real 3D gearboxes at least the following come to mind:

  • thickness of each gear
  • z-level / value for mounting them in different heights on a spindle / axle
  • similar to axle connection a common center could be useful, e.g. for aligning the final drive gears for the individual clock handles
  • fixing an axle on another gear would be required for some differential gears
  • arbitrary pitch diameters to create gears between two shafts
  • common request on the message board was alignment of bevel gears or worm gears too.

I think @Foadsf in #33 already described something like this in a more formal / mathematical way already.

stefan123t avatar Jan 02 '21 21:01 stefan123t