Yet another wheel of unfortune (category MT16-b)

[ME]

Hi guys...
Just in case you didn't know: overbalanced wheel won't work.
Because the sum of Length(m)xMass(kg)xTime(sec) is equal to te left and right side of the wheel (esp. the time factor).

In case you did know: at least you have a nice animation :-)
(this one per 2 strings shows the principle the best way)

greetings from holland.

[ken_behrendt]

Interesting animation. The blue path is the course that the suspended weights follow, but it looks to me like the center of gravity of the three weights just orbits about a point below the axis of wheel rotation (the so-called "punctum quietus"). If that is the case, then it will not be capable of continuous rotation.

Anybody here up to making a WM2D model of the design and running a simulation of it?

ken

[ME]

Can that be done with the demo-version of WM2d?

[ken_behrendt]

Yes, ME, the Demo version of WM2D can probably easily model your design. If you have downloaded the Demo version, then you should give it a try. If you have just started learning to use WM2D, then modeling your interesting design on it would be good practice for using the CAD program and might give you some ideas for improving the design.

ken

[ME]

I'll give it a try, maybe it's faster than programming Delphi.
As starting PM-investigator I am more curious why it doesn't work than chasing my tail to make it work.
I am almost convinced that a static model like this doesn't work. And with static I mean: an overbalanced wheel at all positions (because mgh=½mv²). So the PM-solution must lie in a dynamic system, where motion makes inbalance... but that's hard to simulate.

[jim_mich]

In this case the dynamics cause the wheel to slow down then keel. I used my standard 9 inch radius wheel with three 1/2 inch radius weights attached evenly at three points with 8 inch and 13 inch ropes. It was almost balanced at start and just sat there. So I added a motor to turn it at 80 degrees per second for 10 seconds then quit. Below is the results...

[rks1878]

I'll give it a try, maybe it's faster than programming Delphi.
As starting PM-investigator I am more curious why it doesn't work than chasing my tail to make it work.
I am almost convinced that a static model like this doesn't work. And with static I mean: an overbalanced wheel at all positions (because mgh=½mv²). So the PM-solution must lie in a dynamic system, where motion makes inbalance... but that's hard to simulate.

ME:
J.E.E.B's principle caused his first wheel to be constantly overbalanced. The removal of a bolt or string let it begin rotation.

Also. Do you believe that someone like Gottfried Liebniz could have been fooled by J.E.E.B. and his wheel?

[ME]

1. I said: "ALMOST"
2. Maybe we are all fooled

[rks1878]

2. Maybe we are all fooled



I don't think so.....

[turulato]

ME you said;

So the PM-solution must lie in a dynamic system, where motion makes inbalance...

Interesting thought, have you see the animation here?

http://www.besslerwheel.com/forum/viewt ... 3866#13866

I would be very interested in your comments.

Turulato

[rlortie]

Interesting animation. The blue path is the course that the suspended weights follow, but it looks to me like the center of gravity of the three weights just orbits about a point below the axis of wheel rotation (the so-called "punctum quietus"). If that is the case, then it will not be capable of continuous rotation.

Anybody here up to making a WM2D model of the design and running a simulation of it?

ken

I agree with Ken, this is a unique approach but it will not work as all three weights are below axis while suspension points are horizontal with each other.

Ralph

[trevie]

Hi Jim, Nice simulation graph, looking at the output the sinusoidal waveform shows the velocity increasing and decreasing at a constant rate almost, although if were to take an average from the waveform, it looks like the output would be zero. Hence no PM. If the strings are evenly spaced then Each weight would not overbalance the wheel but to balance the wheel.

[ME]

2. Maybe we are all fooled
I don't think so.....

I think you hope so? :-)
So we keep on trying...

ME you said;
So the PM-solution must lie in a dynamic system, where motion makes inbalance...

Interesting thought, have you see the animation here?
http://www.besslerwheel.com/forum/viewt ... 3866#13866
I would be very interested in your comments.

Turulato

I think you pointed at your 'CounterWeights'.

Eventually it comes to torque = (leverdistance) times (force)
(am not familiar with the english expression of this)

For the Big Blue beads (weight=a) the Torque is per frame
1. +212
2. +220
3. +278
4. +228

For the Small Purple beads (weight=b) the Torque is per frame
1. -248
2. -283
3. -263
4. -242

Result
1. 212a<248b ;a<1.17b
2. 220a<283b ;a<1.29b
3. 278a<263b ;a<0.95b
4. 228a<242b ;a<1.06b

(torque positive=clockwise, negative=counterclockwise)

hmm, assuming the weights move as you mention,
and the weight of Blue(a) must be heavier than Purple(b), to move as mentioned,
and the weight of Blue(a) must be between the Purple weight(b) and 1.06b
and the angular acceleration is enough to overcome the torque-dip in frame 3...
then it could work.

When better mathematics are used, I assume the result should be 0 torque (even without friction)

[Clarkie]

Its going the wrong way for me.

[ME]

Sorry, which way should we go now?