Hello
I’m new here and I began working with blender in recent weeks.
I made this couple of gears in Rhino and imported into blender one after another. Now, I want to create an animation. sadly, the perimeters of the two gears are not equal. I don’t know how to synchronize their revolving as their teeth are matched each other accurately, while the numbers of their turning are different
You’ll need to use drivers for this:
hello sir
Sadly I can’t watch YouTube videos due to a network problem. May you explain more?
Basically, a driver is created based off the other gears rotation thus…
DriverExample.blend (1.2 MB)
Hello,
It’s a mix between mathematics and wiring (drivers)
First you need to calculate the speed ratio
If the teeth have the same properties (dimensions) then you divide the number of teeth of the big wheel by the number of teeth of the small wheel.
Second you wire (connect) the rotation of one gear to the other and you set an expression based on the speed ratio.
gearDrivers.blend (973.3 KB)
The number of the big gear teeth is 33 and the small gear is 14 (I specified the numbers randomly in Rhino).
So for every rotation the big gear makes, the small gear makes 2.35 rotations in the opposite direction. You could set the big gear to (press N, go to Item, Rotation) to something like #frame/50 (just copy and paste that into the X Y or Z rotation field). Then your small gear would be #frame * -1 / 117.8
Side note: all those numbers are rounded and will eventually lead to precision errors. For this reason, you should use gear teeth ratios that have prime numbers: variants of 2:1, 3:1, 4:1, and 5:1, for example. In your case, you could get almost exactly the same rotation with a 5:2 setup, and if you want your higher gear to have 30ish teeth, just multiply by 6 to get 30:12. This is a much better ratio than 33:14. You can repeat 30:12 forever with no errors, you’ll start breaking your animation after just a couple rotations with 33:14
Thank you all 
I multiplied 360 by 2,35 for the small gear and the result was 846. thus the rotation ratio of the gears was corrected.
Thank you again
I’m glad you’ve found a solution, but there’s that precision error I was talking about. You have 360 and 846, but (33/14) * 360 = 848.5714285714286…Currently, your rotation will be out of step by +2.57… degrees every full rotation of the bigger gear.
After ten rotations of the big gear, your smaller gear will be wrong by a full tooth-that is to say, the teeth will clip all the way through their adjacent teeth and into a new gap after ten rotations. (360/14- full rotation / teeth = 25.17. 2.57 * 10 ~= 25.17)
Rounding up to 848 won’t help either, it’ll just slow down the error rate. You need prime numbers
Edit: if you use 360 and 848.571, assuming you don’t have any floating point errors (you probably will, but three digits isn’t too bad), that leaves you with an error of +.000428… which will take 62,925 rotations for the full tooth clipping error to occur. It’s still not good enough for any kind of real world use, but it should give you enough wiggle room for your animation.
Bear in mind that doesn’t mean you can get 62K rotations without visual errors- you’ll see errors after just a 2 degree error, so you’ll actually get more like 5000 rotations without any glaring visual errors
Could you keyframe at 0 and 462 (33 x 14), with keyframes at 462 being 33 * 360 and 14 * 360, and then turn off frame snapping and scale to desired length?
Edit: I guess it doesn’t even matter when you keyframe, as long as it’s to those values and the same for both gears, in which case you don’t need to worry about frame snapping.
Probably, that sounds like it would work, but it’s a hacky solution that wouldn’t scale well. OP could do all this rotation with key frames, fixing the error as needed, but why? If OP just used prime ratios, it would be two simple drivers and infinite rotations without errors. See my second reply on this thread for why non-prime ratios will always eventually fail in animation
What about just leaving the math live in your drivers? There’s no reason to use 2.35*var when you can use (33/14)*var. Should leave you only with floating point precision error, always there, which isn’t compounding. The third gear can be driven from the rotation of the second gear, rather than from a primary control.
You all experts are right.
My solution was not systematic and accurate. Because I was not familiar with “drivers” detail and orders, and learning them took time, I had to find a simple and primitive way to resolve my problem in a sole sequence (one turn revolving)
At one turn, that error doesn’t appear, then the clip can be repeated in a player, and the watcher supposes the gears are turning continuously! Of course, there is a small jumping between the repetitions which is a defect.
Nevertheless, what I did was not acceptable in an accurate mathematical, and professional way. Using drivers (by all its facilities) or using scripting is scientific work.
I will try to learn how to use drivers more skillfully soon.
