Atmega8 - enkoder obrotowy jako licznik w górę i w dół

Witam
Kupiłem ostatnio na allegro kilka sztuk

enkoderów obrotowych NONAME. Pierwszy raz mam styczność z takim czymś jak enkoder dlatego najpierw chciałem napisać program bez jakichkolwiek przerwań czy funkcji zwracających wartości oraz zanian z kodu Grey-a na binarny.

Podłączyłem to w taki schemat

i sugerując się przebiegami

napisałem taki program:


Wcześniej gdy nie dawałem _delay_ms() wogóle były problemy ze zliczaniem
Myślałem, że enkoder ma ustalone swoje stany i nie występują żadne stany przejściowe, ale po problemach sprawdziłem na oscyloskopie (działka na 50ms)

że każde przekręcenie to impuls, po którym następuje powrót do poprzedniego stanu. Niestety mam oscyloskop jednokanałowy i nie mogę zobaczyć przesunięcie w fazie na dwóch wejściach do enkodera.
Okazuje się też, że przy powolnym przekręceniu gałki impuls ten wydłuża się i to znacznie

jak trzymam ją w pozycji pomiędzy jednym a drugim skokiem impuls utrzymuje się cały czas. Czy to normalne? Enkoder kosztował 2,80zł, czy w tych droższych impulsy są płynne?
Jak dodałem funkcję _delay_ms(100) tak jak w programie powyżej już jest trochę lepiej, ale nie mogę w ten sposób wykonywać szybkich obrotów i dalej występuje coś takiego:

gdzie te migania (oczywiście z T=100ms) i przeskoki występują podczas powolnego przekręcania gałki. Najpierw przekręcałem w prawo, a potem w lewo. Jak widać licznik jako tako działa, ale chciałbym się zapytać czy można jakoś zmienić program, żeby wyeliminować ten problem?
Problemem jest chyba to, że przez przy powolnym kręceniu może zostać odczytany błędny stan.

Enkoder to mechanicznie zwykły przycisk. Ma też wszystkie wady przycisku, czyli np. drgania styków. Wiele enkoderów na jeden "przeskok" generuje 2-4 impulsów i oczywiście czasy trwania poszczególnych faz zależą od szybkości kręcenia. Przejrzyj darmowe przykłady do książek w mojej stopce - masz tam przykłady obsługi enkoderów w oparciu o ATMega i XMEGA.

Twojego programu nie analizowałem, nie chciało mi się, albowiem od razu Ci powiem, że ja bez przerwań w ogóle bym się za to nie zabierał i dotyczy to nie tylko enkodera ale także zwykłych przycisków. Tak jak napisał tmf, każdy zestyk ma tendencję do drgań, a więc enkoder również, jest to opisane w książce Pieńkosa i Turczyńskiego "Układy scalone TTL w systemach cyfrowych" w rozdziale 4.8.4. "Układy współdziałające z zestykami" (no chyba masz tą książkę, he?). Ilość i czas trwania tych drgań zależy nie tylko od rodzaju przycisku ale także od jego stanu (zmęczenia sprężyny, starości, stopnia zabrudzenia), a więc może się zmieniać w czasie, dlatego trudno jest znaleźć skuteczną metodę do odfiltrowania tych "stanów przejściowych", przy której przycisk będzie pewnie reagował na szybkie naciśnięcia. Jest to szczególnie istotne w przypadku enkodera, dlatego dodawanie kondensatorów o pojemności aż 100nF nie jest dobrym sposobem.

Odwal te kondensatory i czytaj stany obu wyjść enkodera bezpośrednio. Wykorzystaj cykliczne przerwanie od timera, powiedzmy co 1-5ms, które będzie próbkowało (czytało) obydwa wyjścia i zliczało ilość zer lub jedynek następujących po sobie zanim wykryje zmianę stanu wyjścia. To można zrealizować jako prostą maszynę stanów, posiadającą jedynie licznik oraz dwa stany: LO i HI. W stanie LO zakłada się, że na wyjściu enkodera (przycisku) jest i jak dotąd było zero, i jeżeli czyta się zero z enkodera to licznik się kasuje, a jeżeli jedynkę to się go inkrementuje i sprawdza, czy osiągnięto próg, czyli wymaganą ilość jedynek następujących po sobie. Jeżeli próg został osiągnięty (np. 3) to zakłada się, że stan enkodera/przycisku jest już stabilny i więcej drgań nie będzie i wówczas zmienia się stan na HI. Dla ilustracji w sekwencji 0000010110111111 licznik zliczyłby pierwszą jedynkę ale zero (od drgań) zaraz skasowałoby go, następnie licznik zliczyłby 2 jedynki ale znów zostałby skasowany przez zero i dopiero po trzech następnych jedynkach licznik zliczyłby do 3, próg zostałby osiągnięty i nastąpiłoby przejście do stanu HI, czyli wykrytoby stabilną jedynkę na wyjściu enkodera. Jest to w zasadzie rodzaj prymitywnego filtru dolnoprzepustowego, który eliminuje krótkie "trzaski" kosztem wprowadzenia pewnego opóźnienia, które w tym przypadku wynosi minimum 3 razy okres próbkowania.

W stanie HI postępowanie jest takie samo, tylko zamiast jedynek zliczane są zera. Zamiast licznika można użyć rejestru przesuwnego (w sensie instrukcji mikroprocesora) i przed zmianą stanu sprawdzać czy rejestr zawiera identyczne bity w swojej młodszej czy starszej części (w zależności od tego czy przesuwa się w lewo czy w prawo). W przypadku rejestru 8-bitowego próg oczywiście nie może być większy niż 8, ale w praktyce stosuje się jeszcze mniejsze wartości, więc to nie przeszkadza.

Dopiero dysponując czystymi od drgań stanami HI i LO obu wyjść enkodera można interpretować jego przeskok w lewo lub w prawo. Jeżeli zrobi się to w tym samym przerwaniu z jednoczesnym zliczaniem przeskoków, ryzyko, że przeskok z jakiegoś powodu zostanie "przeoczony" przez główny program, będzie wyeliminowane.

... a dodatkowo zobacz co najmniej końcówkę od 1min 30 sek, a najlepiej całość:



Link

Należy zrobić 2 czynności:

1. Usunąć te kondensatory 100n wydłużające czas ustalania stanu układu,

2. Zaprogramować timer na przerwania co około 2.5ms (~400Hz) i w nich odczytywać stan wejść A, B nie zawracając sobie głowy drganiami styków. Sygnał A używamy do wykrycia stanu zwarcia, wówczas sygnał B odczytujemy do ustalenia kierunku obrotu enkodera.

Pzdr

He he, tak książkę mam i na pewno za jakiś czas przerobię rozdział 4.8.4
A wracając do tematu, to najpierw zrobiłem taki licznik dla stanu LO i HI jak radziłeś kspor, ale ostatecznie po sprawdzeniu tego co napisał PDT widząc, że działa bez jakichkolwiek pomyłek zostałem przy tym założeniu, że pominę drgania styków.


Aż się zdziwiłem, że tak prosto można to napisać, że jeden kanał wykorzystywany jest do wykrywania kręcenia, a drugi w tym samym czasie mówi w którą stronę następuje przekręcenie. No fajnie, kolejna mała rzecz opanowana.

Dzięki za pomoc Panowie

Nie ciesz się tak bardzo, bo rzecz wcale jeszcze nie jest całkiem opanowana, wszystko zależy od rodzaju enkodera obrotowego. A jak się okazuje są ich przynajmniej dwa rodzaje: takie, które podczas jednego przeskoku grzechotki wykonują cały cykl złożony z czterech faz jak na rysunku z Twojego pierwszego postu, oraz takie, które przechodzą tylko z jednej fazy na drugą.

Ten, który posiadasz, należy do pierwszego rodzaju i wówczas metoda opisana przez PDT działa. Przyznam się od razu, że nie wiedziałem, że są takie enkodery, chociaż jak się okazało, też mam takie w swoich zbiorach. A to dlatego, że jakieś 10 lat temu kupiłem sobie w Farnell enkoder ECWJ-B24-AC0006 firmy Bourns z 24 przeskokami na obrót, dający tylko 6 pełnych cykli na obrót, czyli jedną zmianę fazy na przeskok. Wtedy enkodery obrotowe nie były jeszcze tak tanie i łatwe do dostania jak obecnie (ECWJ-B24 kosztował chyba jakieś 10 Euro), więc przejrzałem sporo kart katalogowych zanim zdecydowałem się na zakup i widocznie doszedłem wówczas do przekonania, że wszystkie enkodery potrzebują czterech przeskoków na pełen cykl. Albo coś przegapiłem, albo coś się zmieniło, ale zbadałem teraz enkodery PEC11-4220F kupione na Allegro i rzeczywiście zachowują się tak jak te Twoje, czyli wykonują pełny cykl co każdy przeskok. W takim przypadku metoda PDT jest dobra, ale w przypadku ECWJ-B24 już nie, gdyż przeskoki będą ewidentnie gubione.

Jakby tego było mało zdarzają się jeszcze inne enkodery obrotowe. Wiem, bo wraz z ECWJ-B24 kupiłem też sobie miniaturowy enkoder z ośką Φ3.18 typu 3315C-1-006: ENCODER 6 CYCLES (napis z opakowania, chyba także Bourns), czyli również wykonujący 6 cykli na obrót, ale obracający się płynnie bez przeskoków. Obawiam się, że bez grzechotki, która wymusza określone położenia ośki, taki enkoder może zostać przypadkowo ustawiony na granicy kontaktowania lub być obracany bardzo wolno i wówczas bez eliminacji drgań styków, którą PDT pominął, może dojść do łapania fałszywych zmian ustawienia.

Istotnie są enkodery, które generują pojedyncze przejścia, albo całe cykle, lecz w praktyce nie ma to znaczenia i metoda opisana przez @PDT sprawdzi się w obu przypadkach. Jedynie wynik należy podzielić przez 4 jeśli enkoder generuje pełen cykl/przejście. Jeśli przerwanie tak jak w przykłądzie jest generowane co 2,5ms to potencjalnie możemy wykryć 125 przejść na sekundę na jednej linii co wystarcza nawet przy szybkim kręceniu enkoderem. A jeśli zgubimy kroki, to cóż, przecież nic się nie stanie.
Można też użyć AVR ze sprzętowym enkoderem kwadraturowym (XMEGA), ale dla enkoderów mechanicznych o niewielkiej liczbie obrotów/s niewiele to daje.
Warto też zauważyć, że w przypadku enkodera drgania aż tak bardzo zazwyczaj nie przeszkadzają - po prostu odczytana pozycja będzie przeskakiwać przez kilka ms o +/-1 i nic więcej.

tmf wrote:

Istotnie są enkodery, które generują pojedyncze przejścia, albo całe cykle, lecz w praktyce nie ma to znaczenia i metoda opisana przez @PDT sprawdzi się w obu przypadkach. Jedynie wynik należy podzielić przez 4 jeśli enkoder generuje pełen cykl/przejście

No nie bardzo, przecież w enkoderze z pojedynczymi przejściami (to znaczy ze zmianami pojedynczych faz) nie przy każdym przeskoku następuje zmiana stanu wyjścia A z wysokiego na niski, tak jak chciał PDT. W takim przypadku pojedynczy przeskok (kliknięcie) mógłby nie odnieść żadnego skutku, a przy obracaniu w jedną stronę wykrywany byłby dopiero co czwarty przeskok. Ponadto nawet zakładając, że enkoder jest akurat w takiej pozycji, że pojedynczy przeskok wygenerowałby zmianę stanu wyjścia A z wysokiego na niski (np. zmiana fazy 4-->1 na rysunku powyżej) i zostałby wykryty, to pojedynczy przeskok wstecz już nie zostałby wykryty i żeby cofnąć zmianę należałoby zrobić jeszcze dwa dodatkowe skoki wstecz (zmiany fazy 1-->4-->3-->2). Byłoby to coś w rodzaju histerezy czy też luzu mechanicznego, na pewno nie do zaakceptowania.
To dzielenie przez 4 też jest bez sensu, bo przecież chodzi o to, by zliczać nie fazy a przeskoki, co właśnie robi metoda PDT, ale tylko w przypadku enkoderów generujących pełny cykl co każdy przeskok.

Zdaje się że mam podobne enkodery. One po prostu gubią kroki bo są kiepsko wykonane.
Ja napisałem sobie program który zliczał poszczególne kombinacje podczas kręcenia. I okazało się że niektóre występują bardzo rzadko. Przy kręceniu w odwrotną stronę już występują, za to nie występują inne. No to po prostu wywaliłem ich zliczanie i od tej pory działa dobrze (pomijając to że mam 2-krotnie zmniejszoną rozdzielczość).