Add an internal involute gear

[jbaehr]

Here is a first prototype for internal gears (only involute). This reuses the same (external) tooth profile from pygear but swap some parameters to make the resulting gear internal. In theory, the user could already do this manually, but it requires deeper knowledge and some brain twist as the property names do not match any more.

This prototype is mostly a copy of the external involute gear. Eventually we should refactor this to share more code but this has to be coordinated with the megagrant endeavour. Otherwise later merging becomes a nightmare.

Note that in contrast to the involute rack I chose to base the "thickness" on the pitch diameter, not the root diameter. This has the benefit of keeping the outside diameter stable when e.g. adjusting the clearance. And setting the outside diameter directly could result in an invalid shape when changing the number of teeth. (Eventually we should change the rack, too, but this requires special care because of backward compatibility.)

The default head value of "-0.4" is chosen to match the internal gear profile from the PartDesign WB.

Remaining tasks

• [x] an icon
• [x] Improve performance on internal helical gear. Cutting seems slow, so maybe we can refactor the helicalextrusion to work on a Face instead of a single Wire, to get the internal gear in one go.
• [ ] Look at PartDesign support. Here (and maybe for other workflows in Part) we require the internal gear not as "ring object" as one can buy it, but rather as "cut away tool" for boolean operations. Note This is not included in this PR. It would require "substractive gears", see #74 for more reasoning why this is better tracked as a separate task.

[jbaehr]

Here is a little demonstration what works so far. I recreated the example from Fig. 5-1 on page T23 of QTC Gear's Technote (α = 20° , z1 = 16, z2 = 24, x1 = x2 = 0.5), m = 1 mm, head = 0, clearance = 0.25, backslash1 = 20 µm, backslash2 = 50 µm:

internal-external-gear3.FCStd.zip (sorry for zipping the FreeCAD-file again, but GitHub does not allow .FCStd files as-is)

[luzpaz]

@jbaehr ping

[jbaehr]

@luzpaz tl;dr: Still working on it; slowly, but steadily.

I'm currently trying to create the helical variants without using boolean cut operations. Those are quite slow an suffer from coplanar issues. However, sweeping a two-wire profile (one with a hole) does not work with Wire.makePipeShell (that's what's currently being used). Various experiments with building the solid manually (i.e. sweeping only the teeth profile and then using Part.makeShell and Part.makeSolid) failed.

My current approach, with Part.BRepOffsetAPI.MakePipeShell, looks promising; basically what PartDesign's sweep does. It is more complex than initially thought and I'm still learning. (and I can only spend a few hours per week)

[jbaehr]

@looooo within the constraints of the PR's description, I consider this now ready for merging. Please tell me what you think.

I'm not aware of backward compatibility issues. However, commit a9be51c may result reordered geometry, thus potentially triggering a "TPN issue" for those who based features on gear faces directly -- That's the trade-off for enabling future development and a 5x speed up for all double-helical gears (commit 84d4fb5).

[looooo]

looks good. I see some issues with the boolean operation (see attached image). Also I think a internal gear should be a sperated command. I guess we can create a menu bar for "derived" gears. Also it would be nice if you can work on the megagrant branch as there are some additional properties for the involute gear which are not yet available in the master-branch.

Anyway, many thanks for your contribution.

[jbaehr]

I see some issues with the boolean operation (see attached image)

At a first glance this looks like the coplanar issue my first (and awfully slow) implementation had. Are you sure your clone is up to date (i.e. HEAD is at 84d4fb5)

[looooo]

Sorry, you are right. This looks very promising. Thanks for your contribution.

I will try to merge this PR into the megagrant branch as there are some additional things there (root / top fillets) that are also useful for the internal-gear.

[looooo]

@jbaehr if possible, please checkout the megagrants-branch if everything is working as expected. This branch includes the head and root-fillet parameters.

Also i beg to work on the megagrants-branch if you have addional changes. I would like to let the master-branch in the current state and replace it with the megagrants-branch. This way we do not have to care about backwards-compatibility a lot.

[jbaehr]

I will retarget the feature to the develop branch.

[jbaehr]

I will retarget the feature to the develop branch.

Hey, I've just seen you already did that. Cool, thanks. I guess we can close this PR now (because you cherry-picked gitlab didn't notice the commits are actually in already).