Phase A and Phase B on encoders

[kiettyyyy]

Hey all!

I've been looking through Kevin Watson's encoder code on his website (http://www.kevin.org/frc/). I'm trying to learn about how to make these things work, but I do know that there are two connections to the encoders. A phase A and phase B. I only saw references to phase B inside the code like pinouts to the digital inputs on 11 to ???. Where would the phase A connectors go? And why arn't they in the code? Maybe its in some file that I wouldnt know??

Thanks!

[Mike]

Phase A would be connected to the appropriate interrupt. Kevin's code is set to interrupt on a low to high logical change of phase A, which will indicate that the wheel is turning. Once you know that the wheel is turning, you can read phase B to find out in which direction it is going.

[Tom Bottiglieri]

Originally Posted by Mike

Phase A would be connected to the appropriate interrupt. Kevin's code is set to interrupt on a low to high logical change of phase A, which will indicate that the wheel is turning. Once you know that the wheel is turning, you can read phase B to find out in which direction it is going.

Unless you are using interrupts 3-6, which are triggered on any change in state by default.

[kiettyyyy]

Ohh I see.. So if I wanted to have Encoder1 on digital i/o #1 and #2, and Encoder2 on digital i/o #3 and #4.. I would set...

	#ifdef ENABLE_ENCODER_1

	// make sure interrupt 1 is configured as an input
	TRISBbits.TRISB2 = 1;

	// interrupt 1 is low priority
	INTCON3bits.INT2IP = 0;

	// trigger on rising edge
	INTCON2bits.INTEDG2 = 1;

	// make sure the interrupt flag is reset before enabling
	INTCON3bits.INT2IF = 0;

	// enable interrupt 1
	INTCON3bits.INT2IE = 1;
	#endif

	// if enabled in encoder.h, configure encoder 2's interrupt input
	#ifdef ENABLE_ENCODER_2

	// make sure interrupt 2 is configured as an input
	TRISBbits.TRISB4 = 1;

	// interrupt 2 is low priority
	INTCON2bits.INT4IP = 0;

	// trigger on rising edge
	INTCON2bits.INTEDG4 = 1;

	// make sure the interrupt flag is reset before enabling
	INTCON3bits.INT4IF = 0;

	// enable interrupt 2
	INTCON3bits.INT4IE = 1;
	#endif

and change the Phase B inputs in encoder.h

#define ENCODER_1_PHASE_B_PIN	rc_dig_in02
#define ENCODER_2_PHASE_B_PIN	rc_dig_in04

// Encoder 3 to 6 is not defined in encoder.c
#define ENCODER_3_PHASE_B_PIN	rc_dig_in13
#define ENCODER_4_PHASE_B_PIN	rc_dig_in14
#define ENCODER_5_PHASE_B_PIN	rc_dig_in15
#define ENCODER_6_PHASE_B_PIN	rc_dig_in16

If you see any problems in this code, let me know because I am also learning

Thanks every body!

[Joe Ross]

Originally Posted by kiettyyyy

Ohh I see.. So if I wanted to have Encoder1 on digital i/o #1 and #2, and Encoder2 on digital i/o #3 and #4.. I would set...

If you see any problems in this code, let me know because I am also learning

Thanks every body!

You should not change anything in encoder.c.

It would be better to assign the Phase-B pins to not be on an interrupt pin (ie digital inputs 1-6).

I'd suggest reading Kevin's encoder_readme.txt about the differences between the different ways encoders 1&2, 3&4, and 5&6 are implemented. Because of those differences, it would be best to keep both encoders on similar channels.

[Alan Anderson]

Originally Posted by kiettyyyy

Ohh I see.. So if I wanted to have Encoder1 on digital i/o #1 and #2, and Encoder2 on digital i/o #3 and #4...

You don't want to use those inputs that way. It'll make the interrupt routine a lot more complicated than it needs to be.

Digital inputs 1 and 2 are the "natural" ones to use for Phase A of a pair of encoders. They can be set to cause separate interrupts on either a low-to-high or high-to-low transition of the signal. Inputs 3-6 are able to cause interrupts as well, but they all share the same interrupt bit in the processor, and they will trigger the interrupt on both rising and falling edges. The Phase B lines don't need to be connected to interrupt-capable inputs, and should generally go to input 7 or higher.

[kiettyyyy]

So I should just scrap the entire idea of moving the interupts from #1 and 2 . It might just be easier to use the normal interupt pins..

[Mike Betts]

What Alan is saying is to attach:

Encoder #1 Phase A to Digital Input #1
Encoder #2 Phase A to Digital Input #2
Encoder #1 Phase B to Digital Input #7
Encoder #2 Phase B to Digital Input #8

And I completely agree. This is the most efficient use of pin assignments.

Regards,

Mike

[gburlison]

We are having problems with our Autonomous code. It seems that we bought 100 count quadrature encoders because we did not want to over load the processor with interrupts, but we dont get enough counts per program loop unless we are going nearly full speed. After reading some of the info about interrupts it seems that we can use different digital I/O pins and trigger on the rising and falling edge of our pulse to effectively double the amount of counts we get per program loop.

Can we also connect the 'B' side of the encoder to an interrupt and effectively quadruple the amount of precision by counting the rising and falling edges of both the 'A' & 'B' channel of the encoder?

Would this be any different than multiplying the single channel count by '4'?

[Phalanx]

You may also want to donwload and read this whitepaper on using quadrature encoders. We found it very helpful, insightful, and should help you understand the workings better.

http://www.chiefdelphi.com/media/papers/1490

[kiettyyyy]

Thanks for all the help everyone! The encoders work perfect ..... just having another problem now.. I made a new post on the programming forum regarding the camera + encoder

[Mark McLeod]

Originally Posted by gburlison

Can we also connect the 'B' side of the encoder to an interrupt and effectively quadruple the amount of precision by counting the rising and falling edges of both the 'A' & 'B' channel of the encoder?

Would this be any different than multiplying the single channel count by '4'?

The quick answer is yes, it's as you describe - more interrupts = more resolution per revolution.

Multiplying the existing count of the rising A interrupt by 4 doesn't tell you the encoder has moved further, it only changes the units it's expressed in. That's like multiplying your salary by 100 - okay, you then know how much you made in pennies, but it doesn't let you buy more stuff than you could before. Each actual interrupt you see tells you the encoder has absolutely, positively moved. Extra interrupts are more like extra dollars in your salary - always a nice thing .

The complexity of your interrupt hander code goes up to correctly interpret the order of the additional interrupts, so you keep track (state machine style) of whether the encoder is rotating forwards vs backwards and when it jitters or changes direction.
E.g., if the A line rises then falls again before the B line changes (either up or down) then you've reversed direction. Or an A fall followed by a B rise is the opposite of an A fall followed by a B fall. You have to know if you should be adding or subtracting encoder counts.