[Spitlebug]

Hrm. This isn't the first time I have witnessed this very thread.

There are about fifteen threads from very recently to way way back in the day with virtually the same concept.

[P0E (Banned)]

Originally Posted by iLovPieNCake

Here are some pictures of what I am thinking.

It's going to be chop/problem less but I get bragging rights for having a boltless spimmy.


That's a really rough diagram.

I.. am... trying ...

Nope. Can't understand any of that.

It shouldn't be too hard though, just need to draw up some thing in CAD, find someone to remove the top inside of the breech and make a channel for your trap door the whole way back, make the door from scratch, then connect the old bolt to.... actually it sounds like a whole bunch of work.

Maybe it's better if you saved up your allowance and purchased a Nova or Epic?

Originally Posted by Spitlebug

I don't discount some stack clipping. It's going to happen, but regarding eye malfunctions they are much more common that people would like to admit. The reason why people don't notice it as much as they would have say seven years or so ago is because of the prevalence of fast loaders. The eye programming is horrendous, but there isn't much one can do in the way of adjustment. Perhaps polling the eyes more regularly and using that as a sensitivity setting much like debounce. Another thing that I think would really help break beam eyes is separating the emitter/receiver and using a fiber channel to create a more directed beam of IR light. This is different than an eye pipe in the idea that eye pipes are meant to "bend" the light and be an easier way to locate the eyes away from the actual breach. I was thinking more along the lines of a using a positive converging lens where the focal point would be close to the receiver. It could be made of plastic and would look similar to a Lite-Brite peg.

First, what do you think causes the eye system to malfunction? I have never seen a break-beam setup fail (hardware). Would there be a benefit to adding additional optics?

Most of the ICs on these markers are using an Atmel or Microchip controller running at least 1million instructions per second. This is plenty fast enough.
No need for a user adjustment (in all honesty there's absolutely no need for a user adjusted debounce either) just good programing.

The logic isn't even that difficult. In my own personal testing I've noticed it all boils down to just a half dozen simple shortcuts the programmers took.

Now if the 'eye' system is using a reflective or pressure sensor well that's failure waiting to happen.

[loldongs]

This will not work well you may fire 2-4 balls in one shot you will have massive inconsistency as the air will be blowing up into the loader.
to much cons

[Spitlebug]

Originally Posted by P0E

First, what do you think causes the eye system to malfunction? I have never seen a break-beam setup fail (hardware). Would there be a benefit to adding additional optics?

Most of the ICs on these markers are using an Atmel or Microchip controller running at least 1million instructions per second. This is plenty fast enough.
No need for a user adjustment (in all honesty there's absolutely no need for a user adjusted debounce either) just good programing.

The logic isn't even that difficult. In my own personal testing I've noticed it all boils down to just a half dozen simple shortcuts the programmers took.

Now if the 'eye' system is using a reflective or pressure sensor well that's failure waiting to happen.

There are several reasons why I think eye systems fail.

In non forced fed loader situations the ball stack will "bounce" some as balls fall down. This leads me to believe that there is one of two possible outcomes here:

1.) Bounce and a clip because the eyes are not polled enough.
2.) Shot queueing without properly checking to see if the eyes are clear.

Paint variances. IIRC, older 5mm eyes didn't have as much of a problem detecting paint that was a little "loose" in the breach. This I think has to do with the probable location of 5mm eyes and also the additional buffer zone in which 5mm offers you over 3mm. This also alleviates roll back/roll forward some.

Programming errors is a big one. I think some programmers have what I would call "equational failures" in which the number of cycles they are trying to use are greater than the number that is availible with the various settings that can be applied.

I also like to think that eyes don't really "track" the paint as it enters the breach and as such timing is relied on a little to heavily for the many different possible combinations of equipment.

I was actually thinking with an RF interface eyes are pretty much a redundancy. The loader would tell the marker when it's done feeding as opposed to the marker trying to figure out when the loader is done feeding.

[P0E (Banned)]

Originally Posted by Spitlebug

There are several reasons why I think eye systems fail.

In non forced fed loader situations the ball stack will "bounce" some as balls fall down. This leads me to believe that there is one of two possible outcomes here:

1.) Bounce and a clip because the eyes are not polled enough.
2.) Shot queueing without properly checking to see if the eyes are clear.

Paint variances. IIRC, older 5mm eyes didn't have as much of a problem detecting paint that was a little "loose" in the breach. This I think has to do with the probable location of 5mm eyes and also the additional buffer zone in which 5mm offers you over 3mm. This also alleviates roll back/roll forward some.

Programming errors is a big one. I think some programmers have what I would call "equational failures" in which the number of cycles they are trying to use are greater than the number that is availible with the various settings that can be applied.

I also like to think that eyes don't really "track" the paint as it enters the breach and as such timing is relied on a little to heavily for the many different possible combinations of equipment.

I was actually thinking with an RF interface eyes are pretty much a redundancy. The loader would tell the marker when it's done feeding as opposed to the marker trying to figure out when the loader is done feeding.

I can't access the site that shall not be mentioned. The latest discussion could use Nicad's testing results:
http://www.network54.com/Forum/9013/...act+bolt+times


Back to the off-topic topic of eyes...
I have actually tested several eye systems for a customer several years ago. It's what brought me back into the sport. I have noticed many problems, but the biggest issue always comes back to programming.
-They program in a higher level language which can waste 8x as many cycles compared to assembly. Even with this waste though, most processors can easily handle the load.
-They use interrupts instead of active polling. This is about 1000x slower than just looping on some polling code. This doesn't cause chops, but it can result in a pulsing ROF when the eyes are on. This pulsing always resulted in a 'barrel break'. The stack is likely getting slammed during the pulse.
-They do not wait 3milliseconds to see if the ball has disappeared due to a bounce. They just see a ball in the breech and fire. That's the big one there.
-They do not verify a ball has disappeared after a shot. (paint on the eyes)
-Etc.

There were some hardware issues we ran into as well. For example some emitters and sensors had a 'viewing angle' that was too large. The mirror like breech was causing false positives chopping paint. A simple section of code similar to how switches should be debounced, cleared that up though.

Good point about the RF.

[Spitlebug]

Originally Posted by P0E

I can't access the site that shall not be mentioned. The latest discussion could use Nicad's testing results:
http://www.network54.com/Forum/9013/...act+bolt+times

Oh, I wonder why that would be. Posted it up for you.

Originally Posted by P0E

Back to the off-topic topic of eyes...
I have actually tested several eye systems for a customer several years ago. It's what brought me back into the sport. I have noticed many problems, but the biggest issue always comes back to programming.
-They program in a higher level language which can waste 8x as many cycles compared to assembly. Even with this waste though, most processors can easily handle the load.
-They use interrupts instead of active polling. This is about 1000x slower than just looping on some polling code. This doesn't cause chops, but it can result in a pulsing ROF when the eyes are on. This pulsing always resulted in a 'barrel break'. The stack is likely getting slammed during the pulse.
-They do not wait 3milliseconds to see if the ball has disappeared due to a bounce. They just see a ball in the breech and fire. That's the big one there.
-They do not verify a ball has disappeared after a shot. (paint on the eyes)
-Etc.

There were some hardware issues we ran into as well. For example some emitters and sensors had a 'viewing angle' that was too large. The mirror like breech was causing false positives chopping paint. A simple section of code similar to how switches should be debounced, cleared that up though.

Good point about the RF.

The point about higher level languages is that if you use a good compiler it should break the code down and make it very efficient. It is true though, there are some inneficiencies with doing things the easy way instead of bit flipping. Can't blame them though, bit flipping sucks ***.

Yes I was going to bring up interrupts instead of a "if" and "while" set of commands. I think the reason for the interrupts is to reduce procedure calls when a loop is required. It's also the lazy man's way of programming where one should really be using a flow chart for procedural calls. At least that how I was taught to program...

Yeah some programs have what is called "AED" or "After Eye Delay". This determines the number of MS to wait after detection before allowing a trigger poll.

[P0E (Banned)]

Originally Posted by Spitlebug

Oh, I wonder why that would be. Posted it up for you.



The point about higher level languages is that if you use a good compiler it should break the code down and make it very efficient. It is true though, there are some inneficiencies with doing things the easy way instead of bit flipping. Can't blame them though, bit flipping sucks ***.

Yes I was going to bring up interrupts instead of a "if" and "while" set of commands. I think the reason for the interrupts is to reduce procedure calls when a loop is required. It's also the lazy man's way of programming where one should really be using a flow chart for procedural calls. At least that how I was taught to program...

Yeah some programs have what is called "AED" or "After Eye Delay". This determines the number of MS to wait after detection before allowing a trigger poll.

Thanks for posting that. The reason is likely due to our stellar IT 'professional'.

High level languages are great at saving time and are absolutely required with today's complex software packages, but they don't even come close to the efficiency of assembly. Since optimizers are only as good as the programer's knowledge of the processor and it's assembly... nearly all programs are very inefficient.

I rewrote the code for a 2009 Tadao EGO8 board just to add some features and improve performance. In the end, the code was 80% smaller, polled the eyes about 500 times faster and used 2% of the power. They could have gone from a $7 processor to a $0.50 processor... and still had more features and better performance.

'Bit flipping' sucks, but you can't argue with the results.

[Spitlebug]

Originally Posted by P0E

Thanks for posting that. The reason is likely due to our stellar IT 'professional'.

High level languages are great at saving time and are absolutely required with today's complex software packages, but they don't even come close to the efficiency of assembly. Since optimizers are only as good as the programer's knowledge of the processor and it's assembly... nearly all programs are very inefficient.

I rewrote the code for a 2009 Tadao EGO8 board just to add some features and improve performance. In the end, the code was 80% smaller, polled the eyes about 500 times faster and used 2% of the power. They could have gone from a $7 processor to a $0.50 processor... and still had more features and better performance.

'Bit flipping' sucks, but you can't argue with the results.

At my work, I am the stellar IT professional... *sigh*

Regardless, you should write code. Have you considered doing a "Open Source" paintball board? I mean PCB schematics that are freely distributable with a distributed code base?

[DasWolfenstein]

Dude I was browsing around here and the BST and look what nation has turned up lmao. https://www.pbnation.com/showthread.php?t=3426853

[Spitlebug]

Yeah that's a classic EPIC. You really want the DV8...

[P0E (Banned)]

Originally Posted by Spitlebug

At my work, I am the stellar IT professional... *sigh*

Regardless, you should write code. Have you considered doing a "Open Source" paintball board? I mean PCB schematics that are freely distributable with a distributed code base?

Maybe I'll do something around the holidays (schematic, gerbers, code, etc). Right now I'm so busy with work I barely have enough time to troll these forums a few times a week.... and that's my only source of entertainment.

[Spitlebug]

Originally Posted by P0E

Maybe I'll do something around the holidays (schematic, gerbers, code, etc). Right now I'm so busy with work I barely have enough time to troll these forums a few times a week.... and that's my only source of entertainment.

Wow, your life sucks.

Seriously, I have very little time as well.

[RidgeH]

Ive had an amazing idea in my head for a very long time for a boltless marker. I've seen the first prototype since it was conceived, and the ones who pursued the design in search of something great. Wish I could have worked with someone on this design before it completely flopped. Ohwell, back in the vault it stays till someday I have the minds on my side to help revolutionize the marker industry.

[Pb^addict]

Originally Posted by iLovPieNCake

I had an idea spring on me one day. Why not make a boltless gun ? Then you would never chop

Originally Posted by iLovPieNCake

I could make a feedneck closer that slides on top of the bolt

HAHAHAH FAIL

[a Beeg Boi]

trial and error...

[GFX260]

Nnnnnnoooooooovvvvvvvvvvvaaaaaaaaa

[minisforme]

idk if its already been said but such a thing exist it was made by alien looked pretty bad but its cool still don't know much about it, and its actually how the company got their name

[Onuris]

Originally Posted by P0E

What about the Splatmaster?

http://www.zdspb.com/media/tech/anim...latmaster1.gif


Unlike the Alien, the EPIC trap door operated at a low enough force to prevent chopping a ball in half.

With any trap door system though, the door is trying to squeeze between two balls. Unfortunately paint comes in a variety of sizes so the door isn't always going to hit perfectly between. Additionally the leading edge is normally thin to minimize how far the balls get pushed back up the stack. These things combined can potentially cause a small crack on the base of the second ball (in the stack) which leads to a 'barrel failure'.


If you're trying to design a boltless gun don't use a trap door like the ICE or Alien or Nova or Splatmaster.... and good luck.

ICE has a nice trap door kit for the Epic that has a variety of trapdoors with varying thicknesses and profiles to match to different size paint. And if you are ambitious enough, you can take one that is slightly oversize and trim it down to be perfect. The trap door is a very good design imho, of the over 400 different markers that I own, my Epics seem to break the least paint of most of them. And they are some of the most accurate markers as well.

One of my DV8s is in the process of being converted to electronic operation. Have a rough working prototype at the shop, but some of the components are outside of the marker. Have to spec parts so everything will fit inside. Will probably have to engineer a new grip frame for it to make it work, and put the battery and board in the front grip.

Also working on a couple of designs that use electronic bolts, air only used to fire the balls. Using a couple of Invert Minis as donors for those projects. Might start a thread on them soon.

[tweeter4]

Originally Posted by Onuris

ICE has a nice trap door kit for the Epic that has a variety of trapdoors with varying thicknesses and profiles to match to different size paint. And if you are ambitious enough, you can take one that is slightly oversize and trim it down to be perfect. The trap door is a very good design imho, of the over 400 different markers that I own, my Epics seem to break the least paint of most of them. And they are some of the most accurate markers as well.

One of my DV8s is in the process of being converted to electronic operation. Have a rough working prototype at the shop, but some of the components are outside of the marker. Have to spec parts so everything will fit inside. Will probably have to engineer a new grip frame for it to make it work, and put the battery and board in the front grip.

Also working on a couple of designs that use electronic bolts, air only used to fire the balls. Using a couple of Invert Minis as donors for those projects. Might start a thread on them soon.

pics or shens

[RabidHobo]

Originally Posted by Spitlebug

The Airstar Nova was the first truly no bolt marker. It has a reciprocal barrel that opened and closed the breach. The EPIC was the second. Also, Jack Rice of Alien did a similar marker that went nowhere and basically was similar to the EPIC but the door operated slightly different.

then a few years later Alien paintball came out with their trap door gun. i dont think it ever went into production though.

[paintballcrazy89]

that drawing that the did was a fail if its going to be a bolt less design then why did u draw and label a bolt?