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.
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.
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.
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?
Ok. I think I know whatâs happening.
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):
On the normal circle, the curvePlane of the circle is reported as (10,0,0),(1,0,0),(0,1,0):
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:
Geometry:
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.
