Delay code isn't delaying.
 

I'm working with Kevin Watson's 3.0 compatible FRC framework. I have code in the begining of my Autonomous() function that should cause the robot to wait, based on a few constants defined in Autonomous.h. It doesn't seem to work, and just takes off immediately. Could it have something to do with the fact that the field control system spends a moment in teleop before jumping to autonomous in the begining?

I attached a .zip archive with my entire workspace.

Thank you for helping.

-Guy Davidson

Re: Delay code isn't delaying.
 

Might it have something to do with this line in autonomous.h?

Re: Delay code isn't delaying.
 

That line is commented out as part of this block:
The copy I hope it's using is defined a few lines later:
Is there any way that's causing issues?

Re: Delay code isn't delaying.
 

I didn't think the preprocessor cared about comment lines. Are you getting any compiler errors or warnings about trying to redefine a symbol?

Re: Delay code isn't delaying.
 

Nope. No errors or warnings what-so-ever, as far as I can see.

Re: Delay code isn't delaying.
 

The best thing to do for delays is make a counter that does everything. Here is a few lines that I used for our robot in the Tacoma Regional:

int timer = 0;

if(timer < 72)
/* 72, if I remember right, is about 2 seconds, this number can be adjusted however you need it to be */
{
timer ++;
}
else
{
// This is where the remainder of autonomous functions occured
}

Re: Delay code isn't delaying.
 

It cycles 40 times a second right? So you can just make a function that returned i / 40 so you can say if(timer < 2) which would be the actual amount of seconds. I know it's basic math to just multiply by 40, but it makes the code a little more readable for someone that doesn't know that.

Re: Delay code isn't delaying.
 

That's pretty much what I have there.

Re: Delay code isn't delaying.
 

if that is what you are doing, I don't know what the issue would be. Can you copy and paste your delay code here so I (or anyone else) can help you?

Re: Delay code isn't delaying.
 

It's in autonomous.c in the attached archive. Since it's also based on stuff in autonomous.h, I left it in an archive. Would it help if I copy both .c and .h here?

Re: Delay code isn't delaying.
 

The only thing I can think of now is changing this:

if(auton_counter < WAITING_TIME * LOOPS_IN_A_SECOND)

to this:

if(auton_counter < (WAITING_TIME * LOOPS_IN_A_SECOND))

Maybe try printing out WAITING_TIME and LOOPS_IN_A_SECOND and see what it's outputting.

Re: Delay code isn't delaying.
 

What does your debug statement say for the value of counter?

Re: Delay code isn't delaying.
 

The code is fairly confusing for me as to what you are trying to do. The way I learned programming makes this very hard to read, no offense. I just can't figure out what is wrong with it.

Re: Delay code isn't delaying.
 

I too find the highly compact style a hindrance to readability. I actually reformatted the relevant lines in order to make it easier for me to see what the code was trying to do.

I don't remember who said it, but I agree with the philosophy that says a programmer's job is to write documentation that compiles into a working program.

Re: Delay code isn't delaying.
 

That's the next thing I was going to check. I put it in there during our last competition in hopes of getting around to test it there, and I haven't been able to yet. I'm hoping to do that early Thursday morning in Atlanta.

Re: Delay code isn't delaying.
 

What would you suggest I do to make it more readable?

Re: Delay code isn't delaying.
 

It looks like you might be being bitten by C18's habit of doing single byte arithmetic. In your if statement cast WAITING_TIME and LOOPS_IN_A_SECOND to int.

For example:
if(auton_counter < (int) WAITING_TIME * (int) LOOPS_IN_A_SECOND){ //wait

C18 is most likely currently treating them as single byte numbers - so 8 x 38 is 304, which overflows to become 48. (Which would only give you about a 1 second wait.)

Re: Delay code isn't delaying.
 

Thanks, I'll do that and give it a shot on Thursday.

Re: Delay code isn't delaying.
 

I know this sound trivial, and it "should" work the way you have it, but....

Try changing
to

I've been bitten by this a couple times.

Re: Delay code isn't delaying.
 

The double less-then signs will not do what you intend (they will shift auton_counter left by WAITING_TIME * LOOPS_IN_A_SECOND, which will end up being 0).

Re: Delay code isn't delaying.
 

This is the correct solution.

Re: Delay code isn't delaying.
 

Spread stuff out a bit. Add white space. Put matching braces in the same columns. That sort of thing. Where you have this:
I would change it to
All I did was add spaces, tabs, and newlines.

If you prefer terseness, here is a common idiom for such counters:

I have learned not to rely on preprocessor arithmetic to get things right. It took us two regionals to figure that out this year. Instead of a nice, readable travel ( 150 * INCH ); (INCH is 25) we have to say travel ( 3750 ); in order for everything to work the way we expect.

Re: Delay code isn't delaying.
 

Thanks. I'll keep that in mind when I get around to writing more code.
It could actually be the same problem. If, as rdaugherty suggests, the compiler tends to use byte arithmetic if both operands are bytes and it isn't explicitly told otherwise, then in your multiplication too, it would end up casted into a byte, I think. I'm planning to test this theory in Atlanta, once I have robot access again.

Re: Delay code isn't delaying.
 

Since integer promotion isn't enabled by default, and those preprocessor macros are effectively just search-and-replace, the calculations would not give the expected result. Casting them correctly and using parentheses generously should fix this, as previously stated.