Encoders not changing...
 

i implemented the encoder file from Kevin's site... but it doesn't work. I plugged it in to what it said, and i update it with:
what could my problem be?

Re: Encoders not changing...
 

what other code is being implemented are you using the camera?...GTS?...timers?...other sensors?

make sure the encoder outputs are plugged into the correct inputs.

make sure you are using the right type of encoder, I believe that kevin watson has his code set up for a quadrature encoder.

also make sure that you call all the right functions in the right places ie. encoder_counter() in Interrupt_Vector_low(), encoder1_init() in user_init().

another problem that happened to me was overlapping interrupts. If you do a "find in project" for a bit in the register to see if they are used anywhere else, you may eliminate this problem.

Re: Encoders not changing...
 

Did you follow the steps in the readme that came with the encode code.. such as adding the initialization call?

Re: Encoders not changing...
 

i did follow the steps in the initialization. i am also using the camera. I'll check the encoder type. Where do i find what kind they are exactly? I do call Initialize_encoders() in initialization, and i call interupt handler low from Default routine.

Re: Encoders not changing...
 

Don't do that.

The interrupt handler is "called" by a hardware feature of the processor. You don't have to do anything more than define it as the interrupt handler.

Re: Encoders not changing...
 

k thanks... still haven't gotten a chance to test again

EDIT: nope, still doesn't work...

Re: Encoders not changing...
 

How do you know the encoders are not changing? Are you simply trying to print your xxxxWheelCount variables to a terminal and noticed they don't change?
If so, then that's likely the only problem and your encoders are just fine. Your variables are probably declared long int and, as such, you need to typecast them before printing. Try the following:

and see if it works. Sometimes the simple things really get on your way!

Re: Encoders not changing...
 

actually, they're not longs. they're ints. a long can hold up to 2147483648, which is about a mile. i just used ints. they're printed using
But it's a good point. i'll try printing the values directly from the method...

Re: Encoders not changing...
 

did anyone have to change their encoder code to get it working? what did you do? cuz ours still isn't working

Re: Encoders not changing...
 

I tossed a USB flash drive containing Kevin Watson's frc_encoder.zip file to the lead student programmer and told him to follow the directions in encoder_readme.txt. He did the nine required steps and compiled it. I added a tiny bit of code in Process_Data_From_Local_IO() to turn the raw encoder counts into odometer and heading information, and put a printf statement in Process_Data_From_Master_uP() to verify the proper operation of the encoders.

That's it. It was painless.

Re: Encoders not changing...
 

does the type of encoder affect the code? where did you guys get your encoders?

Re: Encoders not changing...
 

The code is designed to work with any encoder having a quadrature output. That means there are two signals, each producing a square wave signal as the shaft turns, but the A and B signals are a quarter-cycle out of phase with each other.

We're using US Digital's E4P encoders. http://www.usdigital.com/products/e4p/index.shtml
I believe we bought them from Newark Electronics, but I'm not the one who purchased them, and I'm not certain.

Re: Encoders not changing...
 

would the number of clicks per revolution make it more or less likely to work? because ours runs at 128 clicks per revolution, and some are concerned that that's too fast for the RC to detect

Re: Encoders not changing...
 

Make sure the encoders are wired right. You can leave the power pins plugged in and look at the signal wires with an oscilloscope or multimeter. If they change as you rotate the wheel, the problem is in the program. If not, there's an electrical problem.

Re: Encoders not changing...
 

k thanks, we'll try that