GearGen VB script (and others)

Hi all,
I was recently reminded there was a condition inside the GearGen script which tested for Rhino versions and caused the script to stop working on V6. This condition has been removed. The script itself is the same (not a new version). It can be found -> GearGen new location <- under Rhino scripts.

EDIT: The gear limit was also raised to 1000.

NOTE: It came to my attention that a while ago (Varvara Toulkeridou), but together a fantastic tutorial: GearGen tutorial


Could you adapt the minbox also, please?

ok, removed version checking from all the scripts.

1 Like

There was a complaint about the gear teeth limit in the script, so it is now bumped up to 1000 teeth.
GearGen new location

I was also made aware of an excellent tutorial authored by Varvara Toulkeridou --> GearGen tutorial. It is humbling to realize how much I could have explained and didn’t.

1 Like

I want to use geargen in version 6 so that my students can cut gears on a laser. This geargen will work for V6???

As Thomas writes in the first post in this thread, he removed a limitation so that it will run on RH6:

Spotted bob Ks video on geargen so will try

I was going to update the script to python, but it is too trivial and got bored (just porting something that’s already functional).

Then I had the ambition of expanding it to include non-circular gears turning any curve into a gear, but the math gets hairy and got intimidated. The problem splits in two: a) generating computationally a mating pitch curve and b) generating tooth profiles on arbitrary curves. So far it seems above my paygrade.

1 Like

I have come very late to this thread - I missed it when it was fresh, but I still have a comment.

I haven’t used GearGen since Rhino v4, because in V5 it drew weird Spirograph shapes (Spirograph is a kid’s drawing toy) instead of an involute gear. I just tried the new updated script in Rhino 6, and while it doesn’t produce the VB runtime error that the original 2006 GearGen script was making in Rhino 6, it still draws a wonderful ‘Spirograph’ instead of the gear.

It’s a pity. I’ll have to continue using Rainer Hessmer’s Involute Spur Gear Builder. This is very good indeed, but does lack the convenience of a Rhino plug-in.

Thomas, if you see this and can bring yourself to dig out old work, would you be able to have a look at this bug?

Hi Ian, I wouldn’t know what to tell you. I am on V5 and I’ve never seen it misbehave.

Ok. I think I know what’s happening.

  • If you create a pitch circle by entering its radius or diameter via the command line, or directly onscreen with your mouse, GearGen works fine.
  • If you adjust the diameter of the pitch circle via BoxEdit first, Geargen goes crazy.

Geargen worked for me in Rhino v4, because v4 had no BoxEdit.
I started using BoxEdit for diameters from v5 onwards, because I habitually use Rhino’s circle command set to radius. Can’t be bothered changing from radius to diameter – I forget to change it back and then damn – it’s set to diameter input when I meant radius input. That’s annoying. So I don’t change the way the circle command works – I always have it set to radius.

So if I get a result from my Excel spreadsheet for a pitch circle diameter that I can’t mentally convert to a radius, I’ll draw the circle ‘whatever’ and enter the final diameter via BoxEdit. Circle looks good, works fine for anything else, but maybe there’s some minuscule error that GearGen can’t cope with.

Thanks for the explanation.

I think you found a bug in Rhino.

My script relies on the rhino.curveplane() command. This command returns bogus numbers when a circle has been “touched” with the boxEdit feature.

For example, making a normal circle at (10,0,0) and then a boxEditted circle on top of it (identical size and location):

  1. On the normal circle, the curvePlane of the circle is reported as (10,0,0),(1,0,0),(0,1,0):
    Normal Circle curvePlane

  2. With boxEdit the curvePlane of the circle is reported as (27,0,0),(0,1,0),(-1,0,0):

I can’t get the readout on the command line that you have, to confirm the errant values of P1, P2 and P3, but I can replicate the whacky result. I command-line entered a circle of radius 5, at point on 10,0,0; ran GearGen and just enter-enter-enter for all default values (Z=13 etc) and I get that ‘thing’.

Now I’m wondering if using BoxEdit causes any other problems in the drawing geometry that I’m not aware of.

Maybe @pascal or one of the other deep-Rhinoers knows what’s going on.

Yes, I can hazard a guess. BoxEdit transforms the Rhino circle object (a specific type of geometric entity) into a (generic) NURBS curve. For planar NURBS curves, Rhino always puts the curve’s plane origin at the curve start point (which is somewhere on the circle circumference). For a circle entity, the circle’s plane origin is at the circle’s center point. Hence the difference.

I wouldn’t use BoxEdit to modify the circle’s radius, I would use ModifyRadius instead. That way the circle will stay a circle.


Ahah! Ok, that sounds like the reason then. Thanks Helvetosaur, for the deep understanding.

That’s exactly what’s happening.
The bogus geometry has its center precisely on the beginning circumference of the boxEdited circle

Surprisingly the the box edited circle still reports as a “circle” by Rhino.

Curiously, if you boxEdit a circle and then “modify radius” after it, then it becomes a true circle again and works ok.

Note: The script works as long as Rhino reports something is a circle. For anything else the script detects it and exits. So in this case Rhino trips it.

It does if you use “Scale”, but if you use “Size”, it becomes this:

Valid curve.
NURBS circle
center = (-3.14018e-16,-3.14018e-16,0)
radius = 8.5
start = (8.5,0,0)
end = (8.5,0,0)
degree = 2
control points: rational, count=9
knots: non-uniform, domain = 0 to 31.4159
clamped at start and end

With boxEdit, both size or scale report as “circles” but are treated as curves by curvePlane

Yep, interesting. If I run the python version of CurvePlane(), the first thing it does is try to coerce the ‘circle’ to a RhinoCommon curve object, then it runs the TryGetPlane() method on it. The “Nurbs Circle” ends up getting coerced to a generic NURBS curve object and the plane origin is at the curve start/end. If I run SimplifyCurve() on it first, it coerces to an ArcCurve object, and the plane origin goes to the center. So, it appears to be a subtlety on how TryGetPlane() is programmed to special-case when it sees an arc.

I guess if it was me programming something that needed a real circle to get the center, I would add a quickie function to try to convert ‘sorta-circles’ to real circle objects - maybe even just running SimplifyCurve() will be sufficient.

1 Like