If you need assistance, please send an email to forum at 4hv dot org. To ensure your email is not marked as spam, please include the phrase "4hv help" in the subject line. You can also find assistance via IRC, at irc.shadowworld.net, room #hvcomm.
Support 4hv.org!
Donate:
4hv.org is hosted on a dedicated server. Unfortunately, this server costs and we rely on the help of site members to keep 4hv.org running. Please consider donating. We will place your name on the thanks list and you'll be helping to keep 4hv.org alive and free for everyone. Members whose names appear in red bold have donated recently. Green bold denotes those who have recently donated to keep the server carbon neutral.
Special Thanks To:
Aaron Holmes
Aaron Wheeler
Adam Horden
Alan Scrimgeour
Andre
Andrew Haynes
Anonymous000
asabase
Austin Weil
barney
Barry
Bert Hickman
Bill Kukowski
Blitzorn
Brandon Paradelas
Bruce Bowling
BubeeMike
Byong Park
Cesiumsponge
Chris F.
Chris Hooper
Corey Worthington
Derek Woodroffe
Dalus
Dan Strother
Daniel Davis
Daniel Uhrenholt
datasheetarchive
Dave Billington
Dave Marshall
David F.
Dennis Rogers
drelectrix
Dr. John Gudenas
Dr. Spark
E.TexasTesla
eastvoltresearch
Eirik Taylor
Erik Dyakov
Erlend^SE
Finn Hammer
Firebug24k
GalliumMan
Gary Peterson
George Slade
GhostNull
Gordon Mcknight
Graham Armitage
Grant
GreySoul
Henry H
IamSmooth
In memory of Leo Powning
Jacob Cash
James Howells
James Pawson
Jeff Greenfield
Jeff Thomas
Jesse Frost
Jim Mitchell
jlr134
Joe Mastroianni
John Forcina
John Oberg
John Willcutt
Jon Newcomb
klugesmith
Leslie Wright
Lutz Hoffman
Mads Barnkob
Martin King
Mats Karlsson
Matt Gibson
Matthew Guidry
mbd
Michael D'Angelo
Mikkel
mileswaldron
mister_rf
Neil Foster
Nick de Smith
Nick Soroka
nicklenorp
Nik
Norman Stanley
Patrick Coleman
Paul Brodie
Paul Jordan
Paul Montgomery
Ped
Peter Krogen
Peter Terren
PhilGood
Richard Feldman
Robert Bush
Royce Bailey
Scott Fusare
Scott Newman
smiffy
Stella
Steven Busic
Steve Conner
Steve Jones
Steve Ward
Sulaiman
Thomas Coyle
Thomas A. Wallace
Thomas W
Timo
Torch
Ulf Jonsson
vasil
Vaxian
vladi mazzilli
wastehl
Weston
William Kim
William N.
William Stehl
Wesley Venis
The aforementioned have contributed financially to the continuing triumph of 4hv.org. They are deserving of my most heartfelt thanks.
The problem is that the simulation assumes instantaneous magnetisation thus giving an instantaneous force responce and an according inductance change. The truth is that the magnetisation issnt instantaneous due to eddy currents leading to a smaller inductance change than we think (i modeled it by applying a square root to the inductance change due to projectile presence) and it of course leads to a smaller force.
Yes, the eddy current will have 2 effects on the coils inductance. The coupling will reduce it and also the shielding effect on the projectile, which will reduce magnetisation. Both effects are frequency dependent due to the projectiles resistance for the eddy current. For low frequencies, there won't be enough voltage induced in the projectile to cause any significant current. For large f the magnetic flux coming from the coil will be very effectively reduced by the eddy current. Is your FEMM simulation run at the right f?
Registered Member #2906
Joined: Sun Jun 06 2010, 02:20AM
Location: Dresden, Germany
Posts: 727
No, i cant run it at the right frequency, because thats not the purpose of the modeling technique. The parameter extraction allready takes 2h or more (need to implement mult core processing). So i cant sweep in a 3rd dimension like frequency. Also it wouldnt help, because its a transient analysis. there is no frequency... there is just a spectrum if you analyse it with a DFT. so which frequency should the model choose?
As you may have seen in my video i have those magic correction factors to correct the acting Amp*Turns and the effective inductance change. What i need is basically extract these correction terms of the slope of the average Projectile magnetisation - this should be good enough. The question is: how? The steeper the slope of the magnetisation the less inductance change may happen. Thats the most important part right now. But the dB/dt is somewhere in the 1e3..1e5 T/s so how to get a usefull factor out of it? I mean of course i could scale it somehow and get *some* value but i would like it to be reasonable in the end.
I understand the dependence and the source of the error (what why i found solutions for the special cases) but i would like a more general solution than just squere-rooting the inductance change factor
If you know the flux phi in the projectile, you can try to correct it by subtracting the flux caused by the eddy current. Eddy voltage is dphi/dt and the current dphi/dt/R, where R is the projectiles resistance around its circumference. This flux caused by the eddy current reduces magnetisation. It doesn't really change the coils inductance but will induce a voltage in it, so that this looks like a reduced inductance. This is similar to the effect caused by magnetisation. It causes an extra flux that induces a voltage in the coil, which will look as if it has a larger inductance.
Registered Member #2906
Joined: Sun Jun 06 2010, 02:20AM
Location: Dresden, Germany
Posts: 727
Thx Uspring, i think your explaination helps me a lot to understand whats actually going on with the inductance change and stuff. I can follow your description of how the dphi/dt problems connect and thats basically what is solved by the FEM-Solvers since this is the actual thing that happens.
I however do not feel that this kind of accurate thinking helps to find a more abstract solution that is solvable by a schematic based solver. In the mean time i discovered that my theory of modelling the projectile magnetisation is a really good idea. The question is on how i can extract my magic correction factors of the should-be-magnetisation-waveform and the quasi-static magnetisation as this is calculated/exported by FEMM. I think for that another video is due. I have to practice this kind of speeking anyways.
And i am sorry if any moderator thinks that a forum works by text and not video. But the issue is so complex that i must demonstrate what i do, because even while i have provided the simulation and the data, i dont really expect anyone to work through this heap of unfinished ideas.
Registered Member #29
Joined: Fri Feb 03 2006, 09:00AM
Location: Hasselt, Belgium
Posts: 500
Here are two time-domain simulations illustrating the effect of eddy currents on the magnetic field penetration.
The first includes no loss. Penetration is very quick. The second includes a finite conductivity to both the shield and the projectile. We now see that the field "diffuses" into the metallic materials with a clear time delay. Materials are assumed to have the magnetic properties of mild steel.
Registered Member #2906
Joined: Sun Jun 06 2010, 02:20AM
Location: Dresden, Germany
Posts: 727
Hey thx for the pictures! So what program did you use? (just curiosity) I can see the difference and its the same in Comsol to which i have access to. If anyone failes to spot it: observe the most outer left field line within the projectile at the beginning of the simulation: the lossy projectiles field line is slightly curved while the other is kind of staight. I however dont think that the field lines are scaled equally in both pictures.
I managed to extract another set of abstract data of(off?) all simulations. Both FEMM and Comsol (reference simulation) export the average B-Field strength. Here is an image of both usecases (LC-ringing and the SCR-Design)
Red: What the LTSpice simulation "assumes" due to the quasi-static dataset of FEMM. Green: what the reference simulation says. (its much rounder and smaller im amplitude) Brownish: my attempt of first order low-pass filtering the red line with 1k+800nF - its not perfect but a start.
This kind of abstract data is all i can work with on schematic basis. My hope is that from the difference of the red and brownish line (which are both products of LTSpice because one is just the filtered version of the other) we somehow find a way to find the magic correction factors for the current (to adjust the overall acting force) and for the Inductance (so adjust the actual coil current). Maybe adjusting the Amp-Turns-Input of the model is wrong entirely because it changes saturation behavior. Maybe i should just correct the force that is outputted? On the other hand: since the projectile magnetisation is different (lower) reducing the Amp-Turns-Input seems to be ok.
Registered Member #29
Joined: Fri Feb 03 2006, 09:00AM
Location: Hasselt, Belgium
Posts: 500
Hi, It's a program I wrote about 10 years ago that does non-linear, time domain finite elements. Have a look here if you want to know everything about my coilgun modeling efforts!
These GIFs I had posted to the old 4HV forum, but it seems to be completely defunct and inaccessible now. So, here they are again!
Registered Member #2906
Joined: Sun Jun 06 2010, 02:20AM
Location: Dresden, Germany
Posts: 727
Wow I mean... honestly: Wooow You did a really good job there and whats more important: you presented it understandable. I went through MassAccel2.pdf completeley and scrolled through CoilgunNotes1.pdf briefly.
The fact that its close to understandable to me gives me the gut feeling that you simplified stuff enough to make it manageable. And indeed the most important thing is your Inductance function (3) in MassAccel2.pdf where i find you will get good results but not the results of a full blown FEM directly coupled solver. Interesting enough you basically used the same usecase as i do for model verification and this is kind of awesome how your model struggles the same issues as i do. In MassAccel2.pdf, page 5, Figure 4, the coil current is way too influenced by the inductance change or in other words i think your inductance changes too much - as it does in my model. Of course i am judging by using my setup compared to yours - which is inherently a bad idea. Really good work. Maybe later i work through your FEM approximation. This however is not the way i want to go. Every FEM involves way too much computational overhead. You can not for example step parameters like projectile starting position and have your answers within seconds - thats the strength of my apporximation if it will ever work. EDIT: i compiled your code to check what your analytical method yield with my parameters. I must say that i cant get it to output usefull data I have some uncertainty how you define the coils outer diameter. You ask for "a" which is shown in Figure1 of MassAccel2.pdf as inner coil radius but thats it. it also simulates quite a lot time steps (0.1sec) even the shot should be over under less than 7ms. hmmh. And the code export from your PDF sucks Your original Word-Version has mesed up all the minus-signs so it coies as illigal character.
I think the key is currently in matching the average B-Field of the projectile to the should-be-waveform. Maybe one could also gain something by subdividing the projectile into smaller pieces like 16 parts. thus extracting a more precise projectile interaction due to partial magnetisation where the overall averaged function does not work good enough. Here is the update including the new extracted dataset. ]simulation.zip[/file] If anyone is interested in having a closer tour or wants me to try ideas and observe directly what happens, PM me for skype.
Registered Member #29
Joined: Fri Feb 03 2006, 09:00AM
Location: Hasselt, Belgium
Posts: 500
Motion version 3 gives the best result, because we include saturation effects in the armature. (Inductance is overestimated in the others because there is no saturation of the core.)
Download the tarball for the source code and use one of the example input files as a starting point. You can modify the parameters and see what happens! Copying from PDFs never works as expected.
The outer diameter is not needed because we assume that the shield is non-saturable (or infinite in radius) and infinitely permeable. This is the basis for most reluctance models. It's not really correct (because the shield can indeed saturate, as the FEM calculations indicate), but it's OK for a simple model.
I had a lot of fun mucking around with these models during my period of unemployment 10 yrs ago! (It's been quite a while since I looked at them.)
Registered Member #2906
Joined: Sun Jun 06 2010, 02:20AM
Location: Dresden, Germany
Posts: 727
So last night i had a good thought about the whole thing and admit defeat with the current concept. A coilgun shot is clearly frequency (or better: d/dt)-dependent and the abstract data extracted from FEMM at the current level wont help much. One can get pretty good maching if one knows what to expect but the solution is never going to be universal. I am just not happy about it.
So maybe i should try another aproach which in theory should work.. i spoke of it before but now again: I want to subdivide the projectile in smaller pieces. Maybe 16.. 20.. 40? For those pieces i want extract their individual contributions of force and their individual magnetisation behavior (again current and position dependend). But except just using the raw data as i do now, with the Grid that the projectile subdivision brought we implement a small FEM or Finite-Differences solver with spice.
How i think i can do it? I can get some kind of H-Field or whatever out of the FEMM simulation (any ideas appreciated!). But instead of using the data directly i solve the magnetisation pattern of the Projectile with the Spice solder using a differential timedomain equations system. Its output then must give some kind of Magnetisation or Flux density within the Projectile-Sub-Cell. Given that magnetisation i can look up at which current level of the coil such magnetisation would be present at the current projectile position. With the current level i then can look up the force of the the Projectile-sub-cell. In the end i add all forces together and live a happy life.
This would "solve" the issue of the force missmatch. The current system is however good enough to predict the coil current.. So maybe a hybrid? I have currently not thought about how to the projectile subdivision could model inductance change without excessive FEM computation.
So since WaveRider joined and has direct experience with such kind of computation.... maybe we can get something to work? Cant do it on my own
This site is powered by e107, which is released under the GNU GPL License. All work on this site, except where otherwise noted, is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. By submitting any information to this site, you agree that anything submitted will be so licensed. Please read our Disclaimer and Policies page for information on your rights and responsibilities regarding this site.