Toad Elevating Moment

[MrVibrating]

Hmm... just got to the bit where i'm fixing the parallelogram to the stand, and it suddenly struck me that i can't actually model what Bessler's done here, because the beams pass through the stand - i mention it because while it's irrelevant to the apparent operation of the mechanism, it still seems an unnecessary over-complication.

So why would the beams pass through the width of the stand, rather than being fixed to its face? It makes no difference to the mechanism as shown, hence there's another reason for it.

Either its a mere absent-minded over-extravagance, or this type of pass-through was on his mind for more practical purposes. We're immediately reminded of his descriptions of his axle, no - with its many holes and compartments..?

[MrVibrating]

Right, completed a first draft, and it appears there IS some kind of dynamic dis-equilibrium...


I've added some mass and angular momentum to the pendulums' wheels, and also to the parallelogram's horizontal beams. I've tried to tweak the values to sync the motions, but for now this only holds for the first stroke.

Still, this is enough to see that the angular momentum of the parallelogram adds and subtracts asymmetrically from that of the left and right pendulum pairs - the left pair complete their arc before the right-hand pair.

Hard to see what use this might be for now, but it's confirmed my suspicion that there's a dynamic disequilibrium, if not a static one...

The image below shows the start and end positions for the first stroke..

[MrVibrating]

After some head-scratching i've found one way to impart KE from the pendulums to the parallelogram - by connecting the upper right pendulum to the lower left one via a rigid rod.

It still doesn't do anything interesting though. Just rocks a while, slightly chaotically, gradually scrubbing off KE..

So i'm pretty sure there's no chance of any useful feedback mechanisms here... Whatever was on the guy's mind, it's not at all clear from this doodle.. Mind, i didn't include the large upper pair of pendulums, since i cannot see any mechanical purpose to them.

I know some folks have speculated they're connected via strings, however i'm fairly sure those dotted lines are simply indicating the curved paths of the pendulums.

I'm also aware that pendulums connected via a rigid frame will eventually synchronise, but i'm doubtful WM2D would be able to simulate this effect - in fact as i write this i've just decided to double-check this point with a pair of strung pendulums hanging from a horizontal beam, and they remain out of sync for the duration of the sim.

There's a few more loose ends to chase up - perhaps having the whole system rotate, or seeing how these paired pendulum behave in other orientations (as far as a 2D sim will allow).

On this last point, there appears to be some correlation between MT143 and the preceding sketch, 142 - with the main difference being the parallelogram in 143 over the single rotating balance beam in 142. However i suspect that if this sequence does represent a 'right path' progression of ideas, we'll not be able to follow it in two dimensions...

What seems pretty certain for now is that there's no way to convert CF into precessional torque, nor vice versa, in the current scheme of things... for that, i'll either need a 3D sim, or a weekend or two banging the metal...

[MrVibrating]

Still thinking about this CF-on-CF action, but for now i've just been given a prod by Google's Foucault dedication today - the man who named the gyroscope, after using it to replicate his famous pendulum experiment.

Have to admit, the spin of a gyro just seems intuitively incongruent with Bessler's wheels - i'm only really considering it on grounds of first principles.. but perhaps, as with Foucault, the swing of a pendulum is a sufficiently complex inertia to be playing with...

[MrVibrating]

Interesting system, for anyone with WM2D:

I was playing with the idea of rectifying a pendulum's swing via a catch - the catch lets the pendulum swing by in one direction, but then arrests it on the back swing.

This seems to create energy. I've ramped up the accuracy, so don't think it's an error.

Be interesting to see if the gain can be amplified... the system needs careful tuning to sync the inertial moments..

[MrVibrating]

...same again, with a 1kg bob on the pendulum.


One early observation is that the gain appears proportionate to the angles between the wheel and pendulum - at the moment the sync is such that the catch barely does anything, only rarely catching the backswing as intended.

If however it could be tuned such that the pendulum is caught when closer to horizontal (as per the starting conditions) then the per-cycle gain would be optimised..

I'm guessing this is just a matter of tweaking the resonances?

[Fletcher]

Interesting - why are you capturing the GPE Output of the large background flywheel (Body[1]) - surely you are interested in the Grav PE of the rotating parts v's the Rot KE of Body[1] ?

N.B. if you want to know the TOTAL KE of the sim system make an Output [say measure Time] then change the y1 to Kinetic Energy & equation field to ... Kinetic() - this will measure all system Kinetic Energy.

N.B. leave the () empty as it grabs all system movement, both translational & rotational.

ETA: added a sim which may be of use to you with Output Box for Total System KE and Energy Comparisons.

[MrVibrating]

Cheers for the advice mate, noted... TBH i'd intended to select RKE, hit GPE by mistake and just didn't delete it..

But watching slowly, i can't see the catch doing anything, now.. i swear it was when i first got excited, honest! I'll see if i can get it back again - the pendulum needs to catch high on the backswing when it's still full of PE, else the wheel's just coasting on the initial PE.. (as it is now)

I'll have a play around with it next week..

[MrVibrating]

Just had a quick brainstorm - will probably end like the rest of 'em but just wanted to scribble it down here quickly before i forget it, or get hit by a bus or summink...

I'd been mulling over MT41 at work today - that tantalising clue about horizontal scissorjacks has been gnawing at me again, so, without any major insights during the day, i had a leaf through JC's original Machinen Tractate, looking for little details i might've previously missed (found a few too), until i got to MT37, where the scissorjack-type designs begin (the mysteriously-named 'oval discs' mimic the scissorjack action, whatever they are). MT37, and MT38, 39 and 40 all feature this type of actuator.

Then of course we come to MT41, apparently extolling the superiority of horizontal jacks over vertical ones. But then, in the next plate, MT42, we again have another set of jacks, this time vertical. Since these plates are all deliberately numbered, and are said to follow a natural progression of ideas leading to the breakthrough, if horizontal jacks are better then why would he then double-back on himself in the subsequent plate, with more vertical jacks? Wouldn't it have been more consistent to finish dealing with all the 'wrong' orientations before ending the lesson with the 'correct' one?

Hence we come to the word 'application'. Something about its use here had never quite settled with me - i'd interpreted the intended meaning as "applying" = "orienting". Indeed, this reading is implicitly reinforced by virtue of the jacks being oriented horizontally in that particular design. And what with all the other questions this plate - and the whole series - throw up, this little ambiguity didn't seem to warrant too much attention; it seemed sufficient to surmise that the clue clearly pertained to horizontally-oriented scissorjacks.


This evening however i noticed something else....

In MT41, our better, horizontal application of the scissorjacks are actuated horizontally, too. That is, force is applied horizontally, as well as the jacks themselves being horizontally oriented.

And then, coming back to the following plate, MT42, we notice that this vertical jack is also "being applied" (ie. operated) via a horizontal application of forces.

Thus, what truly distinguishes 41 and 42 from the other similar schemes is that all of the others are actuated by the application of a vertical force - invariably that of a GPE interaction. IE. something falls vertically, causing the jacks to operate, regardless of their given orientations.

Obviously, these designs all fail in that they're robbing Peter to pay Paul, simply moving mass around the GPE gradient, to no net effect - as we (should) all know by now, simple GPE translations like this are always a zero sum deal.

I can see i'm starting to ramble so i'll cut to the chase - MT41 and MT42 don't drop masses to activate their lift mechanisms.

For some reason i've a hunch this may be significant - alternatives to GPE certainly 'spring' to mind, and both these plates might also be interpreted as hinting that there's sufficient energy in the rotation of the OB wheel to use the jacks for raising the weights.

Obviously, if this lift energy is stored in springs, we still have the familiar problem of resetting them, but this implication that scissorjacks enable a cheap lift, relative to the resulting torque, is intriguing... i've played with mirrored jack actions previously, but couldn't see an exploit there... dunno... but yeah, i've got such a raging clue right now, and i just wanted to share that wiv yuz'...?


More later, if this goes anywhere...

[MrVibrating]

OK get this: s'pose we got a scissorjack, right, with like all little wheels on all the corners? And the inside of the wheel could be like a V shape - and the jack gets wedged into it by gravity acting on it, and on a weight on top of it... and the combined weight of this top-heavy jack on coasters pulls it down, squeezing it into this crevice in the bottom of the wheel, and thus forcing it to extend upwards?

Would that work? Could the force of the weight be used to make itself rise? It seems dumb cos a rising weight costs energy, it shouldn't pay to lift itself, obvioushly. But the supporting points of the net system of jack and weight does get lower... however it also gets thinner, and thus the jack gets taller.


Can a jack be made to lift a weight by dropping the whole thing into a tapering trench? If so what's the minimal system here?

I'll be testing this out shortly...

[Fletcher]

I've built that in WM - I'll have a look at what I can find.

[MrVibrating]

LOL ta but just tried it meself - 10° incline, 5-link jack, absolute stasis. I mean it contracts a wee bit, but that's it - it just sits there, stuck fast.

I tried starting it from a variety of extensions (ie. mostly contracted, mostly extended and midway at 45° on the crossbeams), and with a variety of weights on top, with no change in result. It was a dumb idea.

Only got excited about it cos it seemed an elegant way of applying horizontal force to a jack. Stands to reason it can't actually operate it tho...

ETA: Model attached

[rlortie]

Cannot download, all I get is computer talk.

Helloha, started putting his .wm2d apps in a .zip folder which I can download.

Ralph

[Fletcher]

Right click on download > select 'Save Link As' > put it where you want [in WM files folder] BUT change 'File Type' from 'Text' to 'All Files'.

Then go to downloads & recover it.

[ruggerodk]

For all the rest of us non-wm2d: We can't see what you are talking about.

A screendump of the sim would be a catch ;-)