Basic Run Error

[Ulibrium]

Hi,

We have the problem of generating a BASIC Run Error in the middle of robot operation. We have put in a lot of custom programming, but none of it looks error-causing. The only way I could see a BASIC Run Error occurring is a divide by zero, or a loss in syncrhonization between the RC and OI. I don't think that either of those are the problems. Can someone help me out here?

[Ian W.]

well, the only time i've seen a basic run error is if i use GreenDice's dashboard program plugged into the program port (not sure why though) or if i download some new code. other than that, i've never seen that happen.

[Curtis Williams]

Try putting debug statements somewhere in your main loop. See if the loop is completing or stopping somewhere.

[Ulibrium]

I made a custom dashboard program in VB for the robot. If what you are saying about the GreenDice program is true, maybe that's what's causing the problem?

[Greg Ross]

I think that was the error I saw last night when I was using one of the other engineer's Windows XP laptop (I normally have used Win95.) When I downloaded a program which contained debug statements, and closed the debug window, I would get a basic run error on the robot. To recover from the error, I had to do one of the following:[list=1][*]Start up a new debug window.[*]Download a new program (and reset the robot controller)[*]Disconnect the programming cable between the robot and the laptop (and reset the robot controller -- I think.)[/list=1]

If that doesn't do it for you, the old standby reply is "Make sure the data requested in your initialization shiftout matches the variables read in the serin command."

[GreenDice]

Please note that the Basic Stamp uses the DTR signal on the programming port as a "Reset" line. When you download a new program, the editor changes the state of the DTR line to reset the processor before downloading.

I think the Dashboard Monitor program changes the DTR line when it initalize the COM port. Thus the program is reset. So it is better to have the cable plugged in first when you start up the Dashboard Monitor porgram.

If you need more help on the RC connection with the Dashboard Monitor, please email me directly (liu@syrres.com)

[Ian W.]

Well, that will be something to try at the first regional i'm going to (LI Regional) since the robot is gone, and i have no other robot to test it on (being a rookie team and all). It's not that i need the program working, it's just a nice feature to play with.

[Greg Ross]

Originally posted by Ulibrium
We have the problem of generating a BASIC Run Error in the middle of robot operation.

I just noticed you said "in the middle of robot operation". This will happen if your battery voltage is too low too.

[Ian W.]

Really? When our batteries "died" i thought the little orange light just went on. Then, the spinning light turned off, along with everything else, and my entire team is yelling at me, "What's wrong! Hit the button and make the robot go!".

then, i sat there trying to explain to them how the RC turns itself off with a voltage lower that 9, and they were all scratching their heads. sheesh, gotta love all the people who build the robot, but have no idea how it works.

[Ulibrium]

Ok, here are the details. All I know is what they told me when they tested the robot, because unfortunately our team worked on the 'bot up until the last day and we had zero time to debug. Additionally, I wasn't there when they got it running so they had to figure things out without me. We designed a control system which includes a custom VB dashboard plugged into the serial dashboard port of the OI, and a steering wheel. We programmed the RC for steering wheel support on the USER slot and 2-joystick support on the DEFAULT slot. This way, if the calibration is funky, we can just fall back on a surefire system. The only difference between the two programs is a scaling factor, because steering wheel output only seems to range between 183-254, for example, instead of the full 0-254, and also a forward/reverse flag that is triggered by one of the buttons on the steering wheel. At the time of robot operation, nothing was plugged into program port of the RC. They reported to me that the BASIC Run Error LED would come on much more often for steering wheel drive than for joystick drive. This puzzles me. As soon as I get back in, I'm going to scour the code for debug statements and purge it. If this is the problem, I'll return and make you guys aware. Otherwise, I need some help.

P.S. They would have been aware if the battery voltage drops. That is part of our dashboard.

[Greg Ross]

Originally posted by Ulibrium
The only difference between the two programs is a scaling factor...

You might check your scaling algorithm. Remember, you need to limit your PWM outputs to 254. I don't know what (if anything) untoward happens if you send an occasional 255, but if you send two in a row in the serout command, the robot controller takes that as the beginning of a new data packet. It wouldn't surprise me at all if the symptom in such a case is a BASIC Run Error.

[Matt Attallah]

Our controls had a basic error too, but it ran perfect. The robot one didn't pick it up, i think, but our driver-controller did. That little red light stayed on, or until i put duck tape over it. Haha, little red, basic error light, who has the upper hand now?

Just put a strip of duck tape when you see your robot agian, and all will be well. Just give it 2-3 hours to let the duck tape act as a bandage, and there u go, brand new robot!

[Ian W.]

Actually, sending two 255's in a row will not make the RC get a basic run error. Believe me, I've done it (hey, it's my first year programming). All it did was make the RC flip out. For the Basic Run Error, well, i would guess you just screwed up one thing in the code, like a "+" sign instead of a "-" sign. This downloads fine, but when you try and run the program, boy can something as simple as that flip the robot out. Especially when controlling the motors. It's not good when you're motors go from full reverse to full forward in about .02 seconds. Not good at all...