Spring Piston Simulator Project

[MartyMcFly]

Don't know if this helps or not, but there's CFD available in FreeCAD, as well as FEA (called the FEM workbench) and there's a CFDoF workbench.  I've used the FEM workbench, and have been able to get CFDoF to run some examples, including supersonic airflow.  The latter (CFDoF) is a lot harder to me to understand and to get running.  I've yet to get one of my CFDoF models to simulate.

I used to program in Python (and NumPy & SciPy) extensively, to design and run radar simulations, from physics models through signal processing.  Can't say I was a Python expert, but I used the tools to get the job done, for designing automotive radars.  It's great to see some active Python programming!

Thanks Bruce! I’m a FreeCAD user too, just haven’t done any CFD work in it. I think that the FreeCAD implementation is actually based on OpenFoam, but I have no experience with that software. It’s definitely something to look into in the future, especially for the transfer port modeling. For now I’m starting with the basics, I’d like to see how close Python (in the hands of a hobbyist) can get us and still keep it simple to run by anyone.

-Marty

[MartyMcFly]

Clarifying the framework/approach…

Next, we need to put some more substance around the simulation framework. As said before I’d like to start with the basics and incrementally improve the simulation’s depth by adding details of various system dynamics. I also mentioned that this simulation will simultaneously model all the components of the system and show how they interact with each other.  So, let's start by clarifying what we mean by components and what we will need to model.

Oh, but wait! Before we can jump ahead, we should remember that all physics models need to adhere to the basic principle that energy can neither be created nor destroyed. Essentially, we want to ensure that what goes in, MUST come out, (like those burritos from last night 😃). What comes out can be in another form (ex. motion goes in while heat comes out), but we must maintain an energy balance. In our case, we can capture a springer’s main performance characteristics by describing where and how much energy is generated, where it is sunk/dissipated, and where it is transferred.


We can start with the simplest equation:

    1. Input Energy = Output Energy
 
This can be expanded into:

    2. (Spring Energy) + (Gas Energy) = (Pellet Energy) + (Dissipated Heat Energy) + (Friction Energy) + (Recoil Energy)
 
Lasty, we can rearrange the above equation, so we get the Pellet Energy on the left side:

   3. Pellet Energy = (Spring Energy) + (Gas Energy) - (Recoil Energy) – (Dissipated Heat Energy) – (Friction Energy)
 

Moving on…

In equation #2 we see six major system components. These components span several areas (or physical parts) and can be broken down further but for the moment we just want the big picture.  The components all simultaneously affect each other, not only in one instant of time, but also across time. Said differently, the pellet energy at time t is not only dependent on the total energy allocations in the system at time t, but also dependent on the total energy allocations that existed just before time t (i.e., t-1). In essence, the simulation will compute the state of the system at time 0.01, save the output, then use that output as the starting point for computing the change in energy at time 0.02 and so forth. It's sort of like stop motion animation; you make a little change, take a picture, then make another change and take another picture, until you get hungry for burritos again If you remember high school calculus you should recall that this is the idea behind integration.

Lastly, you may have noticed that I'm not going to simulate cocking action. The reason is because this is an event that does not happen during the firing cycle of the gun. In the grand scheme of things cocking is a remote event (in time) and not important in describing the internal ballistics of an airgun when the trigger is pulled. This is not to say that cocking effort is not important, just that it's not essential to the simulation.

Thanks for reading, more to come!
-Marty



 

 

[subscriber]

When the energy that comes out is less than what went in, it needs to be accounted for as inefficiency - at some point anyway.

[MartyMcFly]

When the energy that comes out is less than what went in, it needs to be accounted for as inefficiency - at some point anyway.

Right; said inefficiency will be captured by (Dissipated Heat Energy) + (Friction Energy) + (Recoil Energy). But if and only if, the simulation is properly calibrated, and we identify/model all of the energy sinks.

That said, if the model shows a higher energy output than real-world experiments then the possible explanations are:
1. We messed up modeling the physical laws
2. We didn't accurately measure frictional forces
3. Our dimensional or material property measurements are off
4. The numerical integrator is unstable due to stiffness or some such programming limitation

My expectations are that the frictional force calibrations won't be spot on, but they should be close. Assuming everything else is correct, this will result in a couple of percentage points in difference between the real world and the model. The biggest challenge would be missing or misunderstanding an important phenomenon occurring within. For example, the impact of the transfer port on the viscosity, mass flow, pressure or heat dissipation is a big question.

-Marty

[subscriber]

Jolly good!

[mpbby]

I am not capable of technical thinking as you do.   So, maybe this is a kind of off topic post, and you judge if it should be considered.   

Since 2013, when, power-hungry, I bought a Diana 350 T06 .22, I am facing the challenging learning curve of springers in general.  Until I have learned to do a simple scope test about ‘still  holding zero?’, scopes were always a nightmare to the troubleshooting detective.

Well, scopes apart, no matter the springer, I ended thinking we are always dealing with an equation to minimize – inconsistency; where each factor brings its own contribution.

As I understand, for a given springer, when you squeeze the trigger the piston start to move and, at some point, the pellet start to move.  We have a smaller recoil from the very beginning, and the ‘big’ recoil at the ending of the piston curse. 

So, I think that some skilled person analyzing the barrel path after squeezing the trigger would be useful to all springers shooters.

The idea would be to attach a laser device to the barrel of any springer and do a slow motion recording of the laser dot.  I don’t have a slow motion recording device and the profile to execute it systematically.  The distance to the paper target should be convenient to clearly see/record the laser dot path.  ES and pellet weight should be considered.  Making some math, we could know at what point of the recorded path the pellet went out of the barrel. 

For instance, changing modes of holding, resting, squeezing, would show the modes we need to – consistently “minimize” form and length of the barrel path, in order to choose the combination the shooter has to try to repeat at each round.
 
In the whole context of the springer world, I hope you consider this idea useful.

[MartyMcFly]

Some new code and graphs...

Ok, it's time to start computing things. The below code is an update of the boiler plate code I posted previously. The key changes include filling in some placeholder measurements, most which are not utilized yet. The second, important change is adding logic to simulate a simple spring+mass system. This serves as the first stepping stone and is a demonstration of what happens with a spring if it is not confined inside of an airgun.

The setup is a spring that is immobilized on on side (lets say the left side) and has a piston assembly attached on the right side. The spring is compressed to about half its length and released for 15 milliseconds. As the simulation is run the resulting change in position, velocity and acceleration are gstored and then raphed at the end.

import numpy as np
import matplotlib.pyplot as plt
from scipy.integrate import solve_ivp

class SpringAirgunSimulation:
    def __init__(self):

        # --- Mass measurements ---
        self.spring_mass         = 0.1050  # kg TX200 Mk3 FAC spring
        self.piston_mass         = 0.2215  # kg
        self.piston_weights_mass = 0.0231  # kg

        # Effective piston assembly mass: 1/3 of spring + piston + weights
        self.pistonAssembly_mass = (1/3) * self.spring_mass + self.piston_mass + self.piston_weights_mass

        self.pellet_mass = 5.469028e-4  # kg
        self.rifle_mass = 0             # kg - needs to be measured

        # --- Geometry & Dimensions ---
        self.spring_length = 0.2250     # m
        self.spring_preload = 0.0025    # m - possibly more, needs to be measured
        self.spring_cocking = 0.0960    # m - needs to be verified

        # Total spring deflection
        self.spring_deflection = self.spring_cocking + self.spring_preload

        self.pellet_caliber = 0.0045  # m
        self.pellet_head_area = np.pi*(self.pellet_caliber/2)**2

        self.piston_diameter = 0.025    # m
        self.piston_radius   = self.piston_diameter / 2 # m
        self.piston_head_area = np.pi * self.piston_radius**2 # m^2

        # Initial "chamber" length set to cocking distance
        self.chamber_length = self.spring_cocking
        self.chamber_volume = np.pi * self.piston_radius**2 * self.chamber_length

        self.transferPort_diameter = 0.0036 # m - possibly as large as 3.75mm
        self.transferPort_length = 0.00987  # m - possibly smaller at 9.8mm
        self.barrel_length = 0.335  # m

        # --- Physical constants & properties ---
        self.spring_k = 77.2e3         # N/m - Assumed the spring is made of Chrome
        self.ambient_pressure = 101325 # Pa
        self.ambient_temp = 293        # K
        self.gamma  = 1.4              # Heat index
        self.R = 287.05                # J/(kg·K)
        self.gravity = 9.801           # m/s^2

    # ----------------------------------------------------------------------
    #  Spring Force Model
    # ----------------------------------------------------------------------
    def SpringForce(self, spring_x):
        """
        Computes the spring force based on Hooke's Law.
        Args:
            spring_x (float): Current spring displacement from equilibrium.
        Returns:
            float: Spring force in Newtons.
        """
        return self.spring_k * (self.spring_deflection - spring_x)
   
    # --- Friction Models ---
    def BoreFriction(self, pellet_x):
        return
    def PistonFriction(self, piston_x):
        return
    def PelletDeformation(self, pellet_x):
        return
   

    # ----------------------------------------------------------------------
    #  ODE System - 2nd order equations
    # ----------------------------------------------------------------------
    def system_equations(self, t, y):
        """
        Defines the dynamics of the spring-mass (piston + spring) system by computing how the
        system's displacement and velocity change over time (these are the time derivatives of x and v).
        Args:
            t (float): current time
            y (list): y[0] is the current spring displacement, y[1] is the current spring velocity
        Returns:
            list: Two elements, the first is the spring velocity (dx/dt = velocity),
            the second is the spring acceleration (dv/dt = acceleration). Both are the time derivatives of x and v,
            in other words how fast x and v are changing.
        Notes:
            The solve_ivp solver internally keeps track of x(t) and v(t) at every time step.
            When it integrates the system_equations function it stores the results in solution.t and solution.y
            solution.t stores the time steps of the integration.
            solution.y has two elements, y[0], which stores the spring displacements 'x', and y[1],
            which stores the velocity, each is stored at some time t
            The solver needs acceleration information to compute how the velocity changes over time, so it can
            compute the next v it will pass as y[1] in the next iteration of the integration.
        """
        spring_x, spring_v = y
        F = self.SpringForce(spring_x)
        dvdt = F / self.pistonAssembly_mass
        # Note: dvdt is not stored in the solution, but it is easily recomputed if we know x and v.
        return [spring_v, dvdt]

    # ----------------------------------------------------------------------
    #  Simulation block
    # ----------------------------------------------------------------------
    def simulate(self, time_span, time_steps):
        t_eval = np.linspace(time_span[0], time_span[1], time_steps)
        sol = solve_ivp(fun=self.system_equations,
                        t_span=time_span,
                        y0=[0.0, 0.0],  # Initial displacement and velocity
                        t_eval=t_eval,
                        method='RK45')
        return sol


    # ----------------------------------------------------------------------
    #  Graphing simulation data
    # ----------------------------------------------------------------------
    def plot_results(self, solution):
        t = solution.t * 1000  # Convert time to milliseconds
        x = solution.y[0] # Extract the spring positions
        v = solution.y[1] # Extract the pistonAssembly velocity
   
        # Compute spring energy and acceleration
        spring_energy = 0.5 * self.spring_k * (self.spring_deflection - x)**2
        piston_acceleration = self.SpringForce(x) / self.pistonAssembly_mass
   
        plt.figure(figsize=(10, 8 ))
   
        # Energy plot
        plt.subplot(3, 1, 1)
        plt.plot(t, spring_energy)
        plt.ylabel('Energy (J)')
        plt.title('Spring Energy')
        plt.grid(True)
   
        # Velocity plot
        plt.subplot(3, 1, 2)
        plt.plot(t, v)
        plt.ylabel('Velocity (m/s)')
        plt.title('Piston Velocity')
        plt.grid(True)
   
        # Acceleration plot
        plt.subplot(3, 1, 3)
        plt.plot(t, piston_acceleration)
        plt.xlabel('Time (ms)')
        plt.ylabel('Acceleration (m/s²)')
        plt.title('Piston Acceleration')
        plt.grid(True)
   
        plt.tight_layout()
        plt.show()
   
   
if __name__ == "__main__":
    model = SpringAirgunSimulation()
    solution = model.simulate(time_span=(0, 0.015), time_steps=15000)
    model.plot_results(solution)

[MartyMcFly]

You will note in the three graphs that the spring energy oscillates over time. It goes from more than 300 Joules to zero and back up. Never stopping. Shouldn't it decrease gradually and stop at zero? A similar thing happens in the graphs for velocity and acceleration, they all oscillate back and forth.

Although this is not exactly what happens inside of a springer, it is correct for a spring whose right side is not confined or limited to a certain travel distance, and which does not experience friction nor an opposing force (like compressed air pushing back). In essence there is nothing in this simple simulation to slow and dissipate the energy of the spring, so it boings (oscillates) back and forth forever (see Newtons laws for an explanation). We will fix this in the near future, but the first basic step is done. We've setup a simple spring, which will provide the power for our simulated airgun.

See you at the next post!
-Marty

[MartyMcFly]

mpbby, a few years back I heard of a device that attaches to a rifle and measures the vibration and positional changes of the gun itself. The device recorded this data and was meant to help people improve their shooting form. Unfortunately, I think these types of solutions have a small market vs. the price it costs to create theme. Doing the laser setup that you suggested is beyond my technical abilities, but it sounds doable and would be a cool thing to have.

-Marty

[mikeyb]

You will note in the three graphs that the spring energy oscillates over time. It goes from more than 300 Joules to zero and back up. Never stopping. Shouldn't it decrease gradually and stop at zero? A similar thing happens in the graphs for velocity and acceleration, they all oscillate back and forth.

Although this is not exactly what happens inside of a springer, it is correct for a spring whose right side is not confined or limited to a certain travel distance, and which does not experience friction nor an opposing force (like compressed air pushing back). In essence there is nothing in this simple simulation to slow and dissipate the energy of the spring, so it boings (oscillates) back and forth forever (see Newtons laws for an explanation). We will fix this in the near future, but the first basic step is done. We've setup a simple spring, which will provide the power for our simulated airgun.

See you at the next post!
-Marty

Your model is currently an undamped https://en.wikipedia.org/wiki/Damping oscillating system with reasonable "ballpark" values. A good start. As stated you need to add some losses due to friction and drag.
FYI that spreadsheet sim looks pretty close to the numbers I get. Piston velocity going negative IS a small bounce off the compressed air. I think this happens frequently but is NOT a big problem to solve.

Question...

Pellet Energy = (Spring Energy) + (Gas Energy) - (Recoil Energy) – (Dissipated Heat Energy) – (Friction Energy)

I don't understand the +(Gas Energy) term? Can you explain where it comes from?


Spring Energy (J)

is the total and only system energy at the start T="0" of the shot event.

The rifle converts the stored potential energy in the spring to kinetic energy in the piston-mass. The piston kinetic energy is converted back to potential energy in the compressed air (another lossy spring until pellet exits the muzzle). The potential energy stored in the compressed air is converted back to the kinetic energy of the pellet.

There will be losses from:

friction/drag = pellet, piston, spring (these are significant and cannot be ignored)
acoustic = sound, vibrations (likely small enough to be ignored at least during the initial "debug" of your simulation)
recoil = rifle motion (just remember that "work = force * distance" so if the rifle doesn't move there is no "work" done.)
heat = adiabatic heating of the compressed air (Nice thing about "springers" is that the event duration is short so much of the adiabatic heat in the quickly compressed air is recaptured as the air expands & cools behind the pellet. SOME heat is lost to the rifle parts and simulating that will be fun. I predict that percentage energy lost will be small and there will be no practical way to capture it. Suggest you ignore it during initial sim setup.)

Pellet Energy (J) = Spring Energy (J) - All_Significant_Combined_Losses (J)


Springers are a type of simple (yet not so simple) heat engine. Efficiency of ~30%-35% of the spring energy transferred to the pellet is where many springers work today. I doubt that can be significantly improved without making the "elegantly simple" springer engine so complicated it becomes impractical... too difficult and/or expensive to manufacture. I'd be delighted to be proven wrong.

I ran many simulations like this during the 1980s to model electrical, mechanical, and electro-mechanical systems. When properly "set-up" the results can be VERY close to actual measured performance. The work I did was NOT cutting edge in theory OR in computational power. Anyone in the airgun industry would have had access to BETTER models and computational resources and I'd be surprised if they weren't using computer simulations/modeling to improve springer performance by the 1990's.

I already went down this rabbit hole (springer simulation) a few years ago. Learned what I wanted to know and archived my files. May dig up the results to compare with yours when you get closer to a working model.

mpbby - Regarding the idea about characterizing rifle/barrel oscillations to attain better accuracy I think this could be simulated but the effort would be high and the results only good for ONE specific rifle. We all know how springer rifles can be pellet-picky with even the SAME MODELS preferring different pellets. IMO this means that rifle/barrel oscillations are also likely to vary from rifle to rifle (manufacturing variations) so simulating the event for one rifle would not really help predict barrel whip.

I'd personally like to see VERY HIGH SPEED x-ray video of a springer shot cycle including barrel harmonics. I think that would clear up a lot of the myths about how springers actually work. Something in the 10000-100000 frames-per-second range. Anything slower is pretty much useless.

Simulation exercises like this help people understand how & why a springer does what it does. For that reason alone the effort is worthwhile IMO.
Your results may not be what you currently expect. I suggest you "enjoy the journey":-)

[MartyMcFly]

mikeyb, glad you joined the conversation! You're another regular that I hoped would add to the topic. Just a few more regulars and we'll be able to fill a table at Olive Garden Now, on to some of your comments/questions.

Your model is currently an undamped https://en.wikipedia.org/wiki/Damping oscillating system with reasonable "ballpark" values. A good start. As stated you need to add some losses due to friction and drag.
FYI that spreadsheet sim looks pretty close to the numbers I get. Piston velocity going negative IS a small bounce off the compressed air. I think this happens frequently but is NOT a big problem to solve.

Yes, the spring system is undampened. I wanted to ensure that I'm getting the classical sign-wave of spring oscillation before doing anything else. I also looked at the spreadsheet, but I can't decipher all of the inline 'if' formulas in it. Thats the bad part about excel, it's hard to debug and understand the formulas when they get long and complex. This is not to say that it can't be used to solve this problem. Just that, it's not very elegant and harder to get an understanding of how the physics matches with the formulas/code. Regarding piston bounce, I wanted to show that it's not only a function of being pushed back by the compressed air, but also a function of the spring extending past its natural length. This won't be the case once we put a limit on the extension length but it's easy to forget and its does occur if the spring-piston assembly has any room to move in the uncocked position. Furthermore, I think there are two types of piston bounce, the first is when the piston is pushed back by air before it hits the end of the compression chamber and the other is when it makes contact (slams). In the second case the bounce is determined by the piston seal's thickness and its Mohs/Rockwell scale. I suspect the bounce is less in the second case, but we don't know by how much.   

I don't understand the +(Gas Energy) term? Can you explain where it comes from?

I was trying to show how the system balance looks like during the shot cycle. During the simulation a portion of the energy will be stored in the Gas and another portion of this energy will also be transferred from the Gas to the back of the pellet. To be clear, when the simulation starts the energy of the Gas will essentially be zero due to ambient atmosphere and zero again at the end of the shot cycle since the volume will be zero.

I appreciate the reminder about the energy losses. The plan for this project is to go from idealized basics to something closer to real life. Therefore, I intend to add pieces as I go along and fine tune the realism. For example, in the beginning there won't be any heat loss but it is my intention to add it via dissipation into the chamber walls and maybe even the pellet and barrel. It might be small, but I want to know exactly what proportion is wasted. I don't think this is the case but imagine if we find that 15% of energy disappears into friction and conduction. Lets say that out of this its 5% into conduction and 10% into friction. That gives us specific areas to think about improving. Hobbyists could polish the barrel, shorten it, or lube their pellets. But manufacturers (assuming costs are low), could use a different material for the comp chamber and barrel. Field Target competitors could figure out what is the ideal temperature for their rifles, etc, etc, etc.

I'd personally like to see VERY HIGH SPEED x-ray video of a springer shot cycle including barrel harmonics. I think that would clear up a lot of the myths about how springers actually work. Something in the 10000-100000 frames-per-second range. Anything slower is pretty much useless.

I'd love to see this myself. A few years ago I even contemplated recreating the compression chamber of an air rifle in plexiglass/acrylic. Filming the action through the plexiglass in slow motion would not only confirm the timing of the piston dynamics but also allow for temperature extrapolation.

Anyways, sorry for being so long winded. I know this is basic stuff to you! Nevertheless, I appreciate your input and for taking the time visit this thread. I hope to take this project much further and build it on more concrete concepts than my TP Madness thread

-Marty


 

[MartyMcFly]

Getting the friction goin' on...

In the next update to the model I've added a friction function for the piston seal. This is a very simple friction model that will serve to show how the spring behaves when it is dampened. Also, I'm not going to post the full code because it is starting to get long, but I will attach it as a file for anyone that wants to look at it. In the code I'm subtracting the force of the friction from the force of the spring, resulting in a net force.

Please note that I ran the simulation for a longer period, and I exaggerated the scale of the friction force just for demo purposes. It will be modified later to match the piston's actual friction more closely. You should now see how the oscillations die down as the spring's energy is dissipated over time through friction.

-Marty

[mpbby]

mpbby, a few years back I heard of a device that attaches to a rifle and measures the vibration and positional changes of the gun itself. The device recorded this data and was meant to help people improve their shooting form. Unfortunately, I think these types of solutions have a small market vs. the price it costs to create theme. Doing the laser setup that you suggested is beyond my technical abilities, but it sounds doable and would be a cool thing to have.

-Marty

Thank you for answering Marty, you are a gentleman.

[mikeyb]

You have a single spring-mass model working with some damping. Excellent.

I don't want to change your path with specific coding details because I'm hoping your model and results will be consistent with what I've seen. I do have some suggestions on how to proceed through your model to confirm it is working in stages. If you try to add too much function in at one time it "may" be difficult to find small errors or incorrect-assumptions. Been there, done that!

Just some suggestions:

Next add compressible air volume which should behave like a SECOND NON-LINEAR SPRING in front of the piston.

- Include volume of transfer port so that PEAK pressure (ignoring adiabatic heating for now) at piston contact can be confirmed by simple ideal gas volume calculation.
- Set boundry conditions for piston travel... it can't go through the end of the compression tube!
- PRETEND pellet is blocking the bore volume and CANNOT MOVE.

Now you should have a coupled two-spring single-mass model that will oscillate and decay depending on the piston friction value you choose.

At this stage you can check if the time/velocity/pressure numbers generated are consistent with reality.



After that you can allow the pellet to move down the bore and "connect" that expanding-volume-mass-acceleration back into the action of the piston.



Simulating pellet "release" timing is a tricky monkey since in real springers the pellet will "STICK" at the breech until pressure reaches some threshold value. This can be modeled as an IF/THEN condition, a high static friction transitioning to a low sliding friction, or a combination of the two.

Best wishes :-)




Question for mods (and sorry to Marty)...
Should this discussion be moved from here

GTA »
All Springer/NP/PCP Air Gun Discussion General »
"Bob and Lloyds Workshop" (Moderators: Rocker1, ezman604, amb5500c)

to maybe here??

GTA »
All Springer/NP/PCP Air Gun Discussion General »
Machine Shop Talk & AG Parts Machining »
Engineering- Research & Development (Moderators: Rocker1, Wayne52)

[MartyMcFly]

Thanks for the advice, Mike. I've gotten a bit ahead of what I've posted so far. Unfortunately, the code needs a lot of cleaning up and changes to make it more object oriented. That said, I've got simple gas compression dynamics incorporated and I have the pellet movement modelled too. Right now, the TP is considered part of the compression chamber, so that will eventually need to be separated out with boundaries and mass flows etc. (Probably the hardest part of this project...).

I have experimented with two ways of setting boundary conditions for piston travel. The first is checking when the piston is about to extend past the compression chamber (i.e. deflection length - preload) and then setting the spring velocity to zero. However, this doesn't seem like a clean solution as it causes problems with the solver/integration. The second solution I'm experimenting with is adding event handling to the solver. When the wall is hit it should save the system state, reset some of the vectors and then restart the integration for the bounce portion of the movement (assuming there is enough energy for bounce).

Regarding pellet sticking, at the moment I have a simple IF/ELSE condition where it won't let the pellet start moving until a certain amount of force is built-up. Again, this is not the most elegant solution because it causes integration errors, but some of it can be overcome by using a solver that can deal better with stiff problems. Eventually, I'd like to make this pellet friction model less linear and more dependent on velocity and pressure. No recoil dynamics have been attempted yet.

The figures I'm getting are plausible, between 850 and 1000 fps, depending on the spring and pellet variables I set. But I have not tested it vigorously against my TX200 because I still need to measure the exact pre-load and verify the stroke length when cocked. Getting the measurements on actual stroke length is a bit tricky because the rifle needs to be cocked while the stock is off.

I was aiming to clean the code up and continue the step-by-step posts, rather than just posting the spaghetti code I have right now. Anyways, thanks for your input, it helps me verify that I'm going in the right direction.

PS. Attached is some sample output. I don't trust the figures yet, but the shapes of the curves and the scales look plausible.


-Marty

[MartyMcFly]

Just an update for anyone still interested...

The latest iteration of the code is looking better and the output looks very encouraging. I took apart a TX200 and got some better measurements of stroke length and preload. While I was at it, I popped in a softer ARH spring and replaced the metal guide with a Delrin one. That said, this required some new measurements of the spring, which I've updated in the code. I also took multiple chrony measurements of three JSB .177 pellets (i.e., 7.97gr, 8.44gr and 10.3gr) to have as a good range of comparison points.

The model now incorporates the following frictions:

• Piston Seal Friction - both on forward and reverse stroke, however it is only linear. Hope to update it to be dependent on velocity and direction.
• Pellet Elastic Deformation
• Skirt Expansion Friction - dependent on how much of the skirt comes into contact with the barrel
• Rifling Friction - including the lands and the spin on the pellet
• Pellet sticking in breech - linear constant force that needs to be overcome before the pellet moves.

The simulation does very well up to the point that the pellet exits the barrel. I've only relied on friction numbers from various papers and the pellet mass given on the tins, yet the "ball-park" figures look really good. Maybe I got lucky!

Actual vs. Simulated
876 vs 883 (7.87 gr) = +0.80% difference
848 vs 841 (8.44 gr) =  -0.83% difference
751 vs 723 (10.3 gr) = -3.73% difference

The biggest difference is for the heavy pellet. I assume that it has to do with the stiction friction or skirt deformation. Unfortunately, there are many variables to go through and I haven't even touched simulating the transfer of air between the compression chamber and TP.

Now for the parts that aren't working so well...
If I let the sim run past the point of the first piston bounce the piston position given by the integrator gets messed up and shows the piston going through the spring extension limit. This is because the integration function has adaptive time stepping, which does not always capture the exact moment of max spring extensions. I'm not sure how to deal with this yet, but I'm working on some potential solutions.

Also, I noticed that lowering the adiabatic index slightly can actually yield better performance. It's a bit counterintuitive that heat dissipation would cause better performance, so I have to do more research on the mechanics of this phenomena. It could be due to velocity and pressure impulse changes caused by lower heat during critical moments of the piston stroke. This has got me very curious!

More work to be done for sure!

-Marty

 

[MartyMcFly]

What the frrrrriction is going on?

So, I've been playing around with the code as I try to make it more readable and organized. While doing that I got this idea to selectively turn-off the friction logic, just so I know what impact frictions are having on the velocity of the pellet. This will make isolation of each friction component easier in the future, especially when I get friction measurements off my TX200 as opposed to using figures that someone else came up with. Anyways, the impact was BIG!

Based on an 8.44 gr pellet, turning off all frictions resulted in a velocity increase from 848 fps to 1,177 fps. I don't want to make permanent/concrete statements on which friction component is causing most of this because I'm not using my own friction coefficients, nevertheless that's nearly a 39% loss of power due to friction.

Does this mean that we can increase power or efficiency by that much? Nope, I doubt that very much even if we made the gun out of Teflon. But it sure puts things into perspective. Furthermore, at this juncture I don't know if this is "real world" accurate. I say this because I didn't come up with these friction models from scratch and there is a possibility that some of these friction plugs, where backed out to make the academic papers better match up with experimental data. In other words, it could be that the numbers only match-up because the friction coefficients mask the fact that the physics modelled (like in the transfer port) is not accurate.

-Marty

PS. Just to be clear, I don't think Dr. Tavella over-optimized his friction models, just that my code has taken the liberty of using coefficients from all over the place and I have a little bit of doubt of how accurate those coefficients and assumptions are.

[subscriber]

I think that piston seal friction is very complex, because the higher the air pressure during compression, the more the synthetic seal lip is actuated outwards to minimize blowby.  So, just pushing the piston forwards at low speed without increasing air pressure probably is not representative.

Steel piston rings are also activated by air pressure pushing them out, but I suspect the coefficient of friction is lower and more constant.  Certainly, the contact are between rings and cylinder are probably more constant than a seal lip, where the contact patch elongates at higher air pressure to produce more friction.

A Teflon seal lip, or coating may be the answer.  Certainly, a Teflon based grease on the seal lip and compression tube bore should help, regardless of piston seal type.

I think that pellet friction is less significant, because while it might start high, it probably drops significantly after an inch or two of travel down the barrel; if not sooner.  The friction and holding force of the pellet in the breech cone (due to cone to cone interference) may be high, but acts over a very short travel; and energy is force x distance.  The short distance aspect suggests not very much (negative) energy transfer in the breech cone.

Reducing the holding force by using a shallower breech cone to reduce the above loss would be a mistake.  The holding force is what enables full air pressure to be reached before the pellet breaks free.  It is like holding a jet aircraft against the brakes as the engines spool up on a short runway.  Allowing the aircraft to move before the engines have developed full thrust "uses up" runway length, and is contraindicated.

[MartyMcFly]

I think that piston seal friction is very complex, because the higher the air pressure during compression, the more the synthetic seal lip is actuated outwards to minimize blowby.  So, just pushing the piston forwards at low speed without increasing air pressure probably is not representative.

I'm totally in agreement with you on this. I'm working on converting the piston seal friction to be non-static and non-linear. First, I think there is some stiction just to get the piston going, second as the velocity and thus pressure increases the lip flares which initially increases the friction quickly, but it reaches some apex. Next when a piston bounce occurs the friction force in the opposite direction is smaller. Likely this will require three conditional statements and a capped exponential function.

I think that pellet friction is less significant, because while it might start high, it probably drops significantly after an inch or two of travel down the barrel; if not sooner.  The friction and holding force of the pellet in the breech cone (due to cone to cone interference) may be high, but acts over a very short travel; and energy is force x distance.  The short distance aspect suggests not very much (negative) energy transfer in the breech cone.

Regarding the pellet friction - To my surprise the sim is showing the opposite, pellet deformation is the biggest energy sink. On page 19 of Tavella's paper, he assumes that the pellet deformation friction is constant, which I assumed as well for initial simplicity. As you say this may not be a correct assumption, especially given that he got this figure from measuring the push required to get the pellet down the barrel and I doubt he was able to vary the velocity as he was making this measurement. BUT in its totality, as part of the entire simulation, this assumption is holding or offsetting something else.

-Marty

[MartyMcFly]

Coefficients are important...

In the previous post where I compared the simulation results vs. actual, I mentioned that the biggest error was occurring for the heavy 10.3gr pellet. Now I know why!

When I ran the previous simulations, I neglected to update the skirt friction coefficients. I simply used the same value for all three pellet types. Below are the corrected figures, which look even better:

Actual vs. Correct Sim
876 vs 870 (7.87 gr) = -0.68% difference
848 vs 841 (8.44 gr) = -0.83% difference
751 vs 741 (10.3 gr) = -1.33% difference

Note that using Tavella's friction coefficients shrank the error for the heavy pellet from -3.71% undershoot to only -1.33%. It also shrank the error for the light pellet. This is assuming an adiabatic index of 1.35, so allowing some heat loss.

-Marty