Quote:
Originally posted by Joe Ross
I think it is unlikley that setting the pwm values to 255 is causing the problem. But, it depends on what PWM values the variables correspond to. If this was the problem, you'd have a problem sometime into running the program, not on download.
how big is dist and whlc and do you overrun anything when adding them together? Same thing, this shouldn't cause the error, but is something to look into.
I think the most likely cause was already mentioned by Ian. If you tried to read in a new sensor, but didn't define the constant saying that you want to read it, your serin will be mismatched with the initialization. Look at the section of the code labled "DEFINE CONSTANTS FOR INITIALIZATION"
It would also be helpful to see more of your code if one of the suggestions doesn't help.
|
Joe, what you're describing is what causes Basic Init Errors, and not Basic Run Errors.
From the Innovation First Full-Size Robot Controller Reference Guide:
Quote:
Programming Problem: Basic Run Error Indicator
If after programming and resetting the Robot Controller, the BASIC RUN ERR LED is ON, then the
basic code has no output. This means that the code is not running properly. Check for errors in the
code. The BASIC RUN ERR light is controlled by the Output microprocessor.
Programming Problem: Basic Init Error Indicator
If after programming and resetting the Robot Controller, the BASIC INIT ERR LED is ON, then the
basic code did not properly initialize the data packet structure with the master microprocessor. Check
the initialization part of the code for errors. A common mistake is having a different number of
variables in the SERIN command, as compared to the requested data setup in the “Set the Initialization
constants you want to read” section of the code. The BASIC INIT ERR light is controlled by the Master
microprocessor.
|
My guess is that either[list=1][*]the 255s are causing the problem, or[*]some part of the code other than that of which we have visibility is preventing the serout from being executed.[/list=1]
BTW, the two relay bytes are deliberately interspersed in the serout command between PWMs 1, 2 and 3 to prevent 255s output to PWMs from causing problems in the most common cases where someone is using the default code (or has made minimal modifications to it.) So, Salik, if you're using two consecutive PWMs (not including 1 and 2) for drive_r and drive_l, there's your problem. (Actually, it is still possible to provoke this problem when you're using PWMs 1 through 3 if you happen to turn on all the relays in one of the relay bytes.)