Besslers prime mover and its enabler.

[Roxaway59]

Here is the basic lever idea on its own in WM2D.

When you run it you will notice a slight upward movement from the left.

This happens despite the fact that the two weights are equal and the left hand weight is further from the axle than the right hand one.

This means that the whole thing ends up being top heavy and on my wheel the pendulum now sits at 12 o'clock.

Notice that the moving left weight cannot now drop past the bottom of the lever.

[Roxaway59]

Here is the wheel in WM2D and I have put more levers along the bar to give it more torque and speed.

The diameter is smaller than the one shown in Algodoo.

Graham

[Fletcher]

Hi Rox .. I had a quickish scan of your thread today to get the gist of what you have been proposing ..

I did a quick simplification of what I think your Law of Levers workaround appears to me to be .. i.e. that the intervention of an anchored object induces extra energy into rotation ? ..

So I made a quick simplification sim ..

Assumptions are that a pendulum structure starting from horizontal should swing higher than horizontal if it has extra KE - all yellow masses are 1 kg each ..

I have made 3 side-by-side pendulums as can be seen - the first to the left has an anchored "kicker" only just touching the yellow weight - the second it overlaps somewhat - the third it overlaps quiet a lot ( if you zoom in ) ..

I have added Vectors>Contact forces ( red ) to see the various contact positions ( the lhs yellow weight is contained in a "cage" etc ) - also blue velocity vectors .. sim attached ..

Summary :

The greater the overlap of the background anchored "kicker" intervention the greater is the pendulum velocity and KE ..

Conclusion :

1. This appears to be an artifact of WM2D overlap error when two objects are placed too close together ( overlapping ) before a simulation is run ! - the sim attempts to "spit the objects apart" introducing fictitious energy into the system/sim ..

2. Adjust the placement of the 'kicker' to test the hypothesis/theory i.e stress test the sim ..

3. Build a real-world pendulum test with 'kicker' intervention and compare to sims ..

Best -f

.................



.................

[Roxaway59]

Hi Fletcher nice to hear from you I hope you managed to get the work done that you needed to do.

I have come across this overlapping problem before and I did wonder if this could be what is happening here. I am no expert when it comes to simulators but I tried my best when I did these simulations to avoid this pitfall.

In both Algodoo and WM2D I ran the simulation with the lever held in place to let the weights settle down. Then I ran the simulation with the lever released and in both Algodoo and WM2D the left hand side still lifted.

There is only one way to be sure and that is to do the real experiment and this is what I will do.

Here is an Algodoo simulation of the lever and here are some things to note about it.

1) The lever is quite large because Algodoo is more accurate that way.
2) This lever is arranged to be turned upside down so it can work on either side of my wheel and that is why there are those X shapes on it.

Run the simulation then release the fixate on the left so the lever can move.

You will see that the lever still moves upwards.

Exactly the same thing happens in WM2D when you do the equivalent of this.

What I think is happening here is a kind of chicken and the egg situation and it doesn’t break any laws.

Initially when the lever is released the right hand weight overbalances the left one because the left hand weight is partly resting on the fixed ramp. So the lever moves clockwise but the moment it does so it then feels the overbalance due to the left hand weight being further from the axle. However because of inertia it cannot stop instantly and rises just a little before coming back down.

This is what I hope is happening but as I say the only way forward is a real experiment.

Graham

[Fletcher]

Hi Fletcher nice to hear from you I hope you managed to get the work done that you needed to do.

Yes I did thanks - see updated today thread for detail of some of the things I did - was very pleased with fixing my tank and automating my siphon water delivery system into on-demand motor pulled supply for example ..

Run the simulation then release the fixate on the left so the lever can move.

You will see that the lever still moves upwards.

Exactly the same thing happens in WM2D when you do the equivalent of this.

What I think is happening here is a kind of chicken and the egg situation and it doesn’t break any laws.

Initially when the lever is released the right hand weight overbalances the left one because the left hand weight is partly resting on the fixed ramp. So the lever moves clockwise but the moment it does so it then feels the overbalance due to the left hand weight being further from the axle. However because of inertia it cannot stop instantly and rises just a little before coming back down.

This is what I hope is happening but as I say the only way forward is a real experiment.

Hi Rox .. I modified my previous sim to more closely represent what you just showed in Algodoo - now the rhs weight is half the distance to pivot than the lhs ( see animation of sim ) ..

This is what I think is happening ..

Note that when resting on the fixed ramp ( "kicker" ) that the lhs yellow weight shows red dots as contact points and forces - the contact force of a circle is at right angles to the circumference - this means when resting on the ramp the ramp pushes back with the same force ( Newton's Laws ) - in effect some of the weight is being offset by the ramp push back ( see the lhs sim ) n.b. resultant forces are x and y vectors - in the case of the other 2 sims left to right the ramp overlap gets worse progressively - this time they physically eject the lever CW against its natural tendency to rotate CCW - this is not "Physics" but the program trying to maintain integrity i.e. when objects interact by collision or resting against each other there is deformation losses and small change in shape at contact point - the programs cannot process this fine detail frame to frame as the real-world does - so there is an attempt to separate them and in the process they are spit apart with energy/velocity ..

** The trick is to design a sim experiment, whether in Algodoo or WM2D, to separate Newton's Laws from programing artifacts such as overlap error which is well known about .. **

If you look at the animations and run my sims you can see the contact forces ( and fixed ramp sharing the load ) and see when the overlap error is at work for each of the 3 side-by-side sim experiments ..

As you say the best simulator is a real-world experiment, which we all agree on - I can easily see a fixed ramp absorbing/countering part of the lhs weight ( balancing forces ) but I can not imagine it reacting like an overlap error would in the real-world ..

Look forward to your real experiments tho ..

................



................

[Roxaway59]

Fletcher I realised why the left side is lifting and it isn't the overlap problem that you have stated.

I wonder if you would work with me on this because I want to make a point about something.

Will you take the WM2D lever that I posted and repeat the experiment by letting the lever move up as far as it can then positioning the weights on the wheel like I did and see if the wheel works just like mine did.

Graham

[Fletcher]

Fletcher I realised why the left side is lifting and it isn't the overlap problem that you have stated.

I wonder if you would work with me on this because I want to make a point about something.

Will you take the WM2D lever that I posted and repeat the experiment by letting the lever move up as far as it can then positioning the weights on the wheel like I did and see if the wheel works just like mine did.

Graham

Happy to work with you to resolve what is actually happening Graham .. tho I'll only work with WM2D .. post up again your WM sim that you want me to reproduce and examine etc .. explain step by step what you want me to do with it, because it may not be as obvious to me or anyone else as you might think ..

Let's see if I can come over to your camp ..

[Roxaway59]

Thanks Fletcher.

Here is the lever and just run it so that the weight on the left goes up as far as possible so you can position them on the wheel as I did.

[Roxaway59]

Here is the wheel. Just remove the weights on the left then position your weights in their place on the same X axis opposite the green ones. Time for bed.

Graham

[Fletcher]

Thanks Fletcher.

Here is the lever and just run it so that the weight on the left goes up as far as possible so you can position them on the wheel as I did.

Hi Graham .. that's the thing mate - the weight on the lhs does not rise up - it loses some GPE as can be seen by the metering/outputs ..

The rhs weight at the shorter arm also loses some GPE as can be seen in the outputs and visually .. this is because while the rhs weight is fixed/pinned to the horizontal lever the lhs weight is not and is free to make contact and "settle" - which is does - zoom in and see the overlaps as it settles - note the system COM icon also drops a little when the sim is run ..

N.B. I rebuilt parts of your sim because something wasn't right with the green guides COM - also I added positional output metering etc and inputs for Elasticity etc .. but mostly to get everything to have zero Gravitational Potential Energy ( GPE ) at the start - n.b. when an anchor is used it removes the object anchored from the system COM/CoG calculation and icon which shows it ..

Sim attached ..

..................



..................



..................

[Roxaway59]

Hi Fletcher the thing is that if the objects overlap in that way then yes the weight is going to drop too far so doesn't your accuracy settings sort that out?

Here are some close up screen shots of my simulation followed by a screen shot of yours.

The first shows the simulation before it is run showing the small gap at the bottom of the left hand weight which is the reason why it works in the first place.

The second is after it has been run and you will see there is no overlap like there is on yours.

The third is showing my accuracy settings.

The forth is a screen shot of your simulation in comparison showing the overlap.

Graham

[Roxaway59]

Another thing to note Fletcher about my pictures and my simulation is that the GPE of the left hand weight does not drop it lifts. You can see this clearly by looking at the centre of the weight.

Graham

[johannesbender]

Rox honestly this is what happens , you can decrease the overlap error values to insure less overlap etc etc , but the main thing here is that the weight is moveable it needs a few frames to come in to contact with the sides of the inclines , which it does , however that takes some time to happen , you could see this as the contact forces appear and disappear as it makes contact and non contact , during that time when there is no contact and when the contact is on the right incline - the lever has no force on the left side of it ,which will make it lever over to the right , when all contact forces appear (all three) and there is no movement shows you there is no real net torque , and if you include real world friction and resistance there would be less motion especially when in the real world the weight would be settled already.

[Roxaway59]

JP I didn't run my simulation quite the same as you describe or the way that Fletcher shows it.

Just to be clear are you saying that it isn't the overlap that is responsible for the results I am getting?

Graham

[johannesbender]

you can lower the overlap error to like 0.001 if you want to , however the reason why the lever moves is because the weight's total force is not completely on the lever , some of it is on and some not .

There is also a slight time where the weight is not in contact with the lever in the very beginning during which the lever is going to tilt slightly up ,this wont happen in the real world because the weight would be in full contact with the inclines when you start a real world test , unless you hold it on a string such that it does not touch anything , then snip it , it is a very slight fractional part of the reason why the lever starts to move up.

However It appears to me to reach its state of rest at a few degrees off level where the forces match up , you would need to calculate the total GPE lost vs total GPE gained to show a gain of more lifted vs less dropped , mass * gravity * height .

As for reasons why it would go to 12 (i think this is what fletcher is discussing) .