Because in "Pause" (or is it 'Sleep') mode, there's a 2.1 second 'tick' where the BS2 'wakes up' briefly, sets all pins to input, checks if the sleep time has expired, then returns to sleep if it hasn't.
If you've got a pin set as an output, at that 2.1 second point it will appear to 'turn off'. Interesting that it takes 15 mSec to return to sleep.
The explanation remains exactly the same as mentioned, but here is one way to avoid the "glitching". Place the following as the LAST statement in your program:
Looper: GOTO Looper 'Create an infinite loop
That's it.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When all else fails, try inserting a new battery.
I guess we should take this one step further. Here is the noted explaination of the END statement (supplied or implied) as to why the "glitching" occurs:
quote
END
Explanation
END puts the BASIC Stamp into its inactive, low-power mode. In this mode the Stamp's current draw (excluding loads driven by the I/O pins) is reduced to the amount shown above. END keeps the BASIC Stamp inactive until the reset line is activated, the power is cycled off and back on or the PC downloads another program.
Just as with the SLEEP command, pins will retain their input or output settings after the BASIC Stamp is deactivated by END. For example, if the BASIC Stamp is powering an LED when END executes, the LED will stay lit after END, but every 2.3 seconds, there will be a visible wink of the LED as the output pin switches to the input direction for 18 ms.
End quote
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When all else fails, try inserting a new battery.
You can end the program with
STOP
That has the same effect as ending the program with
DO:LOOP
As an aside, the glitch with the BS2pe is 100 times shorter than the other Stamps, 0.15 milliseconds instead of 15 milliseconds. That allows the BS2pe to achieve much longer battery life in a system that can spend much of its time asleep, such as a data logger.
Hi everyone, this is my first post. I have recently acquired the Boe-Bot kit (with bluetooth) for MS Robotics Studio and have been spending 2-4 hours almost every night to figure things out.
I say it because it might be related, I have 32bit Vista, have the Keypan 19HS. Initially, Basic Stamp Editor had problem locking onto COM13, but that problem went away, came back and went away again. So the problem I have right now is like mentioned above where I have the following code:
' {$STAMP BS2}
' {$PBASIC 2.5}
DEBUG "Program running..."
counter VAR Word
FREQOUT 4, 2000, 3000
FOR counter = 1 TO 122
PULSOUT 13, 850
PULSOUT 12, 650
PAUSE 20
NEXT
END
What happens is:
1. in the debug window it shows Program running...
2. it makes the noise for 2 seconds
3. moves forward for maybe half a second, very short distance.
Weird part is, it does all three points above again after sleeping for a second or two, endlessly.
I read your comments above but I don't think I understand the issue and what needs to be done in general so that I have a reliable system to build on.
This behavior typically happens when your servos are "browning out" the power supply. I'll assume you're running with a 9-volt battery, or are using 4 NiMh rechargeable cells. Both would have a hard time running two servo's without losing enough voltage to "brown-out-reset" the BS2.
From the program itself, it should do steps 1 to 3 and then stop, not repeat. Like allenlane5 says, something is resetting the Stamp. Does it do the same thing when it is disconnected from the computer? Maybe the computer is doing something on the serial port that causes the Stamp to reset. How about when the servos are disconnected (just the beeper)? Does it do the same thing if you try a bigger battery pack? If it is a power supply issue, sometimes a good size filter capacitor can help.
1. Disconnect serial, hit reset and see what happens -- ruling out program being uploaded again and again.
2. Disconnect servos and try
3. I don't have a bigger battery pack, how about a 9V adapter? Anything I need to look out for in the adapter?
Possible hint:
Something interesting happened when I disconnected the external hard drive from my laptop the other day. The frequency in which the program re-ran changed, it waited longer in between. (I think No.1 above, disconnecting the serial can lead to a solution)
I will report back my findings tonight. Thanks for helping me resolve this issue.
So I just loaded that program and of course it worked like a charm, for the first time. It probably had to do with my connection, maybe that was resetting constantly. If it happens again, I will check the above and the Keyspan logs, maybe I can confirm from there...
Spoke to early. It's really odd. Now it sometimes works, sometimes doesn't. Also when I hit run, sometimes it fails to find the stamp.
Going back to the three items I was going to test:
1. Disconnect serial, hit reset and see what happens --> it continues to run the program in an infinite loop with about a second pause it between. So no difference.
2. Disconnect servos and try (while serial is disconnected) --> The sound happens just once, meaning it works correctly. Also tried with one servo connected at a time, this also works correctly.
3. Testing with an adapter --> Haven't tested this yet.
From above, the result is when 1 or 0 servos are connected the program runs once, otherwise it runs endlessly.
ie_Coder
Posts: 2
Comments
If you've got a pin set as an output, at that 2.1 second point it will appear to 'turn off'. Interesting that it takes 15 mSec to return to sleep.
The explanation remains exactly the same as mentioned, but here is one way to avoid the "glitching". Place the following as the LAST statement in your program:
Looper: GOTO Looper 'Create an infinite loop
That's it.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When all else fails, try inserting a new battery.
Try a program consisting of just "HIGH 8" followed by "here: GOTO here".
I guess we should take this one step further. Here is the noted explaination of the END statement (supplied or implied) as to why the "glitching" occurs:
quote
END
Explanation
END puts the BASIC Stamp into its inactive, low-power mode. In this mode the Stamp's current draw (excluding loads driven by the I/O pins) is reduced to the amount shown above. END keeps the BASIC Stamp inactive until the reset line is activated, the power is cycled off and back on or the PC downloads another program.
Just as with the SLEEP command, pins will retain their input or output settings after the BASIC Stamp is deactivated by END. For example, if the BASIC Stamp is powering an LED when END executes, the LED will stay lit after END, but every 2.3 seconds, there will be a visible wink of the LED as the output pin switches to the input direction for 18 ms.
End quote
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When all else fails, try inserting a new battery.
STOP
That has the same effect as ending the program with
DO:LOOP
As an aside, the glitch with the BS2pe is 100 times shorter than the other Stamps, 0.15 milliseconds instead of 15 milliseconds. That allows the BS2pe to achieve much longer battery life in a system that can spend much of its time asleep, such as a data logger.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I say it because it might be related, I have 32bit Vista, have the Keypan 19HS. Initially, Basic Stamp Editor had problem locking onto COM13, but that problem went away, came back and went away again. So the problem I have right now is like mentioned above where I have the following code:
' {$STAMP BS2}
' {$PBASIC 2.5}
DEBUG "Program running..."
counter VAR Word
FREQOUT 4, 2000, 3000
FOR counter = 1 TO 122
PULSOUT 13, 850
PULSOUT 12, 650
PAUSE 20
NEXT
END
What happens is:
1. in the debug window it shows Program running...
2. it makes the noise for 2 seconds
3. moves forward for maybe half a second, very short distance.
Weird part is, it does all three points above again after sleeping for a second or two, endlessly.
I read your comments above but I don't think I understand the issue and what needs to be done in general so that I have a reliable system to build on.
Thanks a lot,
Yagmur Coker
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I will try tonight:
1. Disconnect serial, hit reset and see what happens -- ruling out program being uploaded again and again.
2. Disconnect servos and try
3. I don't have a bigger battery pack, how about a 9V adapter? Anything I need to look out for in the adapter?
Possible hint:
Something interesting happened when I disconnected the external hard drive from my laptop the other day. The frequency in which the program re-ran changed, it waited longer in between. (I think No.1 above, disconnecting the serial can lead to a solution)
I will report back my findings tonight. Thanks for helping me resolve this issue.
yagmur
Thanks again.
Going back to the three items I was going to test:
1. Disconnect serial, hit reset and see what happens --> it continues to run the program in an infinite loop with about a second pause it between. So no difference.
2. Disconnect servos and try (while serial is disconnected) --> The sound happens just once, meaning it works correctly. Also tried with one servo connected at a time, this also works correctly.
3. Testing with an adapter --> Haven't tested this yet.
From above, the result is when 1 or 0 servos are connected the program runs once, otherwise it runs endlessly.
Any ideas?