MTs, WM2D, and WM Basic Language Script Code
Moderator: scott
Hi MrBill
The wheel that Wolff is referring to is Bessler's second demonstration wheel at Draschwitz. Unlike the Merseburg (3rd) and Kassel (4th) wheels, the Draschwitz wheel had boards for a cover rather than canvas.
My transcription from Wolff's original letter (the words between the ~ characters were crossed out):
"... In peripheria enim hinc inde affixae erant trabeculae normales, ad quas in circumactione rotae allidi pondera ~manifestum erat~ satis clare percipiebatur. Trabeculas illas per rimam intuens adverti, quamvis e longinquo. ..."
My translation:
"... In fact in the periphery [of the wheel] here and there small 'normal' beams were attached, which on rotation of the wheel ~it was evident~ were quite clearly perceived to be hit by weights. I have noticed those small beams [while] looking through a crack, although from a distance. ..."
(The word 'normal' here means at right angles to the tangent.)
Bessler's wheels turned with the large axle, allowing the axle to be used as a hoist. See Axis in Peritrochio: http://www.fromoldbooks.org/NathanBaile ... /axis.html
I guess Wolff could see through the crack when stationary and as it picked up speed, but not sure if he would have still been able to see anything through the crack at the full speed of rotation.
I've sent you a reply to your emailed question about the grindstone and I've also added you to my forum here on besslerwheel.com in case you're interested in any of my translations in there.
All the best
Stewart
The wheel that Wolff is referring to is Bessler's second demonstration wheel at Draschwitz. Unlike the Merseburg (3rd) and Kassel (4th) wheels, the Draschwitz wheel had boards for a cover rather than canvas.
My transcription from Wolff's original letter (the words between the ~ characters were crossed out):
"... In peripheria enim hinc inde affixae erant trabeculae normales, ad quas in circumactione rotae allidi pondera ~manifestum erat~ satis clare percipiebatur. Trabeculas illas per rimam intuens adverti, quamvis e longinquo. ..."
My translation:
"... In fact in the periphery [of the wheel] here and there small 'normal' beams were attached, which on rotation of the wheel ~it was evident~ were quite clearly perceived to be hit by weights. I have noticed those small beams [while] looking through a crack, although from a distance. ..."
(The word 'normal' here means at right angles to the tangent.)
Bessler's wheels turned with the large axle, allowing the axle to be used as a hoist. See Axis in Peritrochio: http://www.fromoldbooks.org/NathanBaile ... /axis.html
I guess Wolff could see through the crack when stationary and as it picked up speed, but not sure if he would have still been able to see anything through the crack at the full speed of rotation.
I've sent you a reply to your emailed question about the grindstone and I've also added you to my forum here on besslerwheel.com in case you're interested in any of my translations in there.
All the best
Stewart
-
- Devotee
- Posts: 1677
- Joined: Tue Oct 31, 2017 9:22 am
- Location: Lot, France
re: MTs, WM2D, and WM Basic Language Script Code
I've always been intrigued by the use of the word "warped" when, i can"t remember who said "the weights could be heard hitting warped boards at the rim" Or something along those lines.
What particularity of the knocking allowed this assumption?
Is there another translation?
Were the boards seen to be warped through the famous slits/holes?
What particularity of the knocking allowed this assumption?
Is there another translation?
Were the boards seen to be warped through the famous slits/holes?
re: MTs, WM2D, and WM Basic Language Script Code
Hi Robinhood46
The section of text from Wolff's letter that I quoted above is where the 'warped boards' quote comes from, but as you can see from the original Latin there's nothing that can be translated as 'warped' and I'm not sure who originally gave that as a translation or how they thought they could arrive at that. So forget the translations of 'warped' and 'elongated' boards as they are wrong.
Here are some links to previous posts where I've discussed this in a bit more detail:
3 years ago: https://www.besslerwheel.com/forum/view ... 878#150878
5 years ago: https://www.besslerwheel.com/forum/view ... 025#133025
6 years ago: https://www.besslerwheel.com/forum/view ... 431#129431
8 years ago: https://www.besslerwheel.com/forum/view ... 593#101593
10 years ago: https://www.besslerwheel.com/forum/view ... 1388#71388
11 years ago: https://www.besslerwheel.com/forum/view ... 3533#63533
12 years ago: https://www.besslerwheel.com/forum/view ... 1635#51635
All the best
Stewart
The section of text from Wolff's letter that I quoted above is where the 'warped boards' quote comes from, but as you can see from the original Latin there's nothing that can be translated as 'warped' and I'm not sure who originally gave that as a translation or how they thought they could arrive at that. So forget the translations of 'warped' and 'elongated' boards as they are wrong.
Here are some links to previous posts where I've discussed this in a bit more detail:
3 years ago: https://www.besslerwheel.com/forum/view ... 878#150878
5 years ago: https://www.besslerwheel.com/forum/view ... 025#133025
6 years ago: https://www.besslerwheel.com/forum/view ... 431#129431
8 years ago: https://www.besslerwheel.com/forum/view ... 593#101593
10 years ago: https://www.besslerwheel.com/forum/view ... 1388#71388
11 years ago: https://www.besslerwheel.com/forum/view ... 3533#63533
12 years ago: https://www.besslerwheel.com/forum/view ... 1635#51635
All the best
Stewart
-
- Devotee
- Posts: 1677
- Joined: Tue Oct 31, 2017 9:22 am
- Location: Lot, France
re: MTs, WM2D, and WM Basic Language Script Code
Sorry to have not thought of doing a search and you needing to repeat yourself.
Thanks
Thanks
- Wubbly
- Aficionado
- Posts: 727
- Joined: Sat Jun 06, 2009 2:15 am
- Location: A small corner of the Milky Way Galaxy
- Contact:
re: MTs, WM2D, and WM Basic Language Script Code
VM2SO V1.2
The next iteration of VM2SO uses the Variator method. It uses VM2SO V1.1 as the base model but runs the simulation multiple times while varying one of the parameters during each simulation run, then writes the output to a text file.
The inspiration for this version came from Exercise 8 of the WM Tutorial Guide where a parameter in the model is varied, and the output gets written to a text file.
At the start of the run, after the initial dialog box, you are asked to enter a filename (or select an existing filename) where the output of the runs will be written. My system defaults the file location to the "MyDocuments" folder. If you don't put an extension of ".TXT" on the end of the file, the script will automatically attach it for you. I tried separating the output fields with spaces, commas, and tabs, but tabs worked the best when copying and pasting into Excel. If your version of WM2D puts the file in a 'protected' folder, select a different folder for the output file.
The initial dialog box let's you choose which variable to vary between a min and a max value. The choices are M2, R2, R4, Unlock StartAngle, and Unlocked SweepAngle. Depending on what you choose, an additional textbox input will display for the specific max value for the input. You can also choose how many times you want the simulation to run while varying from min to max. You can choose to run from 2 to 20 simulations. The default is set to 10, but if you want more data points for your output graph, you can adjust the number. It only crashed three times on me while doing this, so it's 'fairly' stable and you should be OK.
Each simulation stops after the swinging lever R4 reaches its highest point and it's rotational velocity becomes negative. After the simulation has run the specified number of times (2-20) locate the text file where you chose to write the output data and open it in Notepad. Then copy the entire file and paste the values into an open Excel sheet. Choose which two columns you want to plot and insert a scatter diagram. Observe the trends of the graph. If you have extra time, you can clean up the graph, label the axes, print it out, tape it to your refrigerator, and give yourself a gold star for time well wasted.
Attached are output graphs from 200 simulation runs that were pasted into Excel and cleaned up. Each data point represents the max energy from a simulation run. You can observe and see the the trends for yourself. The energy starting point is zero joules, so any spike over the y=0 line would be an energy gain.
If you look at the output graphs you can see that none of them go over the y=0 line. One of the graphs shows turning points somewhere in the 300 degree range for unlock angle. I thought that down around the 270 mark you would have CF+GF creating something special, but the graphs don't show this. Either I'm overlooking something in the simulation, or I programmed something wrong, or my belief system is wrong. Haven't quite figured out which one it is yet.
The next iteration of VM2SO uses the Variator method. It uses VM2SO V1.1 as the base model but runs the simulation multiple times while varying one of the parameters during each simulation run, then writes the output to a text file.
The inspiration for this version came from Exercise 8 of the WM Tutorial Guide where a parameter in the model is varied, and the output gets written to a text file.
At the start of the run, after the initial dialog box, you are asked to enter a filename (or select an existing filename) where the output of the runs will be written. My system defaults the file location to the "MyDocuments" folder. If you don't put an extension of ".TXT" on the end of the file, the script will automatically attach it for you. I tried separating the output fields with spaces, commas, and tabs, but tabs worked the best when copying and pasting into Excel. If your version of WM2D puts the file in a 'protected' folder, select a different folder for the output file.
The initial dialog box let's you choose which variable to vary between a min and a max value. The choices are M2, R2, R4, Unlock StartAngle, and Unlocked SweepAngle. Depending on what you choose, an additional textbox input will display for the specific max value for the input. You can also choose how many times you want the simulation to run while varying from min to max. You can choose to run from 2 to 20 simulations. The default is set to 10, but if you want more data points for your output graph, you can adjust the number. It only crashed three times on me while doing this, so it's 'fairly' stable and you should be OK.
Each simulation stops after the swinging lever R4 reaches its highest point and it's rotational velocity becomes negative. After the simulation has run the specified number of times (2-20) locate the text file where you chose to write the output data and open it in Notepad. Then copy the entire file and paste the values into an open Excel sheet. Choose which two columns you want to plot and insert a scatter diagram. Observe the trends of the graph. If you have extra time, you can clean up the graph, label the axes, print it out, tape it to your refrigerator, and give yourself a gold star for time well wasted.
Attached are output graphs from 200 simulation runs that were pasted into Excel and cleaned up. Each data point represents the max energy from a simulation run. You can observe and see the the trends for yourself. The energy starting point is zero joules, so any spike over the y=0 line would be an energy gain.
If you look at the output graphs you can see that none of them go over the y=0 line. One of the graphs shows turning points somewhere in the 300 degree range for unlock angle. I thought that down around the 270 mark you would have CF+GF creating something special, but the graphs don't show this. Either I'm overlooking something in the simulation, or I programmed something wrong, or my belief system is wrong. Haven't quite figured out which one it is yet.
- Attachments
-
- VM2SO V1.2 Simulation.TXT
- VM2SO V1.2 Simulation - WM Basic Script file to build the model in WM2D.
- (39.83 KiB) Downloaded 85 times
-
- VM2SO V1.2 Simulation Runs.xls
- VM2SO V1.2 Spreadsheet - Simulation Run Outputs
- (111.5 KiB) Downloaded 98 times
re: MTs, WM2D, and WM Basic Language Script Code
I always wanted to, but never did, build a 2 stage oscillatore and compare the physical results to the simulated ones. Mind you, I could never build one where I was excited about its actual movement. Like you, my simulated ones never gave me a gain.
- Wubbly
- Aficionado
- Posts: 727
- Joined: Sat Jun 06, 2009 2:15 am
- Location: A small corner of the Milky Way Galaxy
- Contact:
re: MTs, WM2D, and WM Basic Language Script Code
VM2SO V1.3
One last try at the model.
Changes to Version 1.3:
Remove the sweep angle variable.
Add a rotational spring at Global 0,0 attached to rect1, and a vary option on the K value of that spring.
Leave the rod Unlock conditions the same.
Change the rod lock to be when rect1's angular velocity becomes negative - to not loose any PE m1 may have gained.
Rod constraint ActiveWhen: rect1.p.r < 0
Simulation stop condition is the same: when rect2's angular velocity becomes negative.
Sim Pause control condition: rect2.p.r < 0
Calculate the energy stored in the rotational spring and add that to the total PE energy budget and the total Energy Budget.
U = 1/2 k (ϴ₂² - ϴ₁²) where ϴ₂ is the final angle, and ϴ₁ is the initial angle, and U is the mech pot energy in the spring.
Convert the model to SI-Radians instead of SI-Degrees so the energy calculations are correct.
Added an option to not write the data to an output file.
Objective: See if there are any changes in the graphs.
---------------------------------------------
Observations:
All of the energy graphs essentially flatlined for all variations of the parameters.
When you add a spring and add its mechanical potential energy into the energy budget, the total potential energy mirrors the kinetic energy, and the total energy in the system flatlines at zero for the entire run.
When all the energy is accounted for, there's still no cross above the y=0 line.
Locking the rod when the angular velocity of rectangle1 becomes negative preserved the PE of m1, and we didn't see the huge energy drop offs that Version 1.2 displayed.
No extra energy in this mechanism.
I'm a little surprised Milkovic fooled himself and others for so long. But I guess you don't learn anything until you "discover" it for yourself, even if others have already gotten the memo, read it and moved on.
One last try at the model.
Changes to Version 1.3:
Remove the sweep angle variable.
Add a rotational spring at Global 0,0 attached to rect1, and a vary option on the K value of that spring.
Leave the rod Unlock conditions the same.
Change the rod lock to be when rect1's angular velocity becomes negative - to not loose any PE m1 may have gained.
Rod constraint ActiveWhen: rect1.p.r < 0
Simulation stop condition is the same: when rect2's angular velocity becomes negative.
Sim Pause control condition: rect2.p.r < 0
Calculate the energy stored in the rotational spring and add that to the total PE energy budget and the total Energy Budget.
U = 1/2 k (ϴ₂² - ϴ₁²) where ϴ₂ is the final angle, and ϴ₁ is the initial angle, and U is the mech pot energy in the spring.
Convert the model to SI-Radians instead of SI-Degrees so the energy calculations are correct.
Added an option to not write the data to an output file.
Objective: See if there are any changes in the graphs.
---------------------------------------------
Observations:
All of the energy graphs essentially flatlined for all variations of the parameters.
When you add a spring and add its mechanical potential energy into the energy budget, the total potential energy mirrors the kinetic energy, and the total energy in the system flatlines at zero for the entire run.
When all the energy is accounted for, there's still no cross above the y=0 line.
Locking the rod when the angular velocity of rectangle1 becomes negative preserved the PE of m1, and we didn't see the huge energy drop offs that Version 1.2 displayed.
No extra energy in this mechanism.
I'm a little surprised Milkovic fooled himself and others for so long. But I guess you don't learn anything until you "discover" it for yourself, even if others have already gotten the memo, read it and moved on.
- Attachments
-
- VM2SO V1.3 Simulation.TXT
- VM2SO V1.3 Simulation - Script file to build the model in WM2D
- (44.18 KiB) Downloaded 81 times
- Wubbly
- Aficionado
- Posts: 727
- Joined: Sat Jun 06, 2009 2:15 am
- Location: A small corner of the Milky Way Galaxy
- Contact:
re: MTs, WM2D, and WM Basic Language Script Code
MT143 or Roberval
BW Wiki picture of MT143.
Here's a first try at MT143 Version 1.
This simulation is very unstable. It does odd movements that obviously don't represent reality. A previous version would literally fall apart at certain angles. Not sure what I'm doing wrong yet. Or maybe WM2D has a cold heart and likes to mess with my mind.
I always wanted to build one of these in real life, but now I can test it in the virtual world (if I can get the simulation stable).
The simulation "as is" doesn't really do anything. It's just something to play with and another MT to cross off the sim list.
Some people see the hanging or swinging levers as something special, but I'm not seeing anything in them yet so I made masses sliding in a slot constraint instead.
BW Wiki picture of MT143.
Here's a first try at MT143 Version 1.
This simulation is very unstable. It does odd movements that obviously don't represent reality. A previous version would literally fall apart at certain angles. Not sure what I'm doing wrong yet. Or maybe WM2D has a cold heart and likes to mess with my mind.
I always wanted to build one of these in real life, but now I can test it in the virtual world (if I can get the simulation stable).
The simulation "as is" doesn't really do anything. It's just something to play with and another MT to cross off the sim list.
Some people see the hanging or swinging levers as something special, but I'm not seeing anything in them yet so I made masses sliding in a slot constraint instead.
- Attachments
-
- MT143 V1 Simulation.TXT
- MT143 Simulation - Script file to build the model in WM2D.
- (37.77 KiB) Downloaded 77 times
re: MTs, WM2D, and WM Basic Language Script Code
FWIW : Yeah, they can be problematic. I find it's usually in the building for me.
So I anchor the horizontals on a Grid. Then build the verticals. Then I use the Point Element to place a point on both the vertical (say top) and the horizontal where I want them to join. Then > Join.
I pull away the vertical so it pivots and is on an angle, and repeat for the bottom > Join. Etc.
If I just place them using the coordinate system relocation and then > Pin Joint it can be off by microns. And when you run the sim it moves erratically and/or explodes the joints.
A real build is perhaps more forgiving than a sim build for these things.
P.S. loved the song ;7)
So I anchor the horizontals on a Grid. Then build the verticals. Then I use the Point Element to place a point on both the vertical (say top) and the horizontal where I want them to join. Then > Join.
I pull away the vertical so it pivots and is on an angle, and repeat for the bottom > Join. Etc.
If I just place them using the coordinate system relocation and then > Pin Joint it can be off by microns. And when you run the sim it moves erratically and/or explodes the joints.
A real build is perhaps more forgiving than a sim build for these things.
P.S. loved the song ;7)
re: MTs, WM2D, and WM Basic Language Script Code
I have tried numerous times to get Roberval Balance to work properly in Algodoo. No matter how many times I build it wants move back to the horizontal level position after you reposition it, balanced but moves slowly back. After Stewart pointed out that I was wrong I built a real physical one and the RB will stay static in any position it is set in. Must be something the SIMs are having trouble calculating.
What goes around, comes around.
re: MTs, WM2D, and WM Basic Language Script Code
Wubbly, Like Fletcher said, accuracy can be very important. When you sim something like this with multiple connected points, any miscalculation or slight error in placement will cause problems (or simulated stress).
What you could do to stop this problem is replace the bottom long bar with two shorter bars half the length. This will allow the bottom bar to compensate for any minor errors that would normally make your sim try to rip itself apart.
What you could do to stop this problem is replace the bottom long bar with two shorter bars half the length. This will allow the bottom bar to compensate for any minor errors that would normally make your sim try to rip itself apart.
re: MTs, WM2D, and WM Basic Language Script Code
I agree guys but that’s my point in real life these changes aren’t so dramatic. In real life the pivot points have to move by quite a bit. How can you say you trust SIMs when known balance don’t react like they should? I like Algodoo for mocking mechanical arrangements up to see how they act and the program is super easy but I don’t trust it on balance/rotating energy gains. I imagine you can get the RB to work on WM2D if you are super accurate but are you going to be that accurate building a device that you are not sure how it will react and where you need to be super accurate? Is there away to make WM2D less sensitive to stress joints or binding?
For maximum accuracy, Roberval balances require that their top fulcrum be placed on the line between the left and right pivot so that tipping will not result in the net transfer of weight to either the left or right side of the scale: a fulcrum placed below the idea pivot point will tend to cause a net shift in the direction of any downward-moving vertical column (in a kind of positive feedback loop); likewise, a fulcrum placed above this point will tend to level out the arms of the balance rather than respond to small changes in weight (in a negative feedback loop).
https://en.wikipedia.org/wiki/Roberval_balance
What goes around, comes around.
re: MTs, WM2D, and WM Basic Language Script Code
Yes, just use rods for the verticals as in the pic below (or some variation). No binding and removes the necessity for extreme accuracy using rectangles etc.Is there away to make WM2D less sensitive to stress joints or binding?
Just an aside. In my example I have made the weights unequal to test full rotation ability without binding or stress related sim exploding issues. They should be pinned to the horizontal or else their inertia will cause them to move across and fall off.
Problem solved I think.
ETA : fwiw replacing rods with springs, dampened springs, separators, and most surprisingly ROPES does not work.
- Wubbly
- Aficionado
- Posts: 727
- Joined: Sat Jun 06, 2009 2:15 am
- Location: A small corner of the Milky Way Galaxy
- Contact:
re: MTs, WM2D, and WM Basic Language Script Code
Fletcher, your rod idea worked beautifully! It didn't explode or exhibit non-Newtonian behavior. Thanks guys for the inputs.
Last edited by Wubbly on Tue Apr 28, 2020 12:37 am, edited 1 time in total.