Reading a rotary encoder
fma38
Posts: 42
For my first attempt to program a BS2 (px), I started with a rotary encoder, which I plan to use for my motorized panohead project.
I used the method described here:
http://www.desktopaviator.com/Articles/Rotary_Encoder/st_ap8.pdf
but it dos not work very well... When I turn the knob, I have false values (turning in CW gives me some CCW values; the same problem occurs in the other direction). It seems that the BS2 is not fast enough. Is it the case ? Or is it my program?
Rotary encoder connected to pin6 and 7...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Fr
I used the method described here:
http://www.desktopaviator.com/Articles/Rotary_Encoder/st_ap8.pdf
but it dos not work very well... When I turn the knob, I have false values (turning in CW gives me some CCW values; the same problem occurs in the other direction). It seems that the BS2 is not fast enough. Is it the case ? Or is it my program?
Rotary encoder connected to pin6 and 7...
' {$STAMP BS2px} ' {$PBASIC 2.5} old VAR Nib new VAR Nib Init: old = INB Main: new = INB IF new = old THEN Main IF old.BIT3 ^ new.BIT2 = 0 THEN CCW CW: DEBUG CR, "DEBUG: CW" GOTO Cont CCW: DEBUG CR, "DEBUG: CCW" Cont: old = new GOTO Main
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Fr
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
My encoder is not continuous, but has some 'clicks'. At a click position, outputs pins are not connected to the common pin. And between 2 clicks, it seems that there are 4 transitions...
So, I divided the count value by 4, and it works better. I get one increment per click, and much less wrong values (except when I turn it very fast). Maybe without the DEBUG command, things will work better.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Fr
www.emesys.com/BS2fsm.htm#twobit
The code you posted is slowed down terrifically by the DEBUG statements. If you want a faster indication, install leds on a couple of pins, say red for CCW, green for CW.
It is true that the Stamp might not be fast enough, when you are able to spin the control fast by hand. The processor does have to catch every single transition of state, or else it will report incorrectly. Even if you remove the DEBUGs, there might be other code that you need this system to execute. The encoder counting might have to be offloaded to a peripheral chip, like an SX chip dedicated to position encoding, or run on a Propeller that can dedicate a whole cog to the encoder and keep up an any speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I should have mentioned that the DEBUG statements are only there to show the proof of concept. Using this code with several projects there are no DEBUG statements, although they are all BS2p or BS2px-based projects. Even then turning the knob extremely fast results in lost counts. But in the applications they’re in I think the BS2p and BS2px are quite suitable. It really depends on how many pulses/revolution the encoder has too. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
www.lsicsi.com/pdfs/LS7366.pdf
But if I can avoid it...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Fr
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
I found an other nice circuit to decode quadrature encoders:
www.lsicsi.com/pdfs/Data_Sheets/LS7083_LS7084.pdf
I guess the second one is better, because it provides pulses and direction. With both, even if you miss a pulse, it does not go back!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Fr
Thanks,
Russ
The code mentions it works on the BS2 before mentioning the other BASIC Stamp Models. I guess I should have said 'also' works on...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support