SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
#172112
Tall order to drill a rod that long in a straight line.

However, I did just order some Taulman Filament. Both the nylon and the translucent one. I think they're both supposed to be incredibly durable. The translucent one may be ideal for an airsoft chamber.
#172115
StaticDet5 wrote:Tall order to drill a rod that long in a straight line.
Perhaps, though it wouldn't be uncommon in industrial works. Then again you could cast the plastic around a "precision rod". Extract the rod when cool, perhaps hone the barrel like you would a car's cylinder.
StaticDet5 wrote:However, I did just order some Taulman Filament. Both the nylon and the translucent one. I think they're both supposed to be incredibly durable. The translucent one may be ideal for an airsoft chamber.
Now that is interesting. One of the uses I have for a 3D printer is to continue my quest for a truely accurate AS pistol. To that end I did some preliminary design work on a small solenoid-type valve to replace the scheme commonly used in CO2 NBB designs. My valve would have to be assembled into the magazine and there's no good way to do that short of making my own custom magazine. It might become easier if some of the pressure vessel could be printed.

Now thinking about it ... I have a CO2 mag that's all plastic except for the inner valve ... so there's no reason it can't be done ... with the correct plastic.
#172116
There was a discussion about this somewhere. They were talking about 3D printing components for a water-cooling rig and hit some really important parts.
For pressure, 3D printers suck. The "laminate" nature of the print makes the whole body subject to leaks and failures. You might be able to get around it by solvent curing your print, but at the heart of the matter, you're going to have micro-channel issues.

All of that being said, make the part and try it out. If it fails, you're out $20 at most.
By ksw9293
#172118
Mee_n_Mac wrote: Why not a clear Lucite (or like) tube, drilled out to a precision diameter ? Now you can look through the barrel and build feed detection and a chronograph into it ? It's not like the barrel has to handle the temps and pressures of a real firearm.
No, but metal barrels are stiffer and less prone to flex under the pounding they take from the gearbox. There's also the friction component to consider: as the BB travels down the barrel, it's got top spin on it from the hop-up. The BBs actually "skip" down the smooth bore of the barrel. The less friction you have at these points of contact, the less energy you lose. Plastics, unless it was Teflon or similar (which would be too soft, I think) would impart too much friction. Chrome plated steel seems to be the best and folks who are building accurate soft air guns use slightly overbore barrels. My understanding of current theory is that tight bore barrels, while providing a better "seal" also make the BB rattle down the barrel more often than a larger bore. Each contact robs the BB of some spin and energy. Completely contrary to rifled barrel design where you want constant contact with the lands to spin up the round as it travels down the bore.

This is veering off topic a little but I suppose that one does have to look at the entire system...
#172129
ksw9293 wrote:
Mee_n_Mac wrote: This is veering off topic a little but I suppose that one does have to look at the entire system...
Agreed ... sry for the OT excursion. In any case it's interesting to see the paths you took, so similar to Static's.

Well done on the "final" product !
By ksw9293
#172133
I've put up a short intro video on YouTube: http://youtu.be/LD5dTjj7Lyc

In the video I run through a simulated 50-round mag on 4-round burst. You'll note that it takes me 13 trigger pulls to get to "empty". 50/4 = 12.5 (the last burst cuts off early as we reach 0 on the mag counter). Video quality ain't great but it'll do to start.

In the video you'll see the counters menu...two of them are the same. They represent the number of rounds that have gone through the gun since I last flashed the code onto the Arduino.
#172142
Nice. So what do you think is left to do ? Static had the idea of "intelligent parking" (my terms, I forget his) wherein the gearbox would be stopped just ready to shoot, spring compressed, the slightest trigger action initiates the next shot. Alternately when the next shot is not imminent (or perhaps on command) the gearbox winds to release the spring ... so as to save wear and tear.

I've forgotten any other ideas that might be possible w/MCU control.
By ksw9293
#172143
You're talking about "pre-cocking" and that's one of the things I need to look at. I mentioned trigger response in semi is not as nice as I'd like right now. The CPU is updating the display during firing and that takes some time away from the polled main program loop. This can cause a delay in the state change that puts the brake on the motor. Ideally, I'd have the state change deterministic, time-wise, so that I could pre-load the gearbox. Shot detection is interrupt-driven on the falling edge (I use INT 2...see the schematic I posted) and the ISR just increments a counter that the main loop references to manage shot count, keeping the CPU in the ISR for the shortest time possible. The main loop has to pick up the change fast enough to apply the brake to the motor within a certain window to assure the gearbox is pre-loaded for the next shot.

Here's the real problem with providing that feature: the S&T gearbox has a "de-cocker" that the operator can use at any time to release the pre-load. So, unless I can keep state on that I can't know for certain where the gearbox is until I detect a BB down the barrel.

As for what's left...a lot of mechanical design and some software tweaks. I mentioned a replacement hop-up with IR detector. Also, the top rail and display housing need some work to make then more robust. Currently that's glued together and is pretty ugly.

Software tweaks include chasing down a display glitch, controlling the display back-light (it's always on right now), tweaking the battery logic and maybe displaying a rounds-per-second value at the end of a burst.
#187883
I'm the OP.
I was using pretty over-spec'd MOSFET's. The only real times I was having issues with blown FET's was when I screwed up. Now, I'm going to be honest, I believe the drive FET had a heatsink on it, and I know it was exposed to an open environment. It wasn't crammed in the buttstock of the P-90 or the AR that I was trying these things out with. That being said, I was going to look at building a thermal cutoff into the system that would recognize thermal issues. I just wasn't convinced that the thermal sensor and system combination could react fast enough to take action preventing a burned MOSFET.

I actually moved again, and now have MORE than enough space to test this out. I need to see if the apparatus made it through the move.
If I can find the box with everything in it, I'll try to get you the part number of the MOSFET I was using. Let me know how you project's going!
#187894
okay, that would be a huge help. I have used the AB Mosfet before with a micro switch ( A Mx Cherry blue switch) and had great performance. Something about having the switch replaced with the arduino ( the 5v/16mhz mini) is making the fets burn up as soon as I try to run them. I have lost a good 6 fets to this problem and I am at loss for how the short is happening. If I had a part list/ schematic to compare against that might help shed light on where I am going wrong. As a small background I am using this in a Nerf Stampede with an 11.1 lipo as the power source. Functionally it is the same as an Airsoft gun ( 11.1 lipo driving a brushed motor with flat gear on a piston). I have even adapted a system similar to the Airsoft systems smart control unit to track the cycling of sector gear. The first goal is to make the system select fire, then working on an ammo counter, and at last adding a RFID system to track each mag's ammo in real time.
#187906
OK, I'm out of town right now, so not able to search through boxes. However, going back over the documentation here, I found the MOSFETs that I was using: IRT 3205. They got hot to the touch (around 65c), with a heatsink bolted on (no sink grease).
There's a fair amount of detail on this page:
https://forum.sparkfun.com/viewtopic.ph ... 8&start=30
There's a picture of my set-up, and Mee-n-Mac wrote out a circuit diagram that should help (it's not what I'm actually using).

The MOSFET's that I was using were blowing at times, due to mechanical issues on the AEG. I really felt that the electronic portion of the build was solid. Once I switched to a "tuned" AEG to test, the heat from the FET was dropping very low. I was planning on using heat measurements of the FET as a diagnostic criteria. As you saw your tuned gun start to heat up, it would indicate that the system was pulling more amps to drive the gear box, indicating that the gearbox was starting to lose tune.

All that being said, my plan the whole time was to have the MOSFET easily replaced, and in a location where I could easily heatsink to the outside world. My plan was to build some kind of metal cover or plate, with some beefy connectors to the power, drain, and trigger legs. The metal cover would sink the heat to the outside world, but screw into the frame somewhere, protecting the circuit. I never got close to the implementation of this.

I think the project is worth doing, I'm just heavily time constrained these days, and I don't have a working AEG.

A ton has changed since I last touched this thing. One thing I would DEFINITELY look at is a higher power (clock speed) processor. I think I was hitting some limits using the basic Arduinos that I was using. I would seriously look at prototyping this with an ugly Due, knowing it was never going to fit in a gun, then sinking money into developing a custom driver board. As it was, the displays that I was using, one of the reasons I wanted them was because I could 'offload' the graphics programming to the display boards, and just let the Arduino drive the gearbox and look for critical sensor inputs. It really wasn't going to be up to doing anything graphically as well as those tasks.

I'll keep looking through my boxes, and I'll keep an eye on here to see how things are going.
By nofxx
#189524
Hey StaticDet5, thanks for all the work... and I'm still on page 28 hehe...
Going to try my shot here: TinyAVR, going to use 20mhz crystal, try to avoid that delay you found on ard on 16mhz.
And the huges fets I can find here in my mess room. Thank you.
PS.: Hey, how about we concentrate this info in a more code/wiki manner? Github ftw?!
#189528
GitHub's a GREAT idea. Back when I was poking at this, I didn't have the depth or experience to understand what GitHub was.
To be honest and upfront: I don't have a current working prototype, or even a Nano that has this code on it. I'm going to work on pulling things together over the next week or so (life got bad over here, but some of it is going to mean I've got some extra time).

One BIG place to look: I didn't fully appreciate how processor intensive float operations and divide operations were. Between that and a 4MHz bump, things should be much easier.
  • 1
  • 28
  • 29
  • 30
  • 31
  • 32