freecad.gears
freecad.gears copied to clipboard
gear train (or gearbox module)
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.
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.
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?
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?
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.
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.
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.