SpudFiles

Hello All!

After being here for a while I have seen numerous inquisitions regarding 'spring guns', which function via a plunger being pushed forward under the power of a spring, to consequently compress a gas and fire a projectile.


Many of these inquests are usually regarded as pointless though, as the design of such a device is a very complicated matter to those unfamiliar with such models, and very often, it is a large portion regarded as guesswork, or trial and error. Therefore these inquests often lead to dead ends and no progress being made in such matters.
I feel this is quite a shame though, as, as far as cheap, fast, fun, small caliber launchers go, these little launchers can be great fun, and with more people committed to them, forming a larger basis of knowledge, I feel that they could go far!

So, Newtons laws of motion in hand, I decided to use my initiative and create a 'GGDT' like programme to give rough estimates of the factors, and the amount they effect the performance of a launcher, so that people can create and design launchers without as much guesswork as there once was.

So I introduce: Spring Gun Design Tool!
A simple modelling program designed quickly by hand on excel, seeing as I lost my VB software a few weeks ago.
Simply input your design parameters, and have a glance at the two output graphs to see the potential performance of your launcher!

(it models this situation: http://www.arld1.com/pistonpelletdynamics.html )

It is still in it's fledgling state at the moment, so don't attack me for the gargantuan errors in some places, which I know are there, as I designed it one cell at a time.
The programmes assumptions are written around the 'inside the machine tab' there are a ton of things that it does not calculate at the moment, and loads of points for inaccuracies, probably due to me doing it in a hurry.
I will be creating a proper 'how to' page though, explaining where to find all the input values, for confused users on v2.

Any contributions to the design are welcome, (flip me a pm and I'll give you the 'raw' unlocked copy)
I intend to be improving on the design slowly but surely, ironing out the errors and improving the programme to a point where it is worthy of transferring to a 'proper' programme, also I'll be improving this page with updates of the programme, and also with the restrictions of the design, and what it does, or does not consider, at the moment it uses very, very basic bank of about 100-200 handwritten equations.

Any comments are welcome, I haven't explained even a tenth of what there is to tell, so don't be shy in asking.
I do believe this would be the right place for comments and questions, although I'm always open for pm's if you would prefer.

Have Safe Fun!


(Currently Running: SGDT.V.1)

Very interesting, I'm normally one of the springer naysayers but this looks great.

Have you tried to see how it matches up with a real world situation? Does it take the effect of "shock heating" into account? That's usually where the "black art" of springers comes in...

How does it compare? Well at the moment I haven’t done any ‘extensive’ testing of the programme, but I tested it against the factory specs of my air rifle, and it seems to be on par with it, I’ll be getting some stuff to make a proper testing rig in the near future, so more testing is in the pipeline.
I can presume what you mean by ‘shock heating’ is the thermal effects of the sudden compression in the chamber,
At the moment, thermal effects are still a distant prospect for the programme. But as far as I've gathered, it doesn't completely invalidate the outputs

cammyd32 wrote:How does it compare? Well at the moment I haven’t done any ‘extensive’ testing of the programme, but I tested it against the factory specs of my air rifle, and it seems to be on par with it, I’ll be getting some stuff to make a proper testing rig in the near future, so more testing is in the pipeline.

It would be interesting to make a rig with an air spring too... you'd be able to fiddle with the pressure to change the specs over a wide range.

I can presume what you mean by ‘shock heating’ is the thermal effects of the sudden compression in the chamber,
At the moment, thermal effects are still a distant prospect for the programme. But as far as I've gathered, it doesn't completely invalidate the outputs.

If airguns can be made to diesel, the implication is that the air is reaching temperatures in excess of 200°C, which has a significant effect on performance. Looking forward to some real world results

If airguns can be made to diesel, the implication is that the air is reaching temperatures in excess of 200°C, which has a significant effect on performance.

So essentially have a small portion of a diesel engine, inside a launcher?

Well I'll update the thread when the time comes, I like the idea of testing air springs as well actually, might equate the ability to design air springs into v2, given that it wouldn't be that hard to do.
Thanks for the input

Nice work. For the future, I would suggest learning Python or some other portable and free language instead of using Excel. Spreadsheets are okay for small jobs, but when it comes to developing a simulation you should know that debugging and testing a spreadsheet is hard.

Does the calculator take projectile friction into account? A loose fitting pellet definitely starts to move earlier and generates less pressure in the cylinder than a tight fitting one.

For the future, I would suggest learning Python or some other portable and free language instead of using Excel.

Yeah it would be nice to move the programme into something better, eventually I will, but at the moment I am just doing this in my spare time, so learning any kind of programme will take time.

Does the calculator take projectile friction into account? A loose fitting pellet definitely starts to move earlier and generates less pressure in the cylinder than a tight fitting one.

Yup, I think it's listed as 'pellet frictional pressure' on the inputs bar, so essentially, the pressure in the chamber at which the pellet will start moving.
I designed it so you could design a detent into the barrel, which I realized is a common feature in smaller power pellet guns, to up the power a bit.
The 'pellet frictional pressure' is the pressure it requires to overcome the detent, then the 'pellet to barrel friction' is the ordinary barrel friction that is present on the pellet as it is moving.

Hi, I'm new here, but I'm a friend of btrettel. I'm also a mechanical engineer, and, coincidentally, I do a lot of work on homemade spring powered systems like these. While we tend to shoot homemade Nerf darts, the mechanics are nearly identical (main differences in internal ballistics come from air flow, and then the external and impact ballistics are very different).

I'm interested in the work you have done here - as btrettel mentioned to me, it's the first publicly released spring powered simulation. Particularly, I wanted to look through your algorithm and see the order of your approximations.

I suppose that the first thing that I'd like to mention is that I found no errors in your kinetics or kinematics. Functionally, that part of the algorithm is very solid. However, you did make some mistakes in the pressure calculations, and I'll get into that later.

I do want to note that instead of adding an entire new column to get the initial conditions of the step (which are the final conditions of the previous step), you can just use the final conditions of the previous step (old column, but up one row). That would really clean up a lot of the equations, and make it clearer for debugging. (As an example, Column O is the same as Column AH, but shifted by one row.)

I worked out your algorithm from the excel equations. I'm sure you know it, but for everyone else, I'll post it here.
In your initial conditions, you don't have units on "Actual Pressure Calculator". They should be Joules, if you weren't sure.

The issue with your pressure calculations comes in here though. Your calculation is APC = P*V = constant. This is shown when you use APC/(total volume) = pressure of each step. This, however, is an isothermal relationship, which means the air temperature never changes. In reality, the temperature will change (you're not removing any heat to keep it the same, heat can't move away fast enough in such a short time frame), so you should use the adiabatic relationship, P*(V^Gamma)=constant, where Gamma=1.4 for air.


To determine the order of your approximations, I looked at the algorithm method. This was more difficult than usual because you start by using distance steps in the plunger, then convert that to time steps in the pellet.

In step 3, you use the Euler method (aka degenerate multistep) for interval dd. This gives your plunger velocity error of O(dd) (which is pretty bad - first order). Interestingly though, it gives your plunger position no error, and the acceleration's error is a function of the pressure error, which we'll see later.

In step 5 when you calculate dt, you use Euler again, and you use the plunger acceleration and velocity to do it. This is slightly worse than O(dd). This one is an easy fix though. You used dv/da=dt, where the change in velocity and the initial acceleration are approximations, but you could use dt=(change in position)/(average velocity). This reduces error because your position is defined - not an approximation. By using the average velocity instead of the initial velocity, you also reduce the error (this is the difference between Euler method and Multistep method). Step 7 only uses that dt and the pressure, so it has about the same amount of error as dt.

Finally, step 8 is where it gets bad. While you tried to use the average velocity (multistep method), because of the way you calculated the velocity of each step, it's the same equation as d=v*t+.5*a*t^2. And since your dt is O(<dd), dt^2 is O(<dd).* This is Euler of an Euler. (first order approximation of a first order approximation of a second order ODE). If it were multistep of a multistep, your error would be O(dd^2).

What this means: Basically, it means that your muzzle velocity results should be relatively OK, which it sounds like it is. However, it means that the position at which the pellet leaves the barrel is probably off by a good amount.


The accuracy of you program is a function of your step size. So you can either use a better function (like I was talking about with the methods), and/or you can use a smaller step size.

Because you're at O(dd), by using 2000 steps instead of 20, you are about one hundred times more accurate. That said, by using O(dd^2), you'd only need 45 steps to get the same accuracy. In general though, simulations should use lots and lots of steps - way more than 20.

I do hope that you don't take this feedback too harshly. I only mean to try to help the development of your model. I don't think that any of the criticisms of the model fall back on you - as you said, it's a work in progress.

I really like the work that you've done, and am glad that you made it public - I'm certainly not comfortable making most of my work public just yet (if ever). I hope that in the future, your SGDT will be a valuable tool to help designers and to compare against the work of others.

Out of curiosity, why did you choose to use the steps to be a function of plunger position, instead of time? I've never seen that before, but it has some interesting benefits. That's one thing I'm going to look at including in my simulations.

*Edit: Btrettel pointed out to me that O(dd^2) is better than O(dd), and he's right about that, so this point was moot. Euler of an Euler is still less accurate than just an Euler though.

Edit 2: Apparently strike-through isn't supported here. I just made the font small instead.

Thanks for the feedback, I did say that criticisms are welcome, and as of that I've found what you've written very useful in my conceptualization of the next version, so, no criticism taken to heart .

I do want to note that instead of adding an entire new column to get the initial conditions of the step (which are the final conditions of the previous step), you can just use the final conditions of the previous step (old column, but up one row). That would really clean up a lot of the equations, and make it clearer for debugging. (As an example, Column O is the same as Column AH, but shifted by one row.)

First things first I am intending in v2 to plot everything against a distinct time column(along with a better step size), and plot against that, as opposed to plotting vs the plunger travel, this should tidy it up (as I can zigzag my way down methodically), and improve reliability and accuracy in the predictions and assumptions.
The reason I chose otherwise first time round was that when plotting it against a time axis, there was no definitive end point, and any attempt at auto scaling would have sent the programme into an endless loop, making results really screw up.

The issue with your pressure calculations comes in here though. Your calculation is APC = P*V = constant. This is shown when you use APC/(total volume) = pressure of each step. This, however, is an isothermal relationship, which means the air temperature never changes. In reality, the temperature will change (you're not removing any heat to keep it the same, heat can't move away fast enough in such a short time frame), so you should use the adiabatic relationship, P*(V^Gamma)=constant, where Gamma=1.4 for air.

When I wrote the programme I knew that the pressure equation that I had was not ideal. Since I deemed that any thermal effects would have been negligible, if any at all, I chose not to use one that equated thermal effects, as this would have unnecessarily confused matters. In the future it's another thing to add in, but for the moment it's just another number-factorial of columns that I need to write in.

I really like the work that you've done, and am glad that you made it public - I'm certainly not comfortable making most of my work public just yet (if ever). I hope that in the future, your SGDT will be a valuable tool to help designers and to compare against the work of others.

Thanks, well the folks here at spudfiles are a good bunch of people, and my launchers have been born and bred in the knowledge that I've got from here, so I wanted to give something back to the community as a whole, along with any others who would like to design and make spring launchers,

Since I deemed that any thermal effects would have been negligible, if any at all, I chose not to use one that equated thermal effects, as this would have unnecessarily confused matters.

I'm not sure you understand what adiabatic means. Adiabatic means there is no heat gain or loss in the process - by definition the "thermal effects are negligible". By using the isothermal equation, you are assuming that the thermal effects are substantial.

I've attached a graph of the difference between the two scenarios. These are both pressure as functions of the plunger position. The blue line is the isothermal equation, while the red line is the adiabatic equation. There is a very substantial difference. It is, however, a very simple fix (and definitely not one that is unnecessarily confusing).

In column AE, instead of using:

='Input Values'!I$13/(AD8+'Input Values'!I$9+AC8)
Which means "APC/(Volume of plunger tube + Dead space + Volume of Barrel)"

Just use:

='Input Values'$D$30*('Input Values'$I$10/(AD8+'Input Values'!I$9+AC8))^1.4
Which means 'Atmospheric Pressure * (Original Volume/Current Volume)^1.4

Split's right. Isothermal is demonstrably wrong even in simple cases. The higher the compression ratio, the worse the isothermal assumption is. Still, isothermal is okay if you are just getting started, but it should be corrected. I myself wrote an isothermal springer simulation back in late 2008, and by 2010 I had a fairly solid grasp of all the basic physics and was writing simulators just as good (if not better in some regards) as GGDT.

Also, to be clear, the effects of shocks (which include more than potentially heating) are different from adiabatic compression. Adiabatic compression is far simpler to model, involving only the simple change Split detailed above for this simulator. Shocks require at least a 1d CFD model to get right with any reasonable accuracy. As far as I know, DYI, D_Hall, and myself are the only people to consider this. I have not been satisfied with my own simulators that include these physics for various reasons.

For a more complex simulator where the barrel pressure differs from the plunger tube pressure (which is an important effect), you'll need to track the mass flow rate between the two chambers. By doing that correctly you'll also have an adiabatic simulator. GGDT works this way.

'm not sure you understand what adiabatic means. Adiabatic means there is no heat gain or loss in the process - by definition the "thermal effects are negligible". By using the isothermal equation, you are assuming that the thermal effects are substantial.

Well I think I phrased that badly, I think what I meant to say was 'the effects of temperature change within the system would not effect the outcome by a great amount' I think I was getting at, due to the fact that my equation assumes the temperature remains constant, no thermal effects would be equated, and therefore ignored, which at the time I thought was a adiabatic relationship, thanks for correcting me, forgive me if I'm a little rusty it has been quite a while since I have done much mechanics, I'm still a little shoddy at explaining this, so please scream in my general direction if I'm just rephrasing what I said earlier, it makes sense in my head, I promise!...

(and definitely not one that is unnecessarily confusing).

Just to clear this up, (and prove that I'm not a moron) at the time the only two pressure calculations that I could remember are 'the perfect gas law' and the simplistic 'p1v1=p2v2', after toying with the idea of using the perfect gas law, trying to force it into the application that I wanted it for seemed an overly complex operation for a very tired me at 11 o-clock at night.
I will definitely use your operation for pressure for future versions, as the results speak for themselves, but two questions regarding: Your graph, have you tested + recorded (or similar) where an actual pressure reading of the system would be taken at? I wonder how close it would lie to the two lines. Also your equation it's perplexing me what law/scientist/rule/parrot you got it from, I will definitely use it in future but I like to understand where my equations come from, for a multitude of reasons I'm probably sure you, as a mechanical engineer, can guess, hence why I'm not going to bore anyone else with them.

Still, isothermal is okay if you are just getting started, but it should be corrected. I myself wrote an isothermal springer simulation back in late 2008, and by 2010 I had a fairly solid grasp of all the basic physics and was writing simulators just as good (if not better in some regards) as GGDT.

Then why haven't we seen any until now! hahaha, save me the time and effort of making my own only joking, I can appreciate why someone wouldn't want to make their programme public, or alternately, the few reasons why someone would want to make their programme public,

For a more complex simulator where the barrel pressure differs from the plunger tube pressure (which is an important effect), you'll need to track the mass flow rate between the two chambers. By doing that correctly you'll also have an adiabatic simulator. GGDT works this way.

All in due time, I'll also be wanting to calculate a better estimate of frictional forces of both the pellet and the plunger, and also account for things such as efficiency of air flow, efficiency of energy transfer, 'blowby' on the pellet, and various spring related calculations regarding spring twist, and numerous other things. But for the moment I'm content with getting just a 10-20% error on the output velocity, it is only a rough estimate programme at the moment after all.

cammyd32 wrote:Your graph, have you tested + recorded (or similar) where an actual pressure reading of the system would be taken at? I wonder how close it would lie to the two lines. Also your equation it's perplexing me what law/scientist/rule/parrot you got it from, I will definitely use it in future but I like to understand where my equations come from, for a multitude of reasons I'm probably sure you, as a mechanical engineer, can guess, hence why I'm not going to bore anyone else with them.

As I recall Split does have some pressure traces for springers. However, don't expect similarity of a curve to validate your model either way. I think using at least separate barrel and plunger pressures is necessary for reasonable accuracy. As for where to measure... that's a good question. The right answer is probably everywhere inside whatever area you are modeling and taking a volume average. But putting a fast and unobtrusive pressure transducer anywhere in a volume is probably okay for low Mach numbers.

Split uses an adiabatic process relationship. These are derived in any basic thermodynamics book, but if you don't have one then you can follow Wikipedia. (Reversible adiabatic processes are isentropic too, hence the different name here.)

cammyd32 wrote:Then why haven't we seen any until now! hahaha, save me the time and effort of making my own only joking, I can appreciate why someone wouldn't want to make their programme public, or alternately, the few reasons why someone would want to make their programme public,

Actually, several years back I released a simulator that was similar to GGDT called BAGS. That's what I was referring to.

(This code is no longer available because I'm writing a new much better one and GGDT is plenty adequate for most folks.)

cammyd32 wrote:But for the moment I'm content with getting just a 10-20% error on the output velocity, it is only a rough estimate programme at the moment after all.

I'm not sure your error is that small. I suggest comparing your results against experiments whenever possible, as it'll often help you decide what new physics to include.

Unfortunately, I don't think any simulator compares particularly well against experiments. GGDT only gets good fits because people use the valve coefficient as a fudge factor. The valve coefficient you get from your typical bench test will surely differ from what GGDT suggests, especially given that GGDT's basic valve model is from the late 1830s and is known to be inaccurate to those in the valve industry.

I did some experiments with pneumatic guns back in 2010 that I'm going to use to validate my next few models, so hopefully we'll finally have a computer model with less fudge factors in the next year.

Split uses an adiabatic process relationship. These are derived in any basic thermodynamics book, but if you don't have one then you can follow Wikipedia. (Reversible adiabatic processes are isentropic too, hence the different name here.)

Thank you, I did wonder, you see my reference books are limited to a few further mathematics ones that I got for A level, and a few of the 'ship theory' series, hence the very limited understanding about closed pressure systems, and (I wouldn't exactly say simple) thermodynamics.

I'm not sure your error is that small. I suggest comparing your results against experiments whenever possible, as it'll often help you decide what new physics to include.

Will do, I did say earlier that I was intending to do some tests, but what with a lot of work to do it will most likely have to wait until the summer.

Also what could be worth considering is forming a design programme that is made entirely from experimental data, have you ever considered such an idea yourself?
In theory it should yield results which have a very close accuracy, bearing in mind the amount of variables for a spring gun, these results could be as accurate as, if not more accurate than a good design programme.
Also just as a side note, with the velocities that we are talking about, I wouldn't say a 20% error is exactly small, although you are probably right, at the current my programme is quite inaccurate, although as I said earlier, it is a rough estimate

I did some experiments with pneumatic guns back in 2010 that I'm going to use to validate my next few models, so hopefully we'll finally have a computer model with less fudge factors in the next year.

I look forward to seeing it! although it might take some of the novelty away from making my own, that is if it's still worth improving my own,