KOP Gear Tooth Encoder Trouble

[Sykan]

I'm not exactly sure how the encoder works but I've been trying to test it with kevin's code. i think i've cover all the bases. i uncommented the Initialize in the teleop.c, uncommented the define in the encoder.h file, uncommented the interrupt in the ifi_frc.h and uncommented the encoder counter printf.

I have the gear tooth sensor to a 12 volt source and a 30 fuse though the white(+) and ground(-) to power it. and a pwm connected to the Rc digital input 11.

When i placed the encoder next to a spinning gear. the Counter printf was a solid 0 the whole time

I went on to print out the value of the digital input it starts out as 0 as soon as I put a metal object and it changes to 1 but when i move the object away it doesn't change back. like i said i don't know if this is normal operation.

I also had a question about the holes in the gear box i read some where that the two holes at an angle on the side were for this encoder but it neither fits nor is close enough to read the gear.. unless it need to be far away for the gear?

Thank you for any light you maybe able to shed on the situation.

~David Elizondo

[Alan Anderson]

I'm guessing that the encoder is working fine, but your printf() is broken.

The encoder count functions return a long integer. You've probably tried to print the value using the %d format string, which expects an integer. All you're getting printed is the first half of the count, essentially 1/65536 of the true value. If you wait long enough, you'll see it change. Change the %d to %ld, or put (int) in front of the encoder function call to cast it to a 16-bit value for printing.

If that isn't the problem, I'd look at the encoder wiring. You said you're supplying +12 and ground, and that's good. Along with the signal, you do have ground and +5 from the RC's digital input connected to the proper pins as well, right?

[Sykan]

I don't think it's my printf statement because I'm using kevin printf. and it's a con. zero.

The printf statment I made was to read the rc dig itself so I see if the variable is changing and since it's a dig input it can only change 0 to 1 and back again.

the pwm connected is connected correctly.

Any other guesses?

[Joe Ross]

Originally Posted by Sykan

I don't think it's my printf statement because I'm using kevin printf. and it's a con. zero.

The printf statment I made was to read the rc dig itself so I see if the variable is changing and since it's a dig input it can only change 0 to 1 and back again.

the pwm connected is connected correctly.

Any other guesses?

It takes longer to print a single character then the time the gear tooth sensor's output is 1. The chances that you would actually catch the output high is very low.

If you follow Alan's post about how to print a long, you should see it counting up.

Make sure you aren't using the bad board too. Read this post: http://www.chiefdelphi.com/forums/sh...ad.php?t=62856

[RyanN]

It could also be the problem that teams have been experiencing with the KOP gear tooth sensors. We connected both of ours up (one good, one bad) the good one worked fine, the bad one gave us a value of 1 after moving it for a while.

[fabalafae]

The printf works now; it wasn't the long int problem, it was something else. But anyway...

The encoder printf is now remaining stable at 2560 and fluctuating to 768 every few times.

And also it's the good encoder, not the bad one.

We have a big code problem: it's putting out 2560 and 768 and 0 and 5 (and other miscellaneous random values) WITHOUT as well as WITH the encoder connected...uhm...

Any ideas? Please?

[RyanN]

What version of Kevin's code are you using? We've had no problems with his code so far except stuff we did wrong. Make sure you have read the README's, as there are more steps to getting the sensors to work than you would think. We're using the version made for 3.0, and I really like it. Some things are simpler than I thought, like the Get_Analog_Value() function, all you have to do is put a number in... very simple. I would recommend using 3.0 if you're not using it already.

[fabalafae]

We're using the latest version of Kevin's code- and we downloaded it again, just to be sure. Yeah, the encoders still don't work.

I don't know what else we can try, but I guess we'll still be working on finding the problem this afternoon after school.

[Kevin Watson]

Originally Posted by Sykan

...and a pwm connected to the Rc digital input 11.

This at least one of your problems. You should be using the phase a input on digital input 1. Then make sure to modify the encoder.c/Int_1_ISR() function to look like this:

void Int_1_ISR(void)
{
    Encoder_1_Count += ENCODER_1_TICK_DELTA;
}

-Kevin

[dcbrown]

I have some files that need some define/setup/config stuff or they won't work correctly. The setup depends on the configuration of the robot - like pins and stuff - and I'm always forgetting to go in and do this as I roll projects forward and do what I call a "refresh" of the code (pull in latest library modules, drivers, etc. from source pool).

So I've resorted to putting the following in the source files to remind me. Yes, its stupid... but it works.

Not saying this was the latest issue above... but I've seen a number of threads related to something similar...

//
// Cause a syntax error, after you read the "readme" section above, 
// remove this line.
unsigned char tmp = someone_forgot_to_read_the_included_readme_section;

encoder.c:3:Error [1105] symbol 'someone_forgot_to_read_the_included_readme_section' has not been defined

[Severious]

Originally Posted by Kevin Watson

This at least one of your problems. You should be using the phase a input on digital input 1. Then make sure to modify the encoder.c/Int_1_ISR() function to look like this:

void Int_1_ISR(void)
{
    Encoder_1_Count += ENCODER_1_TICK_DELTA;
}

-Kevin

I too am having trouble getting the gear tooth sensor to work using your (Kevin's) code. I also have my GTS connected to digital port 11 with a PWM cable. It works with easyc. What is a "phase a input", and don't you mean digital input 11?

Thanks

Scott

[paulcd2000]

i think i understand the misunderstanding. each encoder has 2 pins, phase a and phase b. the phase b pins are, by default, 11-16. the phase a pins, however are... more complicated. they're (as it says in documentation), 1-6. HOWEVER, i can't find where that's defined, so we can't change those. for me, however, the endcoder comes out as 1 pwm cable. if that's true for you, then guess what! they aren't encoders! they're actually gear tooth sensors. they can't sense direction (hurray, hurray!)! so, instead of plugging into port 11, plug into port 1