Automatic gear alignment tool in WB

[J-Dunn]

Hopefully at some stage aligning two parts can be automated: select two gears ( or rack+gear ) ; click on an icon and they snap into mesh with each other. That would be pretty cool. Setting the perpendicular distance to the gear radius ( or sum of radii in the case of 2 gears would be pretty simple to code ). Then adjust the rotation to this line to set the teeth.

[looooo]

I made the first prototype in the develop branch. As we had some discussion on this you might want to check this out @jbaehr . You simply create 2 involute gears, select them and use the new gearconnector (blue icon) to connect them. Once the gears are connected you can use the two properties (value1, value2) to rotate the gears.

This is only a prototype. But it would be nice to get some feedback on this functionality (if you have some time for testing).

[looooo]

[J-Dunn]

Looks nice. I'm pretty busy right now but I'll try to give it look once I've got the current job out. ( It's expected to be finished tonight, as I've been telling myself for the last week.

[jbaehr]

This is only a prototype. But it would be nice to get some feedback on this functionality

Such a "connector" can be a nice thing for some quick demonstration of gear meshing. For "real world" projects though, have my doubts whether the approach of "click on an icon and they snap into mesh with each other" is really helpful: The positioning of two gears is rarely an independent operation. Usually you need to position your gears in some support. To design this support structure I don't see how such a connector helps.

My workflow is the following:

1. I have a spread sheet with the required ratios, number of teeth, etc.
2. In my gear objects (as features in individual PartDesign Bodies) I reference those values via expressions.
3. To design the support, I use Sketches where construction circles reference the pitch diameters calculated by the gear objects. Applying tangent constraints on those circles allows me to position e.g. holes for the shafts.
4. Finally I use Assembly4 put everything together.

My idea is, from the conversation @looooo mentioned, to introduce some "gear paring" objects, which encapsulate all the gear-specific calculus and expose the results as properties. Those can then be referenced in expressions in various places, e.g. sketches, attachment offsets, asm4 links, drive animations, etc. I consider this approach more universal/flexible then a "gear connector" which already performs the placement (similar to the InvGears workbench). I must confess that it's way more complicated to use, though. So I can imagine that both ways can happily coexist: One as a ready-to-use solution for a limited use case, one as a universal building block with limited ease-of-use. (and under the hood both can share a common implementation.)

Here is an excerpt from by notes (which grow much faster then my time to work on this)

"InvoluteGearPairing"

An "App::FeaturePython" doing the calculus for a pair of mating gears.

• calculate the "Working Foo" (Foo = Pressure Angle, Pitch Diameter, ...) in case of profile shift
• calculate the center distance
• calculate actual gear ratio based on given Z1/Z2
• calculate the actual transmission ratio (inverse of gear ratio, and negative if in opposite direction)
  • in case the mate is a rack, we don't have a unitless "ratio" but rather something with "mm/°" as unit
• different "modes", e.g.
  • calculate center distance based on given Z1/Z2 and m (and shift x1/x2)
  • calculate m based on given Z1/Z2 and center distance (and shift x1/x2)
  • calculate Z2 based on given Z1 and "wanted" gear ratio (actual gear ratio may differ because Z is integer)
• different gear pairing objects: "Gear and Pinion", "Annular Gear and Pinion", "Rack and Pinion", "Wheel and Worm" ... (or "Gear/Pinion", "Rack/Pinion", "Annular/Pinion", "Wheel/Worm", or "External", "Rack", "Internal", "Worm") Assume the pinion as driver in all cases (apart from "worm", obviously) For the pairing with internal, interferences could be calculated, see https://gearsolutions.com/departments/tooth-tips/internal-ring-gears-design-and-considerations/
• distribute profile shift for various needs: https://drivetrainhub.com/notebooks/gears/geometry/Chapter%202%20-%20Spur%20Gears.html#Distributing-Profile-Shift

Maybe even for planetary, i.e. three gears (sun, planets, annulus), not only two

---

So, long post with a lot of brain-dump without specific feedback to the gear connector itself, sorry for that. But finally I have one specific wish: Instead of "master/slave" gears, I suggest "driver/driven" gears ("pinion/gear" or "pinion/wheel" would also work, but it somewhat implies that the driver is the smaller one).

[J-Dunn]

"pinion/gear" or "pinion/wheel" offers a false distinction without conveying any pertinent information. driver/driven is semantically useful but so nearly identical as words that you need to constantly re-read to check which is which.

Master/slave does convey the functional relationship and the main objection seems to the fad for "politically correct" speech which has tried to remove this terminology in other fields like computers. So I suggest you keep politics out of gear design and stick with clear terminology, before some idiot starts to suggest that "driver" also has an unwelcome similarity to "slave driver" and may be offensive to someone who is not here and never will be here and probably would not be offended themselves if they were.

Otherwise, jbaehr's breakdown of the design process is very helpful.

[jbaehr]

"pinion/gear" or "pinion/wheel" offers a false distinction without conveying any pertinent information. driver/driven is semantically useful but so nearly identical as words that you need to constantly re-read to check which is which.

Indeed. And even more: The positioning is completely independent of the torque flow. So "base gear" or "supporting gear" and "attached gear" would better match the functional relationship. (In FreeCAD you "attach" something to a "support")

Master/slave does convey the functional relationship and the main objection seems to the fad for "politically correct" speech

I cannot see any obvious, gear-related, functional relationship in "Master/Slave". It's also not a matter of "fad" for political correct speech, it's a matter of striving for a non-discriminating language. But I know, it's always easy to mock as long as one-self is not concerned. Eventually, everyone has to find its own balance here.

Anyway, back to topic: The more I think about the "gear connector", the more I come to the conclusion that it would better be a command only instead of a document feature in the tree. FreeCAD comes with all you need to position two gears relative to each other and based on the gear's properties: The attachment engine and the expression engine. Gear objects are attachable and they expose all the properties needed to calculate a meshing placement; you can do it manually, if you know the formulas. So all that's needed is a command to set this up. That is

• Set the attachment support of the "gear to attach" to the "gear to attach to"
• Set the attachment mode to "Object's X Y Z"
• Set expressions for the attachment offset of the attached gear, e.g.
  • set the X value to the expression "involutegear.dw / 2 + dw / 2" (assuming "involutegear" is your support)
  • set the Angle to the expression "360° / teeth / (2 - teeth % 2)" (with an even number of teeth you need to turn half a teeth to mesh with the other, assuming it's located on the positive X axis. With an uneven number, this turns by a full teeth, which is a no-op in terms of meshing)

You have even more freedom when you do not position your gear objects directly, but a container with a coordinate system (e.g. Std_Part) which contains your gear. All this knowledge can be coded behind a button, so a user just has to select two gears (or two container which each contain a gear), press that button and the attachment is set up. This button could also offer a task panel to configure the attachment in more detail, e.g. an angular offset from the X axis or which gear to reference (in case the container contains more then one, e.g. when the container is PartDesign::Body with a stepped gear)

And to change the attachment (using the same task panel) just selecting the attached gear is enough, as the attachment support is already known. Maybe it's even possible to register a user edit mode from a python workbench (no idea on that, but it would be pretty cool)

What do you think? This could make the tool more versatile compared to a document object which claims the gears as children -- I assume this would break down when your gears more deeply nested, e.g. in PartDesign Bodies, Boolean operations, or anything else that also claims the gear as child.

[J-Dunn]

The positioning is completely independent of the torque flow. So "base gear" or "supporting gear" and "attached gear" would better match the functional relationship. (In FreeCAD you "attach" something to a "support")

Base gear sounds good. In the process of constructing the geometry of the model, the mechanics of what the physical object does or the torques involved are irrelevant.

[looooo]

I cannot see any obvious, gear-related, functional relationship in "Master/Slave". It's also not a matter of "fad" for political correct speech, it's a matter of striving for a non-discriminating language. But I know, it's always easy to mock as long as one-self is not concerned. Eventually, everyone has to find its own balance here.

It's only a prototype. Thanks for this input. I took this idea from the invgears-workbench. The current implementation to couple gears is for sure not the way to proceed. I am currently thinking about a planetary gear system. Some interesting solutions are already posted. https://forum.freecadweb.org/viewtopic.php?f=24&t=64354

I guess gathering more information about the possible ways to align gears is currently the best option.