Vanilla 1.0 is a product of Lussumo. More Information: Documentation, Community Support.
overconfident:Al, Warmer there than it is here. Have you gotten to my whisper, back a page or 2?
alsetalokin:Looking. Meanwhile, an update from Desertphile.
This guy makes a lot of sense.
Even if he does have a wee dram too many now and again.
(language! shame on you DP! there are children and other small minds watching!)
alsetalokin:Looking. Meanwhile, an update from Desertphile.Thanks! (What the hell are those things hanging behind him? Puppets? Does he work in a kindergarten, perhaps?)
This guy makes a lot of sense.
Even if he does have a wee dram too many now and again.
(language! shame on you DP! there are children and other small minds watching!)
alsetalokin:
This guy makes a lot of sense.
(language! shame on you DP! there are children and other small minds watching!)
/:
Anyway, I have found a function to log values at specified position during rendering (to a HTML, which you are supposed to load in Excel, wtf) in Vizimag and tried to get some data at similar positions as you did. I wonder if I could make it look more like your data and estimate the real motion and interactions better afterwards, even with this simple software. But first I'll have to be sure what have I actually plotted, because I have no idea - I'll think about it on my way to work.
alsetalokin:
Looking. Meanwhile, an update from Desertphile.
This guy makes a lot of sense.
Even if he does have a wee dram too many now and again.
(language! shame on you DP! there are children and other small minds watching!)

Harvey:I have some experience with Vizimag (including programatically creating a 3K line script) If you want my code let me know.Huh, how else would any sane person do it? It feels painful just to think about entering the values by hand!
C:\Program Files\Vizimag 3.15\Animations>wc -l *.txt
3206 ocmpmm-v2.txt
3288 ocmpmm-v3.txt
1788 ocmpmm-v4.txt
3928 ocmpmm-v5.txt
3928 ocmpmm-v6.txt
3928 ocmpmm-v7.txt
14248 ocmpmm.txt
3568 ocmpmm100.txtGenerating the script is easy, what sucks more are the bugs, occasional crashes, stupid limitations (two decimals should be enough for everybody!), ugly design, slow computation, etc.




alsetalokin:Now I'm going to bed.
(Just one more story Jag, I promise...)
alsetalokin:"It was 2 years before he realised "bloodyarchitect" was two words."
But anyway this scope probably wouldn't be able to follow some of those spikes that / has obtained.
However it did follow, barely, the homopolar voltages, which were nice and spiky...
Thanks especially for those efforts, folks.
WhiteLite:It would be interesting to see what this looks like in a Visimag animation but I haven't had any experience animating rotational movement, only linear movement.Somehow like this, perhaps.
/:WhiteLite:It would be interesting to see what this looks like in a Visimag animation but I haven't had any experience animating rotational movement, only linear movement.Somehow like this, perhaps.
WhiteLite:The only thing is that diagram is suggesting the anti-gearwise rotor is in attraction directly opposite a rotor magnet and in repulsion when between rotor magnets while my hypothosis was the other way round. It's a shame some of Al's flash photography pictures were taken down or I could confirm this although I did see this one on OU.com [...]Actually, when I created the animation script for this, there had been only one detailed picture shot with flash, so it could even be moving gearwise and I wouldn't know. I'll try to revalidate the rotation synchronization from the more recent material.
/:Actually, when I created the animation script for this, there had been only one detailed picture shot with flash, so it could even be moving gearwise and I wouldn't know. I'll try to revalidate the rotation synchronization from the more recent material.
WhiteLite:So, from what I saw now, it's still quite unclear, but more likely in your direction. I've left it to render in Vizimag and we'll see if it looks any better./:Actually, when I created the animation script for this, there had been only one detailed picture shot with flash, so it could even be moving gearwise and I wouldn't know. I'll try to revalidate the rotation synchronization from the more recent material.
Thanks, that would be fantastic!
Wicked:Perhaps I'm not up to speed with all the peculiarities, but here's my amateur analysis, for what it's worth:Stored as what? L? B? Doesn't seem possible to stash away that much PE without invoking hidden variables or somesuch...
1)When you first spin the rotor you are storing energy in the rotor and the 3 stators act as loads.
2)When you sync the middle stator in AGW rotation, you are adding energy to the system, and the rotor and middle stator act as a combined flywheel. This removes almost 1/3 of the load, so the rotor will accelerate. The outer 2 stators still act as loads.But he stops the middle statmag in the process of reversing it. So he removes some energy, then returns it in the opposite direction.
3)Finally, you stop the 2 outer stators, removing almost 2/3 of the original load and causing the rotor to accelerate considerably. You end up with both the rotor and the middle stator with stored energy and very little load other than bearing friction and air friction.The acceleration of the main rotor seems to present considerably more than the combined L of the two idlers.
The only thing not apparent to me is why AGW rotation would act as a combined flywheel. Did I missing anything important?CoE.
(at least you can't blame me for overanalyzing)Heh. Keep at it eh...
WhiteLite:I don't think the stator magnets would count as a load. When the rotor is spun up it moves the gearwise rotors too so you are adding KE to both rotor and stators, (and the anti-gearwise stator is given KE by hand as well). The only things that would kind of count as loads would be bearing friction, air resistance and lenz effects in the dampners and other bits of metal. I'm suprised it spins so long with these factors to be honest.
zeropointe:and even if the other two stators are loads - drag - then removing that drag won't cause the rotor to accelerate unless it is somehow powered, rather than a free spinning flywheel. think about eg bicycle brakes. if you brake when you're freewheeling on the flat the bike doesn't accelerate when you release the brake.
Wicked:WhiteLite:I don't think the stator magnets would count as a load. When the rotor is spun up it moves the gearwise rotors too so you are adding KE to both rotor and stators, (and the anti-gearwise stator is given KE by hand as well). The only things that would kind of count as loads would be bearing friction, air resistance and lenz effects in the dampners and other bits of metal. I'm suprised it spins so long with these factors to be honest.
I don't agree. The prop does the same thing and we're calling that a load.
), except for maybe air resistance on the moving stator but I don't think we're counting that.
Wicked:Ya. There's gotta be bearing resistance on the stator. That makes it a load. Although, that still doesn't explain the acceleration when removing the load.
)
alsetalokin:
But say, just for grins, that the power dissipation was a factor of ten lower. Would it be possible for a nearby EM source to provide even that much?
/:WhiteLite: So, here is the result.
The main difference to me is that in the previous version, the rotor magnet was repelled when it's was coming close, then catched in the closest proximity on both poles and finally attracted quite long on its way away. All this would probably slow the device down fast.
With the stator magnet flipped, as you suggested, this is of course different. The rotor magnet is attracted when it's approaching, then repelled during the closest encounter and again attracted on the other side when retreating. If the distance is the main factor, it could have big effect.
But it's still only a dumb simulation, we don't know how the interaction really looks like nor how it work.