Animate a reciprocating rack

I am attempting to animate the motion of this design. I have done a fair bit of tinkering and searching. I have got it to move the rack with the rotation of the gear using constraints. But, am at loss as to how to get the rack to reverse direction as the gear continues in the same direction.
Mostly I’m looking for words that would describe what tools/methods would be used so I can go off and do more searching since I’m not sure what to search for.

Hey @drmacro,

It’s been two weeks since you asked about this, so you may well have successfully found a solution :slight_smile:

If not, I’ve had some fun looking into this, and though I wouldn’t consider these the only methods, they are the ones that struck me as most obvious.

First off, some animation as a demo:

By far and away the quickest is just to keyframe - a la the first example, and add a repeat modifier in the animation curves if needed. Or make an animation Action and build the repeats as a sequence in the NLA.

The downside is if you want to have a variable rotation rate on the gear you’ll need to match by hand the reciprocating rack. Which may, or may not, be tedious. It is however only a total of 5 keys, 2 for the gear and 3 for the rack.

The second method uses Geometry nodes - to say this is not ideal is an understatement. Although it works, it is not straightforward because you have to use mathematical operations to perform logic steps. As you raised in your post, it’s the reversing of the rack direction that is the tricky part.

Rather than use the Sine or Cosine functions ( computationally expensive and not linear ) I used a conditional on whether the gear has passed through Pi radians ( 180 degrees). However, Geometry nodes don’t allow ‘true’ branched logic. All branches are evaluated, whether you want the resulting value or not, so it’s necessary to zero out ( via a multiplication by 0 ) any values you need to nullify, which is where the use of comparison value ( x < y ) is employed. But because both branches would use the same result you then need to invert one branch which turns a 1 into a 0 and that clears the value. Convoluted to say the least.

The up side, at least in my demo, is that the geometry node has a value input ( outlined in red on the right) that allows you to specify over how many frames the gear rotates a full 360 degrees. However, because the animation is frame-time derived it’s purely linear, and goes on for as many keys as you have. In the animated example I’ve set it to 60 frames and so it repeats automatically 3 times over 180 frames.

Finally, sanity prevails when you get to drivers, though you’ll need to use python as you still need a way to make a branching decision on the angle of the gear:

The logic in the python code is the same as the geometry nodes, but considerably less hassle to write :slight_smile:

For me this would provide the best option - requiring just key-frames for the gear ( any way you please ) allowing for repeats, curves to control rotation rates etc.

In the animation example it has an ease-in and ease -out as the gear slows as well as a delayed start.

If you want to examine my file it’s attached below, I’ve named the boxes in the Geonodes as best I could to match the logic/names I’ve used in the python code, if you’re inclined to see the ‘translation’.

The driver code does not run automatically, you’ll need to select the rack ~ script ~ play ~ update dependencies - 1,2 and 3 in the screen shot above.

Hope there’s something in there of interest/use. I should also point out I’ve not used any sensible units for the sizes of the rack or gear so the magic number ( 1.69551 ) is the half circumference of the gear, as this is critical in how far the rack moves. If you plan on doing anything similar I’d build the maths of this into the equations so you could have that taken into account automatically.

Finally, in case you ( or anyone else who’s read this far ) is wondering where I sourced the reference it’s:-

which is an excellent resource for these incredibly inventive mechanical movements.


attached file:
ReciprocatingGear.blend (1.0 MB)



I’ll definitely have a look at your blend file and try to understand your methods.

In the mean time, I did get it working with Animation nodes.

At this point in my learning curve, I know of keyframes and geometry nodes, but, have not spent time on them yet.

And, you are correct about the source. The image in the OP is from a reprint of the actual book. :wink:

Seems something is wrong on my end with your file. Rack is invisible, and apparently the Python isn’t happy. (I’m not savvy enough to see the obvious, probably.)

I made this with Blender 3.1.2 is your version the same ?

On this PC it is 2.9…something.

I have 3.1 on my other box, I’ll have a go there.

That was it. Thanks.

1 Like

I would love to read tutorials from each of you about how you set out to solve this problem.

Doesn’t matter “which is best,” but rather, “how many potential solutions are viable.”

1 Like

Well done guys !
Indeed it’s quite interesting to see different approach to the same problem,
I’ve tried something… as the issue is already solved 4 time, I was a bit lazy and didn’t polish it as you did…
driver.blend (139.4 KB)

The idea is to drive the translation by the rotation, and tweak the driver’s curve accordingly.

So it’s simpler but it may take a bit of time to get the right curve that correspond to the right translation. I didn’t take the time to polish it, but I’m sure it’s doable with a bit of coffee !
It’s probably better to go with another solution more accurate anyway…

1 Like