need help for rotary encoder

[williamho]

Hi, I try someone's code to capture rotary encoder as below but
I will miss reading in fast mode.

Can anyone help?
Thanks.


#if defined(__PCH__)
#include <18F458.h>
#DEVICE ICD=TRUE
#fuses HS,NOWDT,NOPROTECT,NOLVP,PUT,BROWNOUT,NOCPD,WRT
#use delay(clock=20000000)
#use rs232(baud=19200, parity=N, bits=8, xmit=PIN_C6, rcv=PIN_C7,stream=COM_1) // Jumpers: 8 to 11, 7 to 12
#endif

#include <lcd.c>

signed int16 count;
#INT_EXT

void gisr()
{
//output_high(PIN_C1);
output_bit(PIN_C0,input(PIN_B4));
if(input(PIN_B4)==1)
++count;
else --count;
//printf("Count = \%04ld \r",count);
printf(lcd_putc,"\fk = %04ld",count);
//output_low(PIN_C1);
}

void main() {

lcd_init();
printf("\n\rready\n\r");

count=0;
set_tris_b(0xFF);
ext_int_edge(0,L_TO_H);
printf("\n\rCount = 0000\r");
enable_interrupts(INT_EXT);
enable_interrupts(GLOBAL);

}

[sseidman]

First, you need an infinite loop in main.

Next, take the printf statements out of your isr. Instead, set a change flag in the isr, and poll it in main, printing and resetting if it is set. Depending on how fast your encoder is moving, don't expect great printing performance. Also, if your encoder is really flying, you'll miss plenty of counts.

The better approach is to put two counters in a triggered mode, use a cheap us digital chip to provide an "up" pulse and a "down" pulse to the timers, use timer interrupt to periodically poll the counts and reset them. My own experience is that this method, too, can miss counts if things are really zipping along.

If your encoder is going real fast, and you're early in a design stage, I highly recommend moving over to a uc that directly handles quadrature, like the 18F4431, or 18f2331 (if you need less IO and memory). The problems you'll encounter without such a device are a tad detailed (search the archives for "quadrature" if you want a review), and can be overcome using a decoder chip like the hctl2020, but that's more expensive than moving to the right PIC, and the programming will be difficult, as well

Scott

Scott

[Thomas Blake]

You can turn quadrature signals into tach and true direction easily enough with a flip flop. The real problem with mechanical encoders is that switch bounce can break the quadrature relationship. In some applications this isn't a problem, in others it is. If you must have absolute monotonicity then you might want to interpret the quadrature pulses as Gray code (although it will change a lot faster when you turn the knob!).

[williamho]

Hi,
Thanks for your reply.

encoder 500 counts/rev at 1800 rpm is fast at average?

Thanks
William

[Ttelmah]

First, is the '500' figure, the encoder 'lines', or the encoder 'counts'. I suspect the former. A quadrature encoder, depending on how you decode it, can give up to four counts/line. Now others have pointed out that you must remove the printf from the encoder handler. The printf, just to actually 'output' the data, will take five character 'times', which at 19200bps, is about 2.5mSec. The rest of the interrupt handler, will take only a few dozen machine cycles, so this really is the part causing the main problem.
What is the circuitry attached between the encoder and the PIC?. The code you are using, looks as though it must have a partial 'decoder' present, otherwise the need to output a bit makes no sense.
As an example of just how fast the encoders can be handled:

[williamho]

Hi, thank for your reply.

I am try to use your code for my application as below:.


Changes that I have done :

set_tris_b(0x30);
new=input_b();
//new=portb;


// bchanged=0;

Total code become as below :-

#include <18F458.h>
#DEVICE ICD=TRUE
#fuses HS,NOWDT,NOPROTECT,NOLVP,PUT
#use delay(clock=40000000)
#use rs232(baud=9600, parity=N, bits=8, xmit=PIN_C6, rcv=PIN_C7,stream=COM_1) // Jumpers: 8 to 11, 7 to 12



#INT_RB
int16 position;

#int_global
void myint(void) {
static int old;
static int new;
static int value;
//Here I have an edge on one of the quadrature inputs
set_tris_b(0x30);
new=input_b();
//new=portb;
/*Now I have to decode the quadrature changes. There are four
possibilities:
I can have a rising or falling edge, on each of the two inputs. I have to
look at the state of the other bit, and increment/decrement according to
this. */
value=new^old;
//'value', now has the bit set, which has changed
if (value & 0x10) {
//Here the low bit has changed
if (new & 0x10) {
//Here a rising edge on A
if (new & 0x20) --position;
else ++position;
}
else {
//Here a falling edge on A
if (new & 0x20) ++position;
else --position;
}
}
else {
//Here the high bit (B) must have changed
if (new & 0x20) {
//Here a rising edge on B
if (new & 0x10) ++position;
else --position;
}
else {
//Here a falling edge on B
if (new & 0x10) --position;
else ++position;
}
}
old=new;
// bchanged=0;
#asm
//Here the 'fast' exit.
RETFIE 1
#ENDASM
}



void main()
{
signed int16 newcount=0;
printf("\n\rready\n\r");

enable_interrupts(INT_RB);
enable_interrupts(global);

do
{

if(newcount!=position){
newcount=position;
printf("\fcount = %5ld",newcount);

}


}while(TRUE);


}


result is only "ready" shown in screen.


I am using Omron optical encoder NPN output with 6 wires.

brown to +5v
blue to 0V
black (channel A) to B4
White (Channel B) to B5
Orange (channel Z) not use


I have been trying for 4 days trying to capture the rotary encoder but not working at all.
Someone recommended HCTL2020 or F4331.

[Ttelmah]

Get rid of the line saying #int_RB. This will bu&&er the code up completely.
The code replaces the _int global_ handler, and only supports the RB interrupt. If you have any other interrupts needed or specified, I can post a version that shows how to do this. You need INT_RB enabled, and INT_global enabled, but you _must not_ have an int_RB handler present.
If you want to use the input_b specification, then you _must_ have the line #use fast_io(B) present, or the compiler will add extra code to handle the TRIS, and will slow things down.
Do not set the TRIS in the interrupt handler. The port must already be set to have inputs on the two bits, or the interrupt will not trigger. Set the TRIS once at the start of main.
You _must_ have the bit definition for bchanged present, and this line _must_ be in the code. You have remmed it out.

Best Wishes

[Ttelmah]

I have put together a demo, which should show how it works:

[williamho]

Thanks, it works.

Why the origin of the encoder remain the same even I reset the PIC?
Just want to know and it is OK for that.

Thanks a lot.

[kender]

A have a problem with a rotary encoder skipping steps, and I want to solve it in hardware rather then frimware. I looked for HCTL2020, but couldn't find a place to buy them. Couldn't find the datasheet too.

Could you recommen where to look for these chips?

Thanks,
Nick

[PCM programmer]

[sseidman]

[sseidman]

[cybanical]

[Ttelmah]

The #bit, and #byte directives on CCS, allow you to define a pseudo variable, to access a specific address in the processor.
The addresses are in the data sheet.
They should be the same on all 18 family chips.
Using them for port I/O, is a bit of a 'left over'. On the current compiler, provided you have used fast_io, the standard 'input' command will work the same for reading the port. The equivalent command to access the whole port, would be "input_b()". In the past, the compiler was at times less well optimised, and this was the 'best' way to access the pins.
The 'bchanged' bit, accesses the interrupt flag set when the port bits have changed, and there isn't a 'standard' instruction to access this.

Best Wishes