MTs, WM2D, and WM Basic Language Script Code

[Wubbly]

MT-25

Attached is the WM2D script code that builds the MT-25 simulation.

[Fletcher]

MT-25

.. snip ..

I still don't know what the good qualities of the MT are. To me, it's just another non-running MT like all the others. He says to "study the diagram extensively." Not sure what there is to see here.

Wiki - No. 25 This is the previous model except for some differences. It is sketched with longer poles. There is something misleading about the diagram, for the poles, when coming out, must not project so far out but must bend somewhat further inwardly. There is more to it than one supposes; one must study the diagram extensively.

John Collins MT booklet - No. 25. This is similar to the previous model except that it is drawn somewhat differently and with longer rods; there is something misleading about the diagram, because the folding rods should not project so far out but must bend further inward. There is more to this than one might think. Mark my words.

Whatever his intention here is, it is only vaguely suggestive, imo.

So we either have ..

1. four weights at the end of levers which fall under gravity, plus 4 hinge systems connected by 2 poles each and a thru axle pulley system (the rope) to an opposite. (i.e. 4 weight system).

2. four weights at the end of levers which fall under gravity, plus 4 weighted hinge systems (n.b. the hinge also acts as a weight), connected by 2 poles each, plus ropes etc. (i.e. 8 weight system).

The first option is a stock standard false OOB wheel.

The second option is a slightly more complicated false OOB wheel. It however could be suggestive of two weight systems being required. A secondary false OOB system (like 1. above) and a Prime Mover weight system (the primary). IMO.

[Fletcher]

I drawn my conclusions in part on the way Bessler makes his drawings (woodcuts) in MT.

WRT to MT's 24 & 25 there is little differentiation between what are obvious weights (on levers), and what are 'hinges', or pivots in some instances. The exception being the fixed position rim pole pivots which look slightly different from the poles 'hinge' (and weights).

People develop a style of drawing, especially when producing many of them, and when they sometimes contain repetitive content. It's human nature to be consistent, and keep it simple. We can't help ourselves, otherwise it becomes too complex and it takes too much effort to keep track of change outs, substitutes etc.

Therefore inconsistencies (or ergo similarities) might well be indicative of overt or covert reasoning. At least enough to peak the interest I should think.

[Wubbly]

I wonder if the simulations would run better if the distance unit was set to millimeters and the sim modeled in millimeters instead of meters. When the computer stores numbers, it can store a whole number exactly, since every whole number is an exact sum of powers of two, and the computer stores number in the binary system. But for numbers with decimal points, some are exact and some are approximate. One half, one quarter, one eight, … are all exact sums of inverse powers of two. But one tenth is not, so the computer only stores it with a certain amount of precision based on how many bytes of memory are allocated to store each fractional number. You can tell the simulation a number is single precision, or double precision, but sometimes I feel I get cheated out of precision. If I model in millimeters will anything work faster/easier/better/less missed collisions?

So I set the distance unit to millimeters, built the sim from the script code, and hit run. Nothing happened. It just sat there not moving. So I set the distance unit to centimeters, built the sim and hit run. Now it ran. Then I went in the code and changed all the numbers to x100, built again, and ran again. This time it again ran. Not sure if that was a step forward or a step backward. Couldn't really tell any difference.

Does anyone have any input on the distance unit when modelling their wheels?

[Fletcher]

I haven't found units of distance to be significant other than make your sim as less complex and cluttered as you can, and still work. I prefer meters as my units.

But I change in > World > Accurate > Animation Step 1000 plus > Integration Error Automatic > Integrator Accurate (Kutta-Merson) > Significant Digits 6 plus.

The Significant Digits is related to what units you use.

You can get ridiculous accuracy but does it achieve anything other than slowing things down ? Maybe you already looked at all these things ?

[Wubbly]

I only fiddled with World -> Accuracy -> Animation Step. Changed from 0.05 to 0.005
Now I have more options. Thanks.

[ME]

WM2D uses the units as set in "menu|Numbers and Units". But when using more exotic units than SI, then it needs to use conversion mechanism to convert things back and forth to their exotic units.
So with a velocity of "centimeters per second", for example, it continuously needs to multiply by 100 *100 to convert things into Joules.
But I wouldn't worry too much about this.

It works internally with double precision floating points, accurate to about 16 decimals. And stored as some scientific notation where you can shift the decimal point a few hundred places and keep the accuracy.
So 1 meter can be administered within a femtometer (1e-15).
But don't expect to combine things with a spread between a meters and a nanometer (1E-9), or a kilometer and a micrometer as shifting-decimal-point alternative
When we would apply Pythagoras to those numbers, this smallest number would simply disappear because it lacks accuracy to hold it in memory.

When in doubt of accuracy of the simulation, then you can compare the end-results between runs of simulation with increasing animation step and a lower integrator error.
I usually set the animation step to 1 khz, and usually the integrator error to 1 millimeter.
I think/suspect that the significant digits setting can be kept on automatic, unless you really aim for insane accuracy.

[Wubbly]

MT-9 Version 2.0

Had MT-9 running through my head. Wondered if I could come up with a different pulley connection system for the weights. A different connectedness principle for the model.

Instead of connecting one weight directly to another, a pulley system is run from:
Weight(I) -> to Center Of Wheel -> to Outer Rim -> to Weight(I+N).

You can get better leverage when pulling on the weights if you pull from the outer rim. Plus the pulleys are frictionless so that shouldn't slow things down.

Modified the wheel to run CCW because it’s easier to think in terms of positive angles. A selection from the dropdown of I+7 would make each weight pull on the one behind it when running CCW (since the "+" increments Counter Clock Wise).

After you build the model, you can change the rope length. It runs better if you select the rope length before you run it in WM2D. Most of the configurations are a sloppy mess, and the final outcome is … well … you guessed it.

[Wubbly]

Alternate words to rednecker: https://www.youtube.com/watch?v=87pCx_wR_l4

My wheel's bigger than your wheel,

and I'm more Bessler than you.

Ha!

[Wubbly]

Was playing with an old sim from Ken Behrendt from 2005. It's slightly different than his but the final outcome is the same.
https://www.besslerwheel.com/forum/down ... er=user_id

It has some similarities to MT 19, 21, and 23, but has no ramps or cross-poles.

Ken only posted pictures, so I had to recreate the sim. I wanted to see how it would run. What surprised me about this design is how 'balanced' it is. As soon as the motor is turned off, it quickly becomes a pendulum.

[Georg Künstler]

of course it does Not Work, because you have removed the Second system. to Work you always need two system which Can interact, One is arranging the other are the Keywords.

[Wubbly]

When I first wrote the ring code, I thought it was fairly useless. Didn't think I would ever use it, but ended up using it in many of my WM2D builds. After figuring out how to use text boxes in a dialog box, I added these to the ring code to make it more user friendly.

Attached is the ring code updated to include a dialog box.

[Wubbly]

Attached are some WM2D scripts to create ramps. One creates an inside ramp, the other an outside ramp.

The inside ramp might be useful to stop a mass from falling inward. Probably more useful in quadrants 1 and 2.

The outside ramp might be useful to stop a mass from falling further outward. Probably more useful in quadrants 3 and 4.

Each initiates a dialog box with instructions on user inputs.

The inside ramp can span multiple quadrants.

The outside ramp can only draw one quadrant at a time. If you need it to span more than 1 quadrant, draw another ramp in the next quadrant.

The solution is probably not in ramps, but with every simulation you learn something new.

[Wubbly]

Here's my take on MT-5.

In the simulation, the rings are pinned to the background and do nothing other than show you where the slide limits are for the masses.

The main circle is attached to the background at (0,0), and the motor is attached to the main circle (0,0) and the background (0,0), but when you run the simulation, the main circle slowly "slips" lower and lower as the simulation runs. Not sure if that is a WM2D bug, or if I set something up wrong.

Has anyone come across this problem before in their simulations?

[Wubbly]

MT-11

This is my interpretation of MT-11. It is similar to the MT-9 simulation except that the weights connect between levels1 and 2. You can choose which sectors to connect (opposite, adjacent, etc.) and the weights on levels1 and 2 can have different mass values.

Start the simulation with the motor on, then after a period of time, turn off the motor.

An acute mind will readily see and grasp what to make of this thing.