Feature request: Gearing

[SoerenDaenekas]

Solvespace offers a special kind of drawing experience using constraint based designing.

One feature I found missing though are gears (e.g. translating cogs or converting linear into rotational motion).

Creating mechanical designs like clocks, transmissions or engine attachments is currently not possible or require workarounds.

There are examples where invisible groups are used to approximate gear functionality.

For example:
https://www.youtube.com/watch?v=W0KIwkXv030
https://www.patreon.com/posts/solvespace-rack-78622024
As seen in the downloaded project a quite complicated workaround is used to archive the desired functionality.

In this thread the idea of a cog tool is discussed:
#1211 (comment)
But I imagine that this particular idea might not cover usecases like in the video above.

My suggestion stems from my intend to design an engine-like gear switching mechanism, which it seems like solvespace in its current form is not capable to be used for.

Thanks for considering!

[phkahler]

If I recall correctly, you can make an equality constraint between a line and arc in the development version. Maybe that could be used to couple the linear and angular motion.

[SoerenDaenekas]

There is this tutorial: https://homehack.nl/solvespace-involute-gear/

But I discovered following downsides:

• it is quite laggy
• Rotating either cog more than one revolution results in the restraint engine breaking.
• high speed revolutions break the restraint engine
• quite a lot of work to archive this functionality
• increasing amount of teeth and the teeth distance is finicky. As seen in the tutorial it breaks if the rings are moved too fast.

[SoerenDaenekas]

If I recall correctly, you can make an equality constraint between a line and arc in the development version. Maybe that could be used to couple the linear and angular motion.

That definitly works but it comes with the downside that arcs cannot go beyond 100%. Meaning multiple revolutions aren't possible with this technique

[MayeulC]

As a user, I think the most logical would be to select one or two surfaces, then use a new "gear" tool. It would need the following options:

• Type of gearing: involute at least, more can be added later, such as cycloid, and various kinds of helical gears. Hypoid, beveled, etc. woud be nice to have, but not really a priority.
• Number of teeth for each part
• Module
• Possibly more complex properties, such as angle

Arguably, the most needed functionality is to change the number of teeth to change the diameter of the gear. This is actually led me to finding this issue, as I was designing a complex gear, and found that I could not constrain my circular repetition to finish at the starting point, changing the length of another sketch accordingly. Even if I design teeth in a sketch before extruding, and select circular repeat, I am not able to have them change the diameter to meet at the shaft.

Example

repeat-cannot-resize.slvs.tar.gz

Obviously, this is not an ideal gear profile, but this is good enough for illustration purposes. Making the reference length a constraint (l=0) would over-constrain the sketch, the solver does not realize it can resize the circle to make it work, as there is a degree of freedom there.

---

For assembly, a new kind of constraint may be required for surfaces that do not slip (or with a configurable slippage ratio/angle, to allow for beveled gears, etc).

I think feature requests for that kind of specialized tool to provide a complex but common mechanical interface are their own category: they also include threads, belts/pulleys, and possibly bevels/chamfer, ball bearings etc: though everything is achievable with low-level primitives, these operations/mechanisms are quite common, and can be complex to model. Moreover, it may be useful to have built-in types to make constraint solving faster.
Some plug-in interface may also be a good fit to provide domain-specific helpers: gear design, propeller/impeller design, etc.

[phkahler]

the solver does not realize it can resize the circle to make it work, as there is a degree of freedom there.

No. The degree of freedom (circle diameter) is in the previous group. Constraints are solved one group at a time, holding all previous geometry static. It might let you drag a prior group without going back to it, but that's a convenience. You do have to go back via the text window to add constraints to get zero DoF.

[dgramop]

Hopefully with parameters/relation constraints, gearing will work a little better, since you can specify the rotation logic with a single constraining equation

Screen.Recording.2024-04-12.at.2.17.59.PM.mov

Here's are some screenshots of the sketch

I know it look chaotic, but I have a few extra constraints to name variables that I basically use as constants. The actual logic is taken care of by a point-to-point constraint that converts the angle to an offset

In this image I actually didn't use the hopefully-upcoming relation constraint, but rather named parameters.