Please review the attached image.
This sample project has a crank wheel and a drive rod.
The rod will be positioned by a GH number slider and the wheel must turn. It doesn’t have to turn all way around, just 90˚ to the end. How would anyone set this up?
Oh… here is the file if you want to play with it.Sample.3dm (2.3 MB)
I am by no means the most knowledgeable Grasshopper person, but this is how I would do it. I wasn’t sure how you wanted the free end of the shaft to behave, so there are two options in there.
Shaft.zip (341.6 KB)
Holy Spaghetti Sauce Batman! I’m not sure I understand anything you’ve created here. I mean, this was some serious work you’ve done here. So you have an input slider for angle, which turns the wheel, and the … dang… not sure what else is going on. That all said, I think this is reversed. I was looking to construct a slider as driving the angle of the wheel.
is there a specific reason you want the rod to be the thing that motivates the wheel? Is it because you need the slider to control the percentage of stroke of the rod instead of the amount of wheel rotation?
As for what is happening (writing from home, not in front of the definition, so there might be some discrepancy between my memory and reality (often the case )), the angle slider rotates the wheel and a reference point, the arm is then moved from the reference point’s original location to the new rotated location. In the first option, that’s all that is going on.
In the second option, I’m also drawing a line along the center of the arm, which represents the direction of travel for the fixed end. I then draw a circle the same radius as the arm and rotate that with the wheel and the reference point. Where the circle and line intersect is where the end of the rod wants to land. I then used an orient module to move and rotate the arm.
The truth is the application I need to use this for is a bit more involved, but the example is the same mechanical setup. Think of this in terms of a bell-crank. How would you express the function of a bell-crank using GH? It’s a basic enough mechanical arrangement but I can’t seem to find the right mix of tools.
I’m totally with sam…from my point of view is easier to tackle it down focusing on the wheel as driver and making the rod follow whatever point you want in the will.
I think that the problem is less about mix of tools and how about face the problem in terms of algorithmic/geometric logic.
The wheel becomes a bell crank? That wouldn’t really change anything, you might just limit the slider input to fit the range you want the bell crank to pivot. If the rod becomes a bell crank, that doesn’t really change anything either, it just becomes a different shape.
Right now I can’t even get the Grab function to work in Kangaroo. It seems very fickle as it worked once, but never afterwards.
I can’t understand why doing something so simple is so impossibly hard.
Here is me trying to move a simple object with GH/Kanga… I had to use a Merge feature just so I can have the grab function work with the rigid body function. It worked once… now the object just shimmers rather than moves.
I think the relationship you are looking for is that the travel distance of the “push” of the rod translates into the arc length on the wheel. HTH
RodAndWheel.gh (16.2 KB)
Again, I really appreciate the work you’ve done, as it looks plenty complicated for something perhaps GH should offer inherently.
if you press&hold shift key, you can plug two wires into one port…
like, plug in the rigidBody to GoalObjects… then holding shift key, plug Grab into GoalObjects
You know, that’s just the kind of bananas I expect from the designers of Bentley, not commercial software. So I got both crammed into the one port… but it behaves the same way: the rigid part doesn’t move, the surface just shimmers.
Here is the basic setup:
I couldn’t get a cube to move in GH if my life depended on it.
are you using the Alt key with Grab?
because this works for me and i’m on mac… so it should definitely work for someone on windows
oh… and if you are on mac, notice the click i have to make when going from grasshopper to rhino.
you have to first bring focus to the rhino window…
i’m not sure if you have to do that on windows but if not, it seems like windows version wins here
actually, when looking at your screenshot more closely:
you have preview turned off on the solver… so yeah, you won’t be able to see it moving if you have the visibility turned off
Of all the dumb things!!! Holy meatball sauce Batman! Preview off. As of this moment, I strongly recommend the “preview” feature should not darken the component icon, but fade it back like it was in ghost mode. The tint is not something I pay attention to.
Thanks so much Jeff. I suppose I won’t be forgetting this anytime soon.