MTs, WM2D, and WM Basic Language Script Code

[Wubbly]

This thread tries to model a few of the MTs using WM2D.
The models are written in WM Basic Language, which is Working Model's scripting code based on the Basic programming language.
Instead of attaching a WM2D file, a zip file will be attached containing a ".WBS" file which is the extension WM2D uses for their script files. Download the zip file, open it, then open the ".WBS" file and place it in a folder where you can find it later.

There are several ways to get the script into WM2D.

1) If you place the WBS file in the folder where WM2D looks for scripts, the script will be available directly from the SCRIPT menu in WM2D.
The folder where WM2D put scripts on my computer is shown in one of the .jpg attachments below. Your experience may vary based on your version of windows and your version of WM2D.
Windows coughed and choked a little when I tried to place a script in that folder, saying it was a protected folder, but I was able to do it from outside of WM2D and in a windows folder.

Or

2) Create a new folder specifically for your scripts and put the WBS files in that folder.
Open WM2D,
Open the script editor: Menu -> Script -> Editor
Select File-> Open
Browse to your script folder, select the script and press OPEN
Press Run from the script editor
Press Run from WM2D

Or

3) Open the WBS file in a text editor e.g. Notepad.
Select the entire contents of the file using the keystrokes: ctrl-A
Copy the entire contents to the clipboard using the keystrokes: ctrl-C
Open WM2D.
Open the script editor: Menu -> Script -> Editor
There are two lines in the file that say:
Sub Main()
End Sub"
Delete those two files (but don't use ctrl-x because it might replace the contents of the clipboard).
Press ctrl-V to paste the contents of the clipboard into the script editor.
From the Script Editor, select Run -> Start
The code will build the model.
You can then scroll and zoom to position the model on your screen,
then press Run from WM2D toolbar to run the simulation.

[Wubbly]

I only plan on modelling a few of the MTs, (as in 2 or 3 of them), but we'll see how it goes. Since none of the MTs run by themselves, don't expect anything earth shattering to come out of this thread.

Let's start with MT1.

Attached is a zip file that contains ".WBS" code to create an MT1 simulation.

It's a fairly simple model.
A background wheel with one slot for each sliding mass.
On each side of every circle mass there is a separator constraint that stops the movement of the sliding small circle mass.

[Wubbly]

The MT1 simulation initiates a dialog box where you can select the parameters of the build.
You can have from 1 to 18 masses.
You choose the "slide distance" which is the percentage of the radius that the mass will move.
You can set the mass of the background wheel, and the mass of the sliding masses.
You can select the initial angular velocity of the background wheel.
Select the parameters you want, and press OK.
The build places three input sliders on the screen. After a run you can press Reset, change the parameters with the sliders, and run again to see the affect.
Attached is the dialog box that the script initiates, and a sample build.

[Wubbly]

And just for fun: Taylor Swift - ME
https://www.youtube.com/watch?v=FuXNumBwDOM

[Wubbly]

MT-1 version 2.0 has arrived!

The MT1 simulation has been updated to include springs and a motor.

You can select Draw Spring (YES/NO), and adjust the spring constant.

A motor was added, along with an on/off switch for the motor, and a motor velocity input slider. This replaces the Initial Angular Velocity input in the dialog box.

Some code was added to try to zoom the model on the screen, but you'll still probably have to pan and zoom it before you run it.

Also, the background wheel was replaced with a hollow polygon.

What's interesting to notice is how badly an MT1 performs. If you include springs to capture the energy during the outward slide, the model runs longer, but the motion still dies out over time.

After you press run from WM2D, adjust the motor speed. Then adjust the spring constant so the masses are doing the movement you want. Then turn off the motor and watch it come to a stop. Turn the motor back on and repeat the process.

[Wubbly]

These are the point calculations for the model in case anyone wants to look through the code, and a sample build is attached.

[ME]

As we say in Dutch: Good busy!

Here a WM2D-script where I reconstructed your 7 slider construction.
I added some springs. They get 'active' when at quadrant II and IV (upper left, lower right) of the axis).
...or they 'deactivate' when in the other quadrant, and thus automatically collapse by gravity. So it lifts in quadrants II and IV.

A sneaky simulation hack, but nevertheless it will accelerate (about 0.5°/s²) the wheel until it reaches 52.4°/s
Enjoy :-)

[Wubbly]

Wow. Thank you Marchello. I knew I would have to add catch and release mechanisms to the masses and was hoping it could be done with ActiveWhen statements but I hadn't gotten to that point yet. Bodies in an array. That's an interesting concept.

And then activating the springs only in quadrants II and IV.
gwrkcons.ActiveWhen.Formula = "(body["& idx &"].p.x*body["& idx &"].p.y)<0"
Good stuff!
Or maybe activating/deactivating the spring when the slot is at a specific angle, or maybe when the spring is at a certain length. So many possibilities. There's an old Jonathan post where he talks about attaching a rod between two bodies and using the ActiveWhen statement on the rod. It didn't make much sense at the time.

I played with your sim a little and noticed that the mass would still slide in the slot even though it was in a quadrant where the spring was not active. Not sure if that's a good thing or not. If the background circle is given an initial angular velocity, the wheel did accelerate until it reached some steady state.

[ME]

Bodies in an array. That's an interesting concept.

Obscurities of the situation :-)
While there exists an internal "bodies" collection, there was something with the index not lining up.
So instead of chasing down a body with some find-function while just roaming in the small scope of one single script, body serialization in an array just lines them all up just as we need them. It makes our lives so much easier.
Perhaps we could technically shave a few bits here and there by just doing an integer mapping to bodies.item(#), but we already have the body-object at creation and still not that body-index.
So why bother :-)
btw, it's indeed unfortunate that not all body-parts and properties are exposed (things like color). It has been a while, but I remember body collisions are also an unrefined system-wide all-or-nothing situation.

(I totally understand this all sounds a tiny bit awkward, when not familiar with the intimate details of this scripting stuff)

And then activating the springs only in quadrants II and IV.
gwrkcons.ActiveWhen.Formula = "(body["& idx &"].p.x*body["& idx &"].p.y)<0"
Good stuff!

yes thanks. More importantly, is it an exclusive-OR analog, or an analog XOR ?

Or maybe activating/deactivating the spring when the slot is at a specific angle, or maybe when the spring is at a certain length. So many possibilities. There's an old Jonathan post where he talks about attaching a rod between two bodies and using the ActiveWhen statement on the rod. It didn't make much sense at the time.

That "mechanical concept" certainly has room for improvement. While improving, it's easy to forget that it's a bit hard to implement in real life..
Yet, we may learn something from the induced motion, path and timing. We could try to figure out if it can be mechanically reproduced without this spring-trick.. or find out if it's still somehow physically possible.
Instead of making things better in simulation-world, I suggest we should try to make it worse: Like finding the most lousy spring setting that still works until we can eliminate it completely.... and still accelerates.

I played with your sim a little and noticed that the mass would still slide in the slot even though it was in a quadrant where the spring was not active. Not sure if that's a good thing or not. If the background circle is given an initial angular velocity, the wheel did accelerate until it reached some steady state.

Note that a "deactivated spring" is simply "turned off" and the rest (actually Body[2]..Body[8]) is still subject to gravity, The spring is still drawn and visible.

As it goes:
In quadrant-I it 'collapsed' towards the center due to the motion of that body[] due to gravity.
At 12-o'clock it gets activated, and the spring suddenly gained spring potential energy, because it stretched relative to its given length.
As a result it shoots up in quadrant-II.
It may wobble around because of its springyness, but at 9-o'clock then spring is turned off again.
Now the spring collapses to the rim while in quadrant-III.
At 6-o'clock the spring is activated again, and the spring should have suddenly gained spring-potential but it doesn't move because it's not enough (setting the spring-length to eg. 0.4 helps to balance this effect with what happens at 12-o'clock )
So currently in quadrant-IV it 'waits' until just below the 3-o'clock position, and the slope is shallow enough for the spring to be able to push that body[] upwards with the amount of spring potential it has.
etc.

Is this Jonathan's post? http://www.besslerwheel.com/forum/viewt ... 5404#15404

Anyway... this is just MT001
Now the rest of them :-p

[Fletcher]

Altho I don't use any scripting in my models I enjoy your discussions, and solutions. I just haven't found a need for them as yet. Maybe one day, then I can come back here and read again and understand the nuances. ATM I can build a sim, and refine and simplify it, and put some lipstick on it, pretty quickly, so don't need a bunch of memory hogging automation for stuff I can just knock out.

What has always been a problem is simple latching and catching arrangements. They really suck memory.

I know we have talked about it before ME, but it would be useful to have rods or rigid joints activated and deactivated by reference to a Body[1] position in quadrants or other smaller divisions as you are talking about i.e. referencing the background grid coordinates. Either degrees a disk has turned for example, or +ve, +ve grid coords etc. I kinda do that already in the ActiveWhen field and using IF or Or (AND) statements etc. For simple tests just using time rather than position, or velocity etc.

The crux of the catch and latch problem for me is that WM continues to total up degrees turned from a starting datum. I'd like some 'counter' Output to restart the degrees again at 0 (360) instead of climbing with each turn. And then reference that Output.

I know you suggested a formula fix previously ME, could you put up an example again plz.

Then we can use the ActiveWhen field with either degrees turned or grid position with accuracy and reliability, without hogging memory too much I hope.

That would allow me for example to build mock-up sims with latches that can continue to rotate more than 360 degs, and not be one-shot sims as I mostly do now when needing catches or latches.

Cheers.

[Wubbly]

Yes Marchello. That's the Jonathan post I was thinking about. Thanks.
A simple ratchet using a rod, and an active when "Body[1].v.r<0"
I wonder if something like that can be used as a catch and release mechanism.

And Fletcher, click on search -> advanced search, type in: mod AND 360
click on Search for all terms, and it brings up this post:

http://www.besslerwheel.com/forum/viewt ... 995#154995

If you mod 360 the angle, it will reset the value back to zero when it passes 360. Maybe that's what you were looking for.

[Fletcher]

Thanks Wubbly .. that was it. And ME.

Have now made and saved a basic test rig with a disk and motor drive. Then created an Output from Menu Measure > PVA > All.

Modified the Body[1].p.r to Mod(Body[1].p.r,360) to give it the 360 degree range before reset to zero. Works a charm.


Now anyone can use a rod or rigid joint as a catch or latch system. In the Properties > 'Active when' field turn off and enter an IF statement to control when it is 'live' and when it is not.

e.g. If(Output[10].y1<-90,1,0) for CW rotation

N.B. if the disk is rotated from the addition of a mass weight at the rim (like a pendulum) the rod latch does its job. If I turn the disk with a motor the motor overrides the rod (it doesn't work). I'm guessing I'd have to add the same IF statement into the Motor Properties "Active when' field ?

[ME]

If you mod 360 the angle, it will never go over 360. I haven't tried it yet, but maybe that's what you were looking for.

Menu: >Measure > Time
Now enter at the Properties, (don't forget to invent a label):
y1: time
y2: MOD( Body[1].p.r, 360 )
y3. MOD( Body[1].p.r+360000, 360 )
y4: MOD(MOD( Body[1].p.r/90,1)+1,1)<0.5

The y3-equation can handle up to 1000 negative rotations until the formula wears out. When it happens, then either add a zero, or use the "better" option: MOD( MOD( Body[1].p.r, 360 ) + 360, 360)
The y4-equation flips every 45° of rotation, even when the angle becomes negative for an infinite amount of rotations. Also, for the output: true=1, false=0

Then we can use the ActiveWhen field with either degrees turned or grid position with accuracy and reliability, without hogging memory too much I hope.

But some things get dropped from the simulation. Depending on the latch it usually has a distance to cover and could be affected by centrifugal forces. As such there could be timing issues to keep in mind.
Are there designs that accelerate by means of some clever latching?


NB. If you want an ideal ratchet: Body[1].v.r<0

[MrVibrating]

Thanks Wubbly .. that was it. And ME.

Have now made and saved a basic test rig with a disk and motor drive. Then created an Output from Menu Measure > PVA > All.

Modified the Body[1].p.r to Mod(Body[1].p.r,360) to give it the 360 degree range before reset to zero. Works a charm.


Now anyone can use a rod or rigid joint as a catch or latch system. In the Properties > 'Active when' field turn off and enter an IF statement to control when it is 'live' and when it is not.

e.g. If(Output[10].y1<-90,1,0) for CW rotation

N.B. if the disk is rotated from the addition of a mass weight at the rim (like a pendulum) the rod latch does its job. If I turn the disk with a motor the motor overrides the rod (it doesn't work). I'm guessing I'd have to add the same IF statement into the Motor Properties "Active when' field ?

Good tip on using modulus! Figured something like that must be possible, hadn't figured it out yet tho. I wonder, would it also work for time, to produce cyclic periods? Previously i'd've tried something like "make two clocks, add 0.59 to one then deduct one from the other in a third clock, hiding the other two" - to try get say a 1 min timer.. will have to have a play around..

Quick word to the wise tho - forget about synchronising your momentum gain principles to gravity or even wheel angle per se.. So you can still use them fine for any energy-management system, but for the prime mover (the part of the action where momentum, rather than just KE, is gained), the system probably doesn't want to remain synchronised to external coordinate space..

..i've reached a conceptual breakthrough here so i'll try relate it as clearly as poss:

• if the momentum gain principle IS synched to the rotation, including syncing to gravity - especially if the momentum gain is being sought from gravity / sinking counter-momentum to gravity or whatever - then inevitably, per cycle momentum yields are going to be inversely proportionate to angular velocity.

This appears to be a de facto inviolable law of spinny things - you get your biggest per-cycle momentum gains when first starting up... and then it's all downhill from there. Per-cycle momentum yields ALWAYS decrease with rising RPM, if their gain mechanism is intrinsically linked to the rotation angle..

To put it in more tractable terms, we're looking for a momentum gain principle that is asynchronous to RPM - so, 'angle-agnostic'.

Because, if momentum per-cycle yield must necessarily decrease with rising RPM, then mechnical OU is only physically possible if the energy cost of that momentum also decreases with speed - like some kind of 'duty cycle' reduction, where the 'on' time per cycle naturally got shorter as RPM's rise.. and there just ain't nothing like that on offer, best as i can see. Bestest i've managed is to keep input energy constant per cycle, as momentum yields dropped; net result was always ½mV² tho..

So the 'breakthrough' is in realising that the only way outa that bind is to forget about synching the internal mechanism rigorously to external angle.

To put it another way, what appears as 'one cycle' to us from an external view of the wheel's operation is only part of one cycle from the perspective of the internal momentum gain (the 'divergent' reference frame). The actual ratio of internal cycles to system revolutions may be dynamically variable.

Because of this realisation, i'm now more skeptical that Bessler could've been pulling momentum from gravity, as i'd been investigating. Any such scheme necessarily must be synched to gravity's vector, yet this invariably means less time-gravitating as RPM's climb, hence momentum yield decreases by the inverse-square of velocity, thus tracking ½mV² even when per-cycle input energy converges to a speed-invariant constant.

Thus the only way outa this straightjacket is to wriggle free of Cartesian coordinate space entirely. No kind of "drop this when vertical" or "spin that when passing 9 o' clock" is gonna cut it - all such regimes are digging themselves into a hole. We need a momentum-gain principle that DOESN'T CARE about any external vestige of 'angle'.

Like i say, for an energy-management system it's still fine - perhaps even inevitable; Bessler's one-way wheels were obviously not entirely agnostic to angle, but the GPE's must've been an energy-management system, and not responsible for the per-cycle momentum gains..

[Georg Künstler]

MrVibrating wrote:

Thus the only way outa this straightjacket is to wriggle free of Cartesian coordinate space entirely. No kind of "drop this when vertical" or "spin that when passing 9 o' clock" is gonna cut it - all such regimes are digging themselves into a hole. We need a momentum-gain principle that DOESN'T CARE about any external vestige of 'angle'.

Yes, thats it, you move the Cartesian coordinate.
It is as when you stand on a rug, and thereby the feet are pulled away.

So with a fix axle you cannot win. Bessler said the axle should also move.
A movable axle and not a turning axle, the turning point and cog free to wriggle.

How will you simulate a moving Cartesian coordinate system ?.