I will be happy to take a look at the new program, but I suspect my answer will be the same as it was before. Here is my prior answer from a post that is just a few above this one:
"I can't help you much with the error message at "Found_E" as I think it came from Phil Kenny's code."
Perhaps Phil Kenny could supply the entire snippet of code in this area of the program, so we can move ahead a bit.
YO PHIL!
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Andrew,
You can wait for a response from Phil, but it can't hurt to puzzle it through yourself. Experiment!
The first thing I would do is comment out that entire line,
' IF iobyte = $0d THEN GOTO Found_E <--- comment out this line, which waits for carriage return
My educated guess is that that line is superfluous, something left over from another program perhaps, and your program will work just fine without it. There is another instruction just following that serves the same (?!) purpose,
LOOP UNTIL ioByte = $0D ' Wait For Carriage Return
The purpose is to detect an ascii "carriage return" (CR=$0D=$0d) from the Vinculum. Andrew, think carefully about what the program is doing and why. The PBASIC program is looping with the initialization, the test "E" and delays, and it loops until it does receive the expected response from the Vinculum, that indicates that the Vinculum is alive and kicking. It may take several tries, but then it's all good, and it drops on through to the main1 routine.
Edit, I see Phil responded while I was distracted. So after the program responds to an "E" with a CR, it then has to respond to an "e", also with a CR. I don't have a Vinculum, so I am not sure what that accomplishes.
However, if the Vinculum is unplugged or defective, the program will hang up in the initialization. Maybe that is okay, but sometimes you might want the program (generally speaking) to continue to perform other tasks, and to ignore a non-functioning component part. It is part of robust design. For example, even without the Vinculum, your robot could still perform the motions. And you could set it up to store a few readings like minimum, maximum and average temperature in the Stamp eeprom.
Found_E:
DOBaudT9600, [noparse][[/noparse]"e", CR] ' Sync Command Character
GOSUB Get_Data ' Get Response
' DEBUG "e iobyte = ", HEX iobyte, CR
PAUSE 450
LOOP UNTIL ioByte = $0D ' Wait For Carriage Return
I was just copying the original Parallax Demo code for the Memory stick.
Some typos crept into my post. See the newest one.
I agree completely with your suggestion of having a fall back position
to save the data to EEPROM if the Vinculum is broken. However, I'm not
sure this project has time to incorporate this feature plus debugging the
existing code.
phil
Post Edited (phil kenny) : 2/19/2008 11:35:39 PM GMT
Thanks for your assistance with these problems. This has become a bit of a rat-race, and I'm afraid the rat's were winning :-)
I almost afraid to do what I'm about to, but I note here:
The attached program is·for·VIEWING ONLY and that the·present program code which the Rocket Group is using·should be LEFT AS IS, and use the Parallax Memory Stick Demo Code·JUST FOR·REFERENCE.
I hope this helps rather than confuses!
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
I've changed all instances of 'iobyte" to "iobyte1" and I am no longer receiving a message regarding it. However, I am now receiving "Expected a label", for "CR" on the line, "SEROUT TX\CTS, Baud ,"e", CR] ' Sync Command Character" What should I do to fix this new problem?
I've downloaded the program you fixed, Newest_Rocket_Robot_Program_2.bs2, and it will download to the robot just fine. However, it hangs up when it comes to "Synchronizing...Restart...Done, etc..." The only way it comes past it is when I press the "RESET" button on the board, just like it was doing before. What might be the problem? I'm using the same exact, and, unchanged version of the program that you sent me.
Restart:
DEBUG "Restart", CR
PAUSE 400 ' Allow Time To Settle
'
HIGH TX ' Initialize Transmit Line
LOW RTS ' Take Vinculum Out Of Reset
PAUSE 500 ' Allow Time To Settle
DEBUG "Done!", CR, "Synchronizing..."
idx_1 = 0
DO
SEROUT TX\CTS, Baud, [noparse][[/noparse]"E", CR] ' Sync Command Character
GOSUB Get_Data ' Get Response
DEBUG "E iobyte1 = ", HEX iobyte1, " idx_1 = ", DEC idx_1, CR
PAUSE 450
idx_1 = idx_1 + 1
IF iobyte1 = $0d THEN GOTO Found_E
IF idx_1+1 > 5 THEN GOTO Restart
LOOP UNTIL ioByte1 = $0D ' Wait For Carriage Return
Found_E:
DO
SEROUT TX\CTS, Baud ,[noparse][[/noparse]"e", CR] ' Sync Command Character
GOSUB Get_Data ' Get Response
DEBUG "e iobyte1 = ", HEX iobyte1, CR
PAUSE 450
LOOP UNTIL ioByte1 = $0D ' Wait For Carriage Return
These will let you see the what is being sent back from the Vinculum
when it trying to send back an 'E' and 'e' as well as the number of passes
thru the loop.
The downside is that we here in the forum can't see your DEBUG screen.
Bruce and Tracy, any suggestions as to how best to provide assistance??
phil
Post Edited (phil kenny) : 2/20/2008 12:53:44 AM GMT
I will go ahead and add the DEBUG statements in the program to try and see where exactly the problem is. I'll let you know how that turns out when I am finished.
Thanks for your help,
Andrew [noparse]:)[/noparse]
Please don't think I'm chastizing you, but you MUST give us accurate information in your responses. As Phil so aptly said, we don't have your DEBUG screen in front of us.
I can't see any way that the following could have been issued from the "newest" version of the program:
quote
"Synchronizing...Restart...Done, etc..."
end quote
My guess is that it said:
Restart
Done!
Synchronizing...
which is a bit different than what you had stated. I TRUST you ARE using the program that Phil recently supplied a few posts back.
Next step, may we presume that you never saw the following message on your DEBUG screen?
Done
Switching to Short Command Mode...
If that never appeared, I'm beginning to suspect a possible hardware problem. But let's not jump to that conclusion yet, until we see the all the results of the added DEBUG statements which is the best debugging tool we have at the moment.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
WOW - This is high-octane dialogue! Light speed stuff··· , great for the imagination and inspiration of bright young minds·(and a great way to re-energize and challenge squeaky old dogmatic minds like mine, too!) Thanks for all your time guys. I really, REALLY appreciate you sharing your time and expertise.
Thanks, too·for the great information and helpful posts. The kids are really charged up ("we're·working with·experts", they tell their classmates.) One of the parents said, a few weeks ago,·they wanted their kid on the team "because·(s)he needs more of a challenge than school can offer." Looks like they got it, in aces!
Off to "talk" with the robot again (*what's the score now? Computers 3, Programmers 2-1/2...?)
UPDATE: Computers just scored. Again.
SCORE: Computers 4, Programmers 1-1/2
All,
A)···· I’m running Newest_Rocket_Robot_Program_2.bs2 ····· I changed GOSUB main to GOTO main as suggested.
C)····· How can I put sections of the program in a blue box on the forum like you guys do? I’ve gathered that I’m not supposed to cut-and-paste sections into the forum screens·(like I’m about to do. Sorry.)
1) Here’s what appears on the screen when the robot initializes and is connected to the
computer. It cycles through, then measures and records data to the Datalogger as it’s supposed to: ·
Restart
Done!
Synchronizing...E iobyte1 = D idx_1 = 0
e iobyte1 = D
Done
Switching to Short Command Mode...Done!
Waiting for Memory Stick...Ready!
Open! ·Ready to Write Data... ··· *FILE OPEN*
Writing temperature (C) and humidity (%) data..
#1 26.0, 24.9
#2 etc., etc., etc. then recycles ·
2) Below is what appears on the screen when the robot is reinitialized (by switching to “2” on the Parallax board) without being connected to the computer. The Datalogger initializes sometimes but not always . It does not measure or record samples. **It does, however, run the program as it’s supposed to when the black ‘reset’ button is pushed on the Parallax board. It doesn’t always initialize on the first push… Sometimes we have to push it twice or three times.
Restart
Done!
Synchronizing...E iobyte1 = 0 idx_1 = 0
E iobyte1 = 0 idx_1 = 1
E iobyte1 = 0 idx_1 = 2
E iobyte1 = 0 idx_1 = 3
E iobyte1 = 0 idx_1 = 4
Restart
Done!
Synchronizing...E iobyte1 = 0 idx_1 = 0
E iobyte1 = 0 idx_1 = 1
E iobyte1 = 0 idx_1 = 2
E iobyte1 = 0 idx_1 = 3
E iobyte1 = 0 idx_1 = 4
Restart
Done!
Synchronizing...E iobyte1 = 0 idx_1 = 0
E iobyte1 = 0 idx_1 = 1
E iobyte1 = 46 idx_1 = 2
E iobyte1 = D idx_1 = 3
e iobyte1 = 64
e iobyte1 = D
Done
Switching to Short Command Mode...··PROGRAM STOPS RUNNING HERE ….
*Tracy – “Switching to Short Command Mode” IS the last thing that appears. ·
Mark · ·
As an exercise, I went back to a post made on 2-7-08 by Andrew where he attached
a file named "Datalogger_and_Movement.bs2" that worked and logged data to the
Memory Stick Datalogger.
I printed out that file as well as his recent, non functioning file, Newest_Rocket_Program_1.BS2
which doesn't work when trying to log data. Then I compared the two to see if
I could spot anything obvious.
A very informative task.
The first difference was in the old file, there was a call to subroutine SHT_Connection_Reset.
This call is omitted from the non-working program. My guess is that it needs to be there.
There were a few small changes to PAUSE statements. 500 counts in the original
and 450 in the later version. These probably don't matter.
There were major differences when it came to the movement section of the code.
Nowhere in the program documentation is the purpose of the program described.
My guess is that if there was it would read something like this:
Purpose: After being ejected from a rocket this program gathers data (temperature,
and other stuff) at x samples/minute until it lands. Then a robot moves, stops to
gather more data, etc. All data is logged to a Parallax Memory Stick Data logger
with the following data format:
List what each byte in the data record means.
Stating the purpose explicitly will help anyone reading the code get a better
feel of what it is intended to do and what records are saved to Flash memory.
My feeling at this point is that it would be beneficial to backtrack to the working
version of 2-7-08 and make SMALL changes to get the movement sections
included.
It has been my experience that making massive code changes usually causes
lengthy debugging.
Just my observations.
phil
Post Edited (phil kenny) : 2/20/2008 4:00:11 AM GMT
Did the original code from 2-7-08 ("Datalogger_and_Movement.bs2") run okay
when not connected to the computer? That's a key question.
If the Stamp wasn't connected to the computer, how did the DEBUG widow
get anything to show??
Mark said...
2) Below is what appears on the screen when the robot is reinitialized (by switching to “2” on the Parallax board) without being connected to the computer. The Datalogger initializes sometimes but not always . It does not measure or record samples. **It does, however, run the program as it’s supposed to when the black ‘reset’ button is pushed on the Parallax board. It doesn’t always initialize on the first push… Sometimes we have to push it twice or three times.
The way to show code in blue
is to click on the 'CODE' button at the top of the message editor. Copy and paste some code.
Then click on the 'CODE' button once more.
It is still a copy and paste method, but the code will show up better formatted with
indents, etc.
If you want to send a copy of the DEBUG window do the following:
1) With the DEBUG window showing the output, press SHIFT + Print Screen
This will copy the screen to the clipboard in Windows.
2) Open WordPad and paste the clipboard into it. Save as an RTF file and
send it to the forum as an attachment.
·· Yes, you nailed the mission statement on the head:
After being ejected from a rocket this program gathers data (humidity, temperature) until it lands. Then·the robot moves as it descends; the·movement and data collection subroutines cycle back and forth all the way to landing. The robot lands, moves,·stops to
gather more data, moves all over again,etc. All data is logged to a Parallax Memory Stick Data logger (or so we hope!)
Right now-- without the bugs debugged-- we have a choice to make: do we eject the robot and have it ONLY measure data. Or do we have the robot move after it lands, but collect no data. The mission is to gather data so that's a given. But we surrrrrrrrrrre would like to see the robot move and take a range of ground samples as baseline data.
Last year, at Redstone Arsenal/ Marshall Space Flight Center, one of the range officers found our robot and shut it off! We never got to see it move. What a bummer! This year we'd sure like to see it move when we locate it. But we must collect data. That's our primary mission.
Boy, this programming business is mind-bending to a neophyte. I'm a logical-sequential thinker and I'm starting to understand some of the logic and premises behind it. But since I lack the knowledge of program commands, what I can intuitively figure out is limited.
I agree with you: I think that wholesale program changesin the progarm·sent things into a quagmire. Perhaps we should go back to the 2-7-08 program and reassess? It was written in large part by Mike Green and it seemed to work really well. I suspect that Mike is peeking over our cyper-shoulders, grinning, and with a debug fix already figures out. Are you there, Mike? What's your take on this miasma?
You guys have been really kind, and generous to Andrew. Understand that he's 'just' a 7th grader. But boy-oh-boy, are you giving him and education, and a run for his money. Please! Keep it up! We need you! OK - I'll say it again... We worship you!··· <---- Me bowing to your infinite knowledge (again!)
· Yes, "Datalogger_and_Movement.bs2" (2-7-08??) ran very well when attached to the computer. It just didn't run directly from the Parallax board without pushing the reset button...
One trick I've used when trying to debug Basic Stamp code on a board
without a computer connection is to use one or more LEDS connected to
unused ports to show when the code has reached critical points. If
you don't have enough spare ports, you can make the LED blink x times
or stay on for x seconds at different spots in the code.
My original code had a red and green LED to show when the datalogger
file was OPEN or CLOSED, since it would corrupt the data to turn off
power when the file was OPEN. You may want to include something
similar after everything is working.
Having them change state gives some visual feedback that data really
is being logged.
Absence of a Debugging Window makes the process much harder, but
with a little inventiveness, that can be overcome.
When I worked on hard drive design at Quantum, LEDs were the
debugging tool of choice.
If the 2-7-08 code really did run when not connected to a PC, then that might
be a good starting point.
When I created a small datalogging program using the Parallax Memory
Stick, I had an experience similar to yours. The datalogger wouldn't
start reliably in a stand alone mode. I too, had to press the black RESET
switch. When I dug into it, the solution I found was to limit the number
of times it tried to respond the the 'E' character (the Sync command) .
If sending the 'E' followed by a call to Get_Data didn't result in a carriage
return character after five attempts. I had the program send the initialization
sequence again.
HIGH TX ' Initialize Transmit Line
LOW RTS ' Take Vinculum Out Of Reset
PAUSE 500 ' Allow Time To Settle
Andrew is doing very well on this project, considering that this is his
first exposure to Stamp programming. It is a major project at that.
phil
Post Edited (phil kenny) : 2/20/2008 4:43:19 AM GMT
Comments
I will be happy to take a look at the new program, but I suspect my answer will be the same as it was before. Here is my prior answer from a post that is just a few above this one:
"I can't help you much with the error message at "Found_E" as I think it came from Phil Kenny's code."
Perhaps Phil Kenny could supply the entire snippet of code in this area of the program, so we can move ahead a bit.
YO PHIL!
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
Thanks for your assistance. I guess I'll just wait for Mr. Kenny to post a response. Thanks again,
-Andrew
phil
Post Edited (phil kenny) : 2/19/2008 11:03:37 PM GMT
You said, "the mission section of code", where does it go? Does it replace what was there or go somewhere else?
Thanks,
Andrew
had in it.
phil
initialization of the Vinculum:
Restart: DEBUG "Restart", CR PAUSE 400 ' Allow Time To Settle ' HIGH TX ' Initialize Transmit Line LOW RTS ' Take Vinculum Out Of Reset PAUSE 500 ' Allow Time To Settle DEBUG "Done!", CR, "Synchronizing..." idx_1 = 0 DO SEROUT TX\CTS, Baud, [noparse][[/noparse]"E", CR] ' Sync Command Character GOSUB Get_Data ' Get Response ' DEBUG "E iobyte = ", HEX iobyte, CR PAUSE 450 idx_1 = idx_1 + 1 IF iobyte = $0d THEN GOTO Found_E IF idx_1+1 > 5 THEN GOTO Restart LOOP UNTIL ioByte = $0D ' Wait For Carriage Return Found_E: DO SEROUT TX\CTS, Baud [noparse][[/noparse]"e", CR] ' Sync Command Character GOSUB Get_Data ' Get Response ' DEBUG "e iobyte = ", HEX iobyte, CR PAUSE 450 LOOP UNTIL ioByte = $0D ' Wait For Carriage Return ' -----[noparse][[/noparse] Program Code ]---------------------------------------------------- Main: DEBUG "Done", CR, "Switching to Short Command Mode..." SEROUT TX\CTS, Baud, [noparse][[/noparse]"SCS", CR] ' Switch To Short Command Mode GOSUB Get_Data ' Purge Receive Buffer DEBUG "Done!", CR, "Waiting for Memory Stick..." Check_Drive: DO SEROUT TX\CTS, Baud, [noparse][[/noparse]CR] ' Prompt Device For Status GOSUB Get_Data ' Purge Receive Buffer IF buffer(0) = ">" THEN ' Check For Ready Prompt EXIT ' If Ready Then Exit Loop ELSEIF buffer(0) = "N" AND buffer(1) = "D" THEN DEBUG "." ' Device Ready But No Memory Stick ELSEIF buffer(0) = "D" AND buffer(1) = "D" AND flag = 0 THEN DEBUG "Connected!", CR, "Accessing..." flag = 1 ' Memory Stick Ready ELSE DEBUG "." ENDIF PAUSE 250 ' Command Retry Delay LOOP DEBUG "Ready!", CR ' DEBUG "Opening Data File..." ' First Delete Old File ' SEROUT TX\CTS, Baud, [noparse][[/noparse]$07, $20, "datafile.txt", CR] ' PAUSE 100 ' GOSUB Get_Data ' Purge Receive Buffer ' Then Create New File SEROUT TX\CTS, Baud, [noparse][[/noparse]$09, $20, "datafile.txt", CR] PAUSE 100 GOSUB Get_Data ' Purge Receive Buffer DEBUG "Open!", CR, CR, " Ready to Write Data...", CRphil
Post Edited (phil kenny) : 2/19/2008 11:41:55 PM GMT
You can wait for a response from Phil, but it can't hurt to puzzle it through yourself. Experiment!
The first thing I would do is comment out that entire line,
' IF iobyte = $0d THEN GOTO Found_E <--- comment out this line, which waits for carriage return
My educated guess is that that line is superfluous, something left over from another program perhaps, and your program will work just fine without it. There is another instruction just following that serves the same (?!) purpose,
LOOP UNTIL ioByte = $0D ' Wait For Carriage Return
The purpose is to detect an ascii "carriage return" (CR=$0D=$0d) from the Vinculum. Andrew, think carefully about what the program is doing and why. The PBASIC program is looping with the initialization, the test "E" and delays, and it loops until it does receive the expected response from the Vinculum, that indicates that the Vinculum is alive and kicking. It may take several tries, but then it's all good, and it drops on through to the main1 routine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 2/19/2008 11:26:54 PM GMT
phil
I've added the changes, but, I'm now back to the error of "iobyte" as being undefined. Can you please tell me how "iobyte" is supposed to be defined?
Thanks in advance,
Andrew [noparse]:)[/noparse]
the same thing.
I've edited the code I posted originally, so be sure you get the latest post.
phil
However, if the Vinculum is unplugged or defective, the program will hang up in the initialization. Maybe that is okay, but sometimes you might want the program (generally speaking) to continue to perform other tasks, and to ignore a non-functioning component part. It is part of robust design. For example, even without the Vinculum, your robot could still perform the motions. And you could set it up to store a few readings like minimum, maximum and average temperature in the Stamp eeprom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I was just copying the original Parallax Demo code for the Memory stick.
Some typos crept into my post. See the newest one.
I agree completely with your suggestion of having a fall back position
to save the data to EEPROM if the Vinculum is broken. However, I'm not
sure this project has time to incorporate this feature plus debugging the
existing code.
phil
Post Edited (phil kenny) : 2/19/2008 11:35:39 PM GMT
Thanks for your assistance with these problems. This has become a bit of a rat-race, and I'm afraid the rat's were winning :-)
I almost afraid to do what I'm about to, but I note here:
The attached program is·for·VIEWING ONLY and that the·present program code which the Rocket Group is using·should be LEFT AS IS, and use the Parallax Memory Stick Demo Code·JUST FOR·REFERENCE.
I hope this helps rather than confuses!
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
Attached is a cleaned up version of Andrew's latest effort.
It compiles without Syntax errors, but I did notice a possible problem in
Lines 199-201. They read
' Loops back to the start of the main: ground movement sequence GOSUB MAINProblem is that MAIN isn't a subroutine.
I suspect the it should read:
' Loops back to the start of the main: ground movement sequence GOTO MAINphil
I've changed all instances of 'iobyte" to "iobyte1" and I am no longer receiving a message regarding it. However, I am now receiving "Expected a label", for "CR" on the line, "SEROUT TX\CTS, Baud ,"e", CR] ' Sync Command Character" What should I do to fix this new problem?
Thanks,
Andrew
See the revised code attached to my previous post.
It fixes the problem you found as well as several others.
There was a missing '[noparse][[/noparse]' in the statement.
phil
I've downloaded the program you fixed, Newest_Rocket_Robot_Program_2.bs2, and it will download to the robot just fine. However, it hangs up when it comes to "Synchronizing...Restart...Done, etc..." The only way it comes past it is when I press the "RESET" button on the board, just like it was doing before. What might be the problem? I'm using the same exact, and, unchanged version of the program that you sent me.
Thanks for your help,
Andrew
Try that before doing anything else and let us know if that improves things.
To pinpoint exactly where the code is stuck, you need to add some
DEBUG statements at strategic spots. We are now getting into the
art of debugging.
I welcome any suggestions others may have.
At the risk of adding to all this code confusion, I'll suggest where to
put a few Debug statements that may aid in locating the problem
area(s).
You will have to comment out the following line of code to make room for
these DEBUG changes:
'DEBUG "_________________________________________________________", CR, CR, CR
These will let you see the what is being sent back from the Vinculum
when it trying to send back an 'E' and 'e' as well as the number of passes
thru the loop.
The downside is that we here in the forum can't see your DEBUG screen.
Bruce and Tracy, any suggestions as to how best to provide assistance??
phil
Post Edited (phil kenny) : 2/20/2008 12:53:44 AM GMT
"GOSUB MAIN" is now "GOTO MAIN" and I am still receiving the same results.
-Andrew
phil
I will go ahead and add the DEBUG statements in the program to try and see where exactly the problem is. I'll let you know how that turns out when I am finished.
Thanks for your help,
Andrew [noparse]:)[/noparse]
0D. That's the HEX value for carriage return
When the Vinculum is responding normally, you should see the following
in the DEBUG window:
E iobyte1 = 0D idx_1 = 1 (or 2,3,4)
e iobyte1 = 0D
phil
Post Edited (phil kenny) : 2/20/2008 1:13:51 AM GMT
Please don't think I'm chastizing you, but you MUST give us accurate information in your responses. As Phil so aptly said, we don't have your DEBUG screen in front of us.
I can't see any way that the following could have been issued from the "newest" version of the program:
quote
"Synchronizing...Restart...Done, etc..."
end quote
My guess is that it said:
Restart
Done!
Synchronizing...
which is a bit different than what you had stated. I TRUST you ARE using the program that Phil recently supplied a few posts back.
Next step, may we presume that you never saw the following message on your DEBUG screen?
Done
Switching to Short Command Mode...
If that never appeared, I'm beginning to suspect a possible hardware problem. But let's not jump to that conclusion yet, until we see the all the results of the added DEBUG statements which is the best debugging tool we have at the moment.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
WOW - This is high-octane dialogue! Light speed stuff··
Thanks, too·for the great information and helpful posts. The kids are really charged up ("we're·working with·experts", they tell their classmates.) One of the parents said, a few weeks ago,·they wanted their kid on the team "because·(s)he needs more of a challenge than school can offer." Looks like they got it, in aces!
Off to "talk" with the robot again (*what's the score now? Computers 3, Programmers 2-1/2...?)
Mark
SCORE: Computers 4, Programmers 1-1/2
All,
A)···· I’m running Newest_Rocket_Robot_Program_2.bs2
C)····· How can I put sections of the program in a blue box on the forum like you guys do? I’ve gathered that I’m not supposed to cut-and-paste sections into the forum screens·(like I’m about to do. Sorry.)
1) Here’s what appears on the screen when the robot initializes and is connected to the
computer. It cycles through, then measures and records data to the Datalogger as it’s supposed to:
·
Restart
Done!
Synchronizing...E iobyte1 = D idx_1 = 0
e iobyte1 = D
Done
Switching to Short Command Mode...Done!
Waiting for Memory Stick...Ready!
Open!
·Ready to Write Data...
··· *FILE OPEN*
Writing temperature (C) and humidity (%) data..
#1 26.0, 24.9
#2 etc., etc., etc. then recycles
·
2) Below is what appears on the screen when the robot is reinitialized (by switching to “2” on the Parallax board) without being connected to the computer. The Datalogger initializes sometimes but not always . It does not measure or record samples. **It does, however, run the program as it’s supposed to when the black ‘reset’ button is pushed on the Parallax board. It doesn’t always initialize on the first push… Sometimes we have to push it twice or three times.
Restart
Done!
Synchronizing...E iobyte1 = 0 idx_1 = 0
E iobyte1 = 0 idx_1 = 1
E iobyte1 = 0 idx_1 = 2
E iobyte1 = 0 idx_1 = 3
E iobyte1 = 0 idx_1 = 4
Restart
Done!
Synchronizing...E iobyte1 = 0 idx_1 = 0
E iobyte1 = 0 idx_1 = 1
E iobyte1 = 0 idx_1 = 2
E iobyte1 = 0 idx_1 = 3
E iobyte1 = 0 idx_1 = 4
Restart
Done!
Synchronizing...E iobyte1 = 0 idx_1 = 0
E iobyte1 = 0 idx_1 = 1
E iobyte1 = 46 idx_1 = 2
E iobyte1 = D idx_1 = 3
e iobyte1 = 64
e iobyte1 = D
Done
Switching to Short Command Mode...·· PROGRAM STOPS RUNNING HERE ….
*Tracy – “Switching to Short Command Mode” IS the last thing that appears.
·
Mark
·
·
As an exercise, I went back to a post made on 2-7-08 by Andrew where he attached
a file named "Datalogger_and_Movement.bs2" that worked and logged data to the
Memory Stick Datalogger.
I printed out that file as well as his recent, non functioning file, Newest_Rocket_Program_1.BS2
which doesn't work when trying to log data. Then I compared the two to see if
I could spot anything obvious.
A very informative task.
The first difference was in the old file, there was a call to subroutine SHT_Connection_Reset.
This call is omitted from the non-working program. My guess is that it needs to be there.
There were a few small changes to PAUSE statements. 500 counts in the original
and 450 in the later version. These probably don't matter.
There were major differences when it came to the movement section of the code.
Nowhere in the program documentation is the purpose of the program described.
My guess is that if there was it would read something like this:
Purpose: After being ejected from a rocket this program gathers data (temperature,
and other stuff) at x samples/minute until it lands. Then a robot moves, stops to
gather more data, etc. All data is logged to a Parallax Memory Stick Data logger
with the following data format:
List what each byte in the data record means.
Stating the purpose explicitly will help anyone reading the code get a better
feel of what it is intended to do and what records are saved to Flash memory.
My feeling at this point is that it would be beneficial to backtrack to the working
version of 2-7-08 and make SMALL changes to get the movement sections
included.
It has been my experience that making massive code changes usually causes
lengthy debugging.
Just my observations.
phil
Post Edited (phil kenny) : 2/20/2008 4:00:11 AM GMT
Did the original code from 2-7-08 ("Datalogger_and_Movement.bs2") run okay
when not connected to the computer? That's a key question.
If the Stamp wasn't connected to the computer, how did the DEBUG widow
get anything to show??
The way to show code in blue
is to click on the 'CODE' button at the top of the message editor. Copy and paste some code.
Then click on the 'CODE' button once more.
It is still a copy and paste method, but the code will show up better formatted with
indents, etc.
If you want to send a copy of the DEBUG window do the following:
1) With the DEBUG window showing the output, press SHIFT + Print Screen
This will copy the screen to the clipboard in Windows.
2) Open WordPad and paste the clipboard into it. Save as an RTF file and
send it to the forum as an attachment.
I can provide an example if this isn't clear.
phil
·· Yes, you nailed the mission statement on the head:
After being ejected from a rocket this program gathers data (humidity, temperature) until it lands. Then·the robot moves as it descends; the·movement and data collection subroutines cycle back and forth all the way to landing. The robot lands, moves,·stops to
gather more data, moves all over again,etc. All data is logged to a Parallax Memory Stick Data logger (or so we hope!)
Right now-- without the bugs debugged-- we have a choice to make: do we eject the robot and have it ONLY measure data. Or do we have the robot move after it lands, but collect no data. The mission is to gather data so that's a given. But we surrrrrrrrrrre would like to see the robot move and take a range of ground samples as baseline data.
Last year, at Redstone Arsenal/ Marshall Space Flight Center, one of the range officers found our robot and shut it off! We never got to see it move. What a bummer! This year we'd sure like to see it move when we locate it. But we must collect data. That's our primary mission.
Boy, this programming business is mind-bending to a neophyte. I'm a logical-sequential thinker and I'm starting to understand some of the logic and premises behind it. But since I lack the knowledge of program commands, what I can intuitively figure out is limited.
I agree with you: I think that wholesale program changesin the progarm·sent things into a quagmire. Perhaps we should go back to the 2-7-08 program and reassess? It was written in large part by Mike Green and it seemed to work really well. I suspect that Mike is peeking over our cyper-shoulders, grinning, and with a debug fix already figures out. Are you there, Mike? What's your take on this miasma?
You guys have been really kind, and generous to Andrew. Understand that he's 'just' a 7th grader. But boy-oh-boy, are you giving him and education, and a run for his money. Please! Keep it up! We need you! OK - I'll say it again... We worship you!·
'Talk' to you in the AM,
Mark
· Yes, "Datalogger_and_Movement.bs2" (2-7-08??) ran very well when attached to the computer. It just didn't run directly from the Parallax board without pushing the reset button...
Mark
One trick I've used when trying to debug Basic Stamp code on a board
without a computer connection is to use one or more LEDS connected to
unused ports to show when the code has reached critical points. If
you don't have enough spare ports, you can make the LED blink x times
or stay on for x seconds at different spots in the code.
My original code had a red and green LED to show when the datalogger
file was OPEN or CLOSED, since it would corrupt the data to turn off
power when the file was OPEN. You may want to include something
similar after everything is working.
Having them change state gives some visual feedback that data really
is being logged.
Absence of a Debugging Window makes the process much harder, but
with a little inventiveness, that can be overcome.
When I worked on hard drive design at Quantum, LEDs were the
debugging tool of choice.
If the 2-7-08 code really did run when not connected to a PC, then that might
be a good starting point.
When I created a small datalogging program using the Parallax Memory
Stick, I had an experience similar to yours. The datalogger wouldn't
start reliably in a stand alone mode. I too, had to press the black RESET
switch. When I dug into it, the solution I found was to limit the number
of times it tried to respond the the 'E' character (the Sync command) .
If sending the 'E' followed by a call to Get_Data didn't result in a carriage
return character after five attempts. I had the program send the initialization
sequence again.
Andrew is doing very well on this project, considering that this is his
first exposure to Stamp programming. It is a major project at that.
phil
Post Edited (phil kenny) : 2/20/2008 4:43:19 AM GMT