Graham,
Without seeing the actual setup I'm not sure what is happening. I might guess that you pre-position the arm against a stop and pre-tension the spring. Then when WM runs the spring tension moves the arm into and overlaps the stop by the amount allowed by the over lap error setting. This movement of the weight might be enough to rotate the wheel. Test it by changing the over lap error value to something smaller. Or maybe try a bigger value. If the rotation speed changes relative to the over lap error seting then you have found the cause. The rotation might be caused by the weights becoming out of balanced or by their inertial reaction with the wheel.
Hitting "run" from here will start the wheel turning clockwise.
If I eliminate the pretensioning against the red stops by changing the spring length to 2'" rather than the 1.5" shown
and hold the L H blue arm in place with a rigid joint to stop it pulling away from its stop, then the wheel does not move.
It is doing exactly what I said. The lever arm gets pulled into the stop. The stop and the lever "penetrate" each other and overlap. Thus the lever moves a small distance when you hit run. You can test this by adding a rope between the lever and the stop. Make the rope a little longer so it is slack. Then make a meter to measure the rope length. This will display the distance between the rope ends. Single step one step then reset and the meter will display the starting length. Then hit run and you will see the rope length distance gets shorter as the stop and lever arm penetrate each other. Now reset and change the overlap error setting to 0.001 and run again. The rope length distance will not shrink as much.
Comparing to real world situation imagine that the lever was made from styrofoam and the spring pulling on it caused the stop to indent into the styrofoam. Ralph would immediately see the dent and know that the lever moved a distance equal to the dent depth causing the weights to no longer balance. Working Models imitates the real world!
I'm having some odd things happening lately and I am wondering if that "clear Velocity" download from Tinheads post in Jims Eureka thread might be something I should use.
I've downloaded the Word document but now what do I do ??
I haven't a clue :-(
Is this the same thing as hitting "script" then "negate velocity"
"all bodies" .
If it is, then why would you need the download ?
I never use any "negate velocity" scripts. If I think I've inadvertently introduced some velocity then I manually check each component to see if it has any preset velocities. To do that I open the properties window and with my curser in the top selection box of the properties window I curser down. The objects will display one after another as I look for any with initial velocities. By doing it this way I will know if there was or wasn't any preset velocities.
Thanks Jim , that's what I have been doing myself. I just thought there might be more to it than that .
As usual you were kind enough to reply to my question .
Has anyone transferred the details of a simple working mechanism that they might have in their possession, into the software, to verify that the software outputs a true realtime model of same?
If a wheel design doesn't work as predicted or anticipated can one be
sure if the output can be trusted to be accurate?
I feel that there will be a very fine line between success or failure of
a OU device.
The software has numerous setting that control accuracy and speed of calculations. If you set them to very very accurate then the calculations slow down greatly. If you relax the accuracy then the calculations speed up. If you're willing to wait many hours for it to calculate just a few minutes worth of movement then it can be done. Or you can let it be less accurate and show results in close to real time or sometimes even faster (with a very fast computer).
The software uses standard known laws of motion. If the real world doesn't follow these laws then the software results will not be the same as real world results. I have no reason to think they won't be the same.
According to Bessler history his wheels had very good starting torque and acceleration up to speed which would be very apparent in a WM2D simulation. Once in motion Bessler's wheel did not seem to demonstrate as much continuous torque. The only data we have concerning how much work they could do is by estimating the size and weight of the hammer mill stampers and calculating how much power it took to run them. This gives a minimum power output of about 24 watts (if I remember correctly) but the stampers might have been using only a small part of the wheel's power. Maybe the wheel was able to run the stampers while raising the basket of brick and also pumping water? History doesn't say if the demonstrations were run individually or concurrently.
Anyway, the line between Bessler's wheels working or not working was much broader than a fine line.
Mick wrote:Is there an easy way to "array" objects, or must one copy and paste?
Copy and paste works good.
If you have some basic language programing experience you can also write basic script files which can use arrays of objects. The WM script editor isn't real friendly. There have been times I've spent a few hours trying to figure out why a single line causes an error or problem. It can be as simple as it wanting a single precision number instead of the double precision number I was trying to use or needing to make a rod inactive while setting it's end points so that it doesn't move other objects.
Anyway, the line between Bessler's wheels working or not working was much broader than a fine line.
I quite agree. When one finally has Bessler's design on WM2D, he won't be wondering if he has it because of some weak motion. He will know he has it because he will get a gross and robust motion in the device. The same applies to a physical model.
ken
On 7/6/06, I found, in any overbalanced gravity wheel with rotation rate, ω, axle to CG distance d, and CG dip angle φ, the average vertical velocity of its drive weights is downward and given by:
Yes, Bessler said something like 'when you have the principle an ounce here or there won't make a measurable difference'. This also implies that having everything exact regarding placement & weight or a finely balanced wheel template are somewhat irrelevant once the principle is known. It's power output overrides the small imperfections of design & build.
graham wrote:I'm having some odd things happening lately and I am wondering if that "clear Velocity" download from Tinheads post in Jims Eureka thread might be something I should use.
I've downloaded the Word document but now what do I do ??
I haven't a clue :-(
Is this the same thing as hitting "script" then "negate velocity"
"all bodies" .
If it is, then why would you need the download ?
I bet Jim knows the answer.
Graham
Sorry for the late response, just back from a trip to Sydney (SolidWorks World .. exhausting).
"Negate Velocity" does not clear the velocity ... it negates them. -10 turns into +10 etc. So your wheel would just turn the other way around :)
That's why I posted the modified version, that one really sets all velocities to zero, nada, nothing. Just rename the clearvelocity.wbs.txt back to clearvelocity.wbs and copy it to the WM2D script folder.
( by default at C:/Program Files/WorkingModel/Program/Scripts). The next time you start up WM2D it will be available in the script menu.
mickegg wrote:Has anyone transferred the details of a simple working mechanism that they might have in their possession, into the software, to verify that the software outputs a true realtime model of same?
If a wheel design doesn't work as predicted or anticipated can one be
sure if the output can be trusted to be accurate?
I feel that there will be a very fine line between success or failure of
a OU device.
Mick
Fletcher mentioned it somewhere else, most of our ideas will be tested in WM2D first. That's my end of the rope. Afterwards, if promising enough, Fletcher builds the 'real' thing. So far WM2D was always right, even using functions driven forces and other things to extend its functionality.
Past experience showed us, yep, we can trust it ... sometimes we wished it would have been wrong ;)
