Can PBP read optical encoder damn fast? :)

[CuriousOne]

Yes I checked that PIC datasheet already, but I don't see any ways to implement it in PBP, we don't have statement for encoder reading, like we have for LCDOUT or OWIN.

[CuriousOne]

I've modified my code and it works ok, but sometimes I get false readings too - say for 20 pulses of CW, I will have 2-3 pulses of CCW and vise versa

STATE: 'WAIT FOR ENCODER TO BE MOVED (STATE CHANGE)
'Lcdout $Fe, $1, "WAIT..." , DEC ENX, " ", DEC ENY
X=ENX
Y=ENY
PAUSE 1
X1=ENX
Y1=ENY
IF X<>X1 OR Y<>Y1 THEN GOTO SOMELOOP
GOTO STATE


SOMELOOP: 'COUNTER LOOP FOR PULSE LENGTH COUNTING
IF ENX=1 THEN X1IN=X1IN+1 'X INCREMENT
IF ENY=1 THEN Y1IN=Y1IN+1 'Y INCREMENT
IF ENX=0 and ENY=0 THEN GOTO ANALYZE 'EXIT AND COMPARE LENGTHS
PAUSE 1
GOTO SOMELOOP


ANALYZE: 'DETERMINE DIRECTION AND INCREMENT CORRESPONDING VARIABLE
IF X1IN>Y1IN THEN 
CCW=CCW+1
ELSE
CW=CW+1
ENDIF
LCDOUT $FE, $1, "RAW", DEC Y1IN, "  ", DEC X1IN, "  "
LCDOUT $FE, $C0, "VAL ", DEC CCW, "  ", DEC CW, "  "
PAUSE 1
X1IN=0 'RESET VARIABLES
Y1IN=0 
GOTO STATE

[CuriousOne]

This is simple 3 pin incremental encoder, middle pin is tied to VCC, A and B are tied to PORTB.3 PORTB.4, which are also pull down with 10K resistors. If I rotate shaft slowly, then no false readings. What can be reason, some wiring issue or code inefficiency?

[Ioannis]

This is simple 3 pin incremental encoder, middle pin is tied to VCC, A and B are tied to PORTB.3 PORTB.4, which are also pull down with 10K resistors. If I rotate shaft slowly, then no false readings. What can be reason, some wiring issue or code inefficiency?

Well, your LCD may be slowing down the response. And since you use PAUSE and LCDOUT it is expected that program is not the most efficient. The encoder is best done in ISR and even better using hardware module when available.

Ioannis

[CuriousOne]

I don't see how to avoid use of pause statement. We have time changing, things are happening within time, so how not to consider time? In final device, there will be no LCDOUT, if that is the problem.

[Ioannis]

ISR then.

Ioannis

[HenrikOlsson]

If the encoder strip has 60 lines per cm then you can get a resolution of 240 counts per cm by counting all four edges of the quadrature cycle.

If you're OK with 60 it makes it a lot easier (compared to 4x decoding) since, again, all you need to do is poll channel B on the rising edge of channel A and you have your count direction. Using a coupe of external NAND gates (or perhaps the CLC module if your PIC has one) you can decode that into two discrete signals, up & down. Feed those into two counters on they'll count for you while you PAUSE.

If counting with software, polling the inputs, then using PAUSE, LCDOUT or any other command that takes longer to execute than the shortest time between two pulses WILL ruin the day - in which case resorting to interrupts or hardware counter is the only way. This is why I asked if the the counting should go on WHILE outputting to the DDS.

/Henrik.

[Ioannis]

Yes I checked that PIC datasheet already, but I don't see any ways to implement it in PBP, we don't have statement for encoder reading, like we have for LCDOUT or OWIN.

What stops you from writing directly to the registers?

Ioannis