Every time the InvoluteGearFeature python module was imported, and we're
in GUI context, the command "PartDesign_InvoluteGear" was registered. On
the 2nd (3rd, ...) time, this was reported as an error in the console,
like "error: Command.cpp(1841): duplicate command PartDesign_InvoluteGear"
The first import happens when the PartDesign FreeCAD Module is loaded,
via `InitGui.py`. Subsequent imports may happen when e.g. executing the
involute gear command or when running it's tests via FC's Test WB.
This change now registers the command only then the PartDesign WB is set
up in InitGui, not when importing the python module. The same fix is
applied for sprocket, where the same pattern for command registration
was used.
In addition, the import error catch was removed, which seems to be a copy
paste left-over from the ShaftWizard. In contrast to ShaftWizard,
involute gear and sprocket only use modules from the Python standard lib,
so I think this precaution is not worth the additional complexity, just
for hiding actual errors.
Since Py3.11 the methods names __setstate__ and __getstate__ conflict with the method names added to the object class.
Thus rename them to 'loads' and 'dumps'
This commit adds the ability to shift the involute profile inside or
outside. Profile shift is implemented as coefficient, i.e. normalized by
the module, so that it the whole profile scales with the module without
chaning shape.
To verify the profile, the tests implement an "over pins measurement"
using formulae found in literature.
Backward compatibility with FreeCAD-v0.20 is garanteed by already
existing tests, not touched by this commit.
This addresses issue #5618.
This makes use of the recent additions to `TaskPanelPython` and
`UiLoader`, cf. #8602, to retranslate the UI without having to close and
reopen it again.
Retranslation of the part from the UI file is now handled by FreeCAD
internally, but the tool tips from the property descriptions still need
to be reassigned with the translated versions.
As the property descriptions are translated at a central place in the
GUI, we have to use the generic "App::Property" category.
For details see https://tracker.freecadweb.org/view.php?id=0002524
As the property docs are also used as tool tips in the InvoluteGear's
task panel, this is also needed to achive a fully translatable GUI.
In order to not maintain the same information in two places, the property
docs are reused as tool tips for their input fields. And for user
convenience, the same tool tip is assigned to the respective label as
well.
The original implementation always took 150% of the addendum/dedendum
difference as fillet radius. For a standard full-depth system this
results in a normalized value 0f 0.375, which is pretty close to the 0.38
definded by the basic ISO rack. However, when using much shorter teeth as
e.g. required for a splined shaft, the fillet becomes way too large.
In addition, I don't understand the approximation to calculate the
distance between the gear's center and the top of the fillet yet. It was
only refactored to allow the custom fillet radii, but it retuns the same
values as the original implementation.
However, with high pressure angles, up to 45° used for splines, this
approximation comes to its limits.
Exposing the addednum and dedendum coefficients as properties allows to
change the tooth length above and below the pitch circle. This makes it
possible to use the profile beyond standard full-depth systems, e.g. for
stub tooths and most importantly: involute splined shafts and hubs.
Gear objets created with earlier versions automatically get the
additional properties on document restore. Its values match the hard-
coded values used in earlier versions.
There is a change when creating *new* internal gear profiles, though:
Previously, an addendum coefficient of 0.6 was used, presumably to reduce
the tip length beyond the base circle in order to avoid a non-involute
edge. This method is one proposal from the "Handbook of Gear Design" by
Gitin M. Maitra, as referenced in the original source code comments.
However, Maitra also states that this reduction of the anual gear's tip
in turn requires an enlagement of the mating gear of 1.25 instead of the
ordinary 1.0. And it is only required for a low numer of teeth and/or the
mating gear being quite large (less than 10 teeth in difference, to avoid
interferences).
Because those additional requirements and conditions have not been
implemented, the previously used values have been incomplete anyway. Thus
I decided to not implemented this special case and use the standard
values of 1.0/1.25 for newly created external and internal gears alike.
Internal gears need special care for other kind of interference anyway
and the newly exposed properties now allow to do so.
There is no entry in the task panel for those advanced properties yet.
This is a pure refactor, without any change in visibile functionality.
However, the new structure allows easy addition of new properties without
breaking existing documents.
