Basic stamp in a paintball marker!
FireHelix
Posts: 42
Well, I'm fairly new to the basic stamp scene, but I've had great luck finding answers and learning material here in the parallax forums. My curent project involves using a pbasic setup to controll the functions of a paintball marker. At it's base level the program needs to monitor the trigger (lever switch), monitor breech eyes (ir led and reciever) for making sure a paintball is loaded before fireing, and activating the pnumatic solenoid that fires the marker. I'm planning on posting more to this thread as my project progresses.
The structure I'm using just scans for trigger pulls repeatedly till it sees a pull, which it then checks the breech eyes. If it sees no paintball, it returns to checking the trigger, if it does see a ball, it jumps to the solenoid routine.
ok whew... that was a lot of explaining right off the bat. so here's my scenario I need help with. I need to be sure that when the stamp sees a trigger pull that it actually is a valid pull, not just electronic or mechanical bounce. Id like to do this by having the routine make sure the trigger is pulled for atleast 2-3ms before passing TrigPull = 1 back to the main program. Looking around a little I thought RCTIME might be what i need but I'm not entirely sure.
Any suggestions on how to monitor the trigger and make sure it's pulled for a set amount of time before counting it as valid?
The structure I'm using just scans for trigger pulls repeatedly till it sees a pull, which it then checks the breech eyes. If it sees no paintball, it returns to checking the trigger, if it does see a ball, it jumps to the solenoid routine.
ok whew... that was a lot of explaining right off the bat. so here's my scenario I need help with. I need to be sure that when the stamp sees a trigger pull that it actually is a valid pull, not just electronic or mechanical bounce. Id like to do this by having the routine make sure the trigger is pulled for atleast 2-3ms before passing TrigPull = 1 back to the main program. Looking around a little I thought RCTIME might be what i need but I'm not entirely sure.
Any suggestions on how to monitor the trigger and make sure it's pulled for a set amount of time before counting it as valid?
Comments
Trigger:
DO WHILE Trig = 0
LOOP
PAUSE 50
IF Trig = 0 THEN Trigger
rest of code here
This way the trigger has to be held for a shot period. You can adjust the PAUSE length to your liking. Hope this helps.
i make it cycle through the for loop checking the trigger status and if it's still pulled, add 1 to the time counter. if the time counter reaches 3, it checks the eyes. if theres a paintball, it resets the time counter and fires the marker. if no paintball, it keeps checking till it gets to 700 at which point it fires with out checking the eyes (forced fire if the eyes break or get gooed with paint). the for loop goes to 1000 to allow TimeCount to get to 999 at which point it will shut off the eye checking routine and be able to fire "blind" (not written in yet)
comments? criticism? yell at me if i'm going to break something?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
Post Edited (FireHelix) : 8/11/2006 12:26:20 PM GMT
If you are using the basic stamp2 at 2000 lines of code pre second you only execute 20 lines of code in the loop from 0..3 so only 10ms
will pass for your debounce of the switch, that may not be enough time.
Your nested code can be simplified. Try not to nest so many if then constructs. For example your input routine "Triggertest" should be just that, an input routine that sets a flag to the main program loop, the main program loop should execute the solenoid nd eyes routines.
I also fail to see the logic in disabling the eyes and firing after 500ms pass if that is the case what good are the eyes if you simply ignore them after 1/2 second.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think outside the BOX!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
with that being said, here's the code
Comments? Suggestions? stuff i screwed up really bad?
I think at some point I should put some debug strings in there for when I actually try the program out, but before hooking it up to critical parts of my marker.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
1. You are missing a RETURN at the end of - TriggerTest: subroutine
2a. In your SELECT TimeCount routine, you can be more specific with your· CASE statements if you wish to:
EX.
·Select TimeCount
·CASE > 0 and < 5
··blah,blah
·CASE 5 to 256
··blah, blah
2b. In that same routine, you have no CASE ELSE if you intended to put one in.
3. Routine - TriggerStall has no RETURN statement
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
Otherwise reading the code it looks like it can fall through the ENDIF into the subroutine below it.
Try to write IF THEN structures so that when you look at the program flow you do not have to follow the code inside the structure.
The following code is eaiser to follow because you can see the in point and the out point without reguard to what happens inside the if then logic.
This should be a subroutine with a return instead of a goto.
Only one gosub triggerstall is needed as your code calls it from both the IF and ELSE clause.
Your main code jumps to Triggertest with a goto instead of a gosub although it will work because you use "goto start" instead of a return but the Normalshot subroutine has a "goto start" for one of it's exit points and that will crash your program when the stack runs over.
Rewrite the modules to exit at only one point
Remove ALL the goto statements by rewriting the logic flow so that ecah function/subroutine is bullet proof. It does a specific task and returns to the calling program.
GOTO's are Basic's worst command as far as trying to follow program logic flow, try to avoid using goto unless the logic has no other way.
Code rewritten with flow changes
*NOT TESTED i AM AT WORK ON A BREAK so I may have made some mistakes*
I usually try and make changes on a piece by piece basis, testing the change as I go. Make only one change to the code and test it when it is working do the next change or with larg programs you will get confused very quickly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think outside the BOX!
Post Edited (metron9) : 8/11/2006 3:56:30 PM GMT
Thanks again for all the advice and help!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think outside the BOX!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
Without the BasicStamp and eyes another shot through the breech clears the breech on the next shot.
With the BasicStamp you have to wait 1/2 second for it to filre
when you hold the trigger down longer to disable the eyes (at the risk of chopping more paintballs due to the gun being "blind"
Without the BasicStamp it fires without holding the trigger for 1 second
With the BasicStamp you still risk chopping paintballs.
Hmmm I guess the only reason I can come up with to have this on a gun would be if it was in automatic mode
where holding the trigger fires paintballs at one per second or more so you dont chop a bunch of paintballs if it jams?
If it's a single shot gun then I still dont see the need for it as it just inserts a delay that seems unnecessary.
Is jamming of paintballs a problem with most paintball guns?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think outside the BOX!
ok... after that being said you're prolly wondering "well why would you ever want to disable the eyes then?"
the reason for that is just being prepared for the worst. if the eyes happen to get damaged or paint filled or something that causes them to not work right anymore i'd need some way to byepass them quickly and easily (they may break in the middle of a game... and you cant really call "time-out" or anything like that in paintball). with the eyes byepassed i'd still be able to continue the game in progress.
as for automatic modes and such, that's in the plans but not till I get this thing working at a base level first. different paintball leagues allow different firing modes. examples are single-pull single-shot only, ramping (must keep pulling trigger like semi-auto, but the gun adds shots to get up to a certain speed of shots per second), and capped full auto (hold trigger and it fires fully automatic up to the shots-per-second cap)
to your last question, is jamming paintballs a problem with most guns.... yes and no
tournament level paintball markers(guns) can run upwards of $1300. the distinctive qualities of the guns are their accuracy, consistency, and rate of fire.
for referance sake, a millitary M16 fires roughly 12-15 rounds per second... paintball guns can reach upwards of 25-30 shots per second (yes, in semi-automatic mode). trying to load gelatin shelled goo filled balls into a chamber and fire them at that rate can make for a messy time if things arent working properly, hence the need for electronic control. if the gun happens to get goo-ed up, then that hurts both accuracy and consistency, thereby reducing the effectiveness of the gun as a whole. So theres a big potential for jams, but due to electronics, they can be kept to a very minimal level.
hopefully one of these days I'll be able to post up a couple pictures to help explain
for anyone curious... the board thats in my gun right now is made by tadao technologies and after snooping around, it has a PIC12F629 controlling it. mfr's site
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
Post Edited (FireHelix) : 8/16/2006 5:39:35 AM GMT
Most of the e-boards I've seen as upgrades are between $50-$150 so I think using a STAMP will probably not save you any money....what it will do is let you customize how the firing works
I can just imagine how cool it would be to set up a firing sequence that just happens to rock out a drum beat from Matalica for instance...hehe.
My GF plays with my old starter Spyder and routinely rips me apart even though I've got a Dye tournament grade marker now. It's all about your skill, not your gear.
Lance
Just for information's sake, First Strike Paintball is the field / team that I play for. Have a look see and even drop a line in our forums and say hi if you feel like it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
We just play woodsball for fun and stress relief. Our company does a regular outing. You wouldn't believe how much fun it is to shoot the HR manager in the butt
Last game I walked 15 rounds across his back....luckily for him most hit his pod harness. That was with a A-5 set to 20/sec. Next game its with my new DM6 set to 30.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
but... i do have 1 question still. I'm shooting for a 15ms pulse to the solenoid... but the number base for the PULSOUT duration is 2us. maybe ive done my math wrong (read: probably did my math wrong... its 6am and ive been up all night) but would i use a duration value of 7500? 1000us in 1ms? 15000us... divide by 2 because of the 2us base... 7500 right?
if i'm right... then i'm looking at the first code ready for hardware testing!!! WOOHOO!!!!
i dub thee "please please please work!!" also known as beta 1 :-P
*edit: added attachment of current code in case anyone wants to take a look-see
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
Post Edited (FireHelix) : 8/20/2006 11:45:33 AM GMT
Your work arounds so far all assume that the only user-input-device is the trigger, and the only user-output-device is the solenoid valve. Have you considered using LEDs and/or pushbuttons for changing modes and indicating modes? You'll need a reset switch anyway, or a routine to automatically shift back to default mode after 5 minutes or something. Otherwise your marker will be stuck in blind mode. I would think that you could benefit from a button or switch that puts the eye subroutine into a force-succeed mode rather than responding to a long trigger hold. That way, you can flip the switch back at any time.
Also, the way your program works right now, I think it only goes into blind mode if the eye detects nothing for a long time. I can only see that happening if you're out of balls, in which case you wouldn't want to force blind. If the eye fails-possive, then the gun will just fire and fire and fire with nothing present in rapid fire mode, which is something you definitely don't want.
Something you coulud definitely benefit from is having a marker that never dry fires. Opponents can hear the difference between a dry fire and a real fire, and in my day if you ever shot a single dry fire, then your *** was grass in about 5 seconds because you would be bunkered. So, preventing the dry fire by not firing if they eye doesn't see anything is great and I don't think you really need to worry about disabling that too often. I feel like a fail negative would be pretty rare. You should hook your eye output up to an o-scope and simulate all the failures you're talking about to see how the output changes under those conditions.
This is a great project. Good luck!
For starters, I am using a break-beam eye setup (infra-red LED on one side of the breech, reciever on the other)
and yes, in this setup, if the eyes fail (reciever for LED sees nothing, which normally indicates a ball present) then the gun could fire at a point when a ball was only partly loaded, resulting in a chop. I am currently working on a routine to check the eyes again as soon as the solenoid turns off to make sure theres a point when the reciever DOES get a beam from the LED (indicating no ball loaded, eyes still work). that way if the eyes never see that open breech right after firing (even though its only open for a split second) the board would be able to tell that the eyes are not working.
the reason I'm basing this code off of a trigger input only is that I'm half way modeling it after the current board I'm using (The Matrix Center's eyes and board, which the board is a Tadao 1.1) This board has the trigger input, a push button on-off, and the eyes. as outputs, the solenoid and a status LED. I'm not really a fan of having a slide switch for control over the eyes as switches can be hard to use with gloves on. much easier to just pull and hold the trigger. I'm working on coding in a status led (solid on = gun on, eyes on. blinking = gun on eyes off) but at some point I'd like to add a LCD to it.
you commented on being able to turn the eyes back on if needed. that is already written into my code. the eye change routine turns the eyes off if theyre on, and vice versa.
right now, the only way the program goes into blind mode is if you pull the trigger and hold it till it goes through the eye change sub. it never forces itself into blind mode.
as for simulating eye failures with an o-scope... I'm just out of college and flat broke a scope is far down on the list of things to spend my money on. my girlfriend nearly shot me when she found out I bought the parts I got now (the BS2... the board...)
at some point, though I know it would be overkill, but to rewrite all this for a propeller would be kinda fun. have a separate cog for trigger monitoring, eye monitoring, solenoid controll, lcd display and main program... ah dreams... lol
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
Post Edited (FireHelix) : 8/21/2006 11:55:07 AM GMT
-a status LED, solid on = marker working fine, fast blinking = eye error
-eye checking sequence, checks that after solenoid turns off there is a short time that the eyes see an empty breech, if they dont, the program goes into an eye error routine that flashes the led and waits for the trigger to be pulled and held for a short time to disable the eyes (acts as a warning, but allows the eyes to be shut off to continue a game in progress)
still working on having the led flash at a slow rate when the gun is on but the eyes are disabled
I'd post up the new code, but I want to look it over again after I've had some sleep. (yes I know I'm making this post at 7:50am... I'm a night owl and normally awake from 4pm till now. product of working night shift at my old job)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
By some strange turn of events I ran across an article on WARPIG (World And Regional Paintball Information Guide) about 2 weeks ago that got me started on a project to put an ebolt in my 98 with a BS2 running it. I'm interested in how you're setting up the code to check if the eyes are working properly. Hopefully you can post the code some time. I was mainly wondering how long you wait after the bolt returns to the cocked position to see if a ball has loaded yet. Oh, you may have seen it already, or may know more than the article says, but here's a link to part 1 of the WARPIG article:
http://www.warpig.com/paintball/technical/electronics/basic_stamp/
as for te eye, i use break beam eyes so when a paintball is present the beam is blocked. this poses a problem if the eyes break, it would appear a paintball is always present.
i countered this by checking the eyes again as the bolt in my matrix is pulling back (fireing complete). the eyes should see a point in which there is no paintball in the breech (it's falling down into the breech at this point) if the stamp never gets a "breech clear" signal from the eyes, it assumes they are broken and effectively disables the gun while flashing the status LED. the gun is reenabled in eye off mode when the trigger is held down for approx 1 second. or, the other option is to turn the gun off and then back on again (the eyes are on by default on startup)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...
cant wait to see what a modified version of this plus my eye routines can make my paintball gun do
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I know just enough to tinker with something... but not enough to fix it when I break it. Thank the techie gods theres forums...