Witam
Usiłuję napisać kod dla ATmegi88 obsługującej silnik i encoder zamontowany na wale silnika. Encoder ma 400 impulsów na obrót a silnik rozkręca się do max 4800obr/min.
Całość ma być serwem sterowanym z zewnątrz przez USART. Jakiś czas temu mierzyłem się już z podobnym problemem, ale poległem. Nie mogłem napisać nic działającego i z upływem czasu zniechęcenie wzięło górę. Teraz znowu mnie naszło i z nowymi pomysłami i zapałem próbuje ogarnąć temat. Niestety encoder dalej jest dla mnie problematyczny. Napisałem sterowanie przez PWM z timera0 silnikiem (to działa), mam komunikację z terminalem do wyświetlania impulsów(też działa), encoder wyjściem A podłączyłem do wejścia timera1 PD5 i wysyłając stan licznika na terminal widzę, że też działa, tzn zlicza impulsy, ale tylko w górę. Tu pytanie, jak to zrobić żeby zliczać impulsy w górę i w dół? Chciałem jakoś badać stan wyjścia B encodera, które jest przesunięte względem A, ale jak?
Myślałem nad wykorzystaniem przerwania INT0 lub INT1 w którym w momencie wystąpienia badałbym wyjście B, ale impulsy z encodera mogą pojawiać się max co ok. 31u sekund więc angażowanie procesora tak często do obsługi przerwania i jeszcze badanie w tym przerwaniu czy pin jest w stanie wysokim lub niskim, chyba nie jest dobre (tak mi się przynajmniej wydaję). Procesor ma jeszcze inne rzeczy do zrobienia więc wydaje mi się, że to złe rozwiązanie. Timer2 generuje mi takty dla timera programowego, timer0 jak napisałem wcześniej zajmuje się PWM-em, więc został mi timer1. Jak to ogarnąć. W internecie jest sporo o encoderach, ale większość dotyczy encoderów ręcznych, natomiast o optycznych z silnikiem jest nie za wiele, a przynajmniej nie znalazłem dla siebie odpowiedzi.
Elektrycznie wszystko działa, sprawdzałem na oscyloskopie i widać dwa przebiegi z encodera, zresztą jak wcześniej wspomniałem na terminalu ma ładnie pokazany przyrost licznika T1, niestety tylko przyrost.

Witam
Przyjrzyj się przebiegom na oscyloskopie albo nawet mierniku.
Są przesunięte tworząc sekwencję. Parami np. ( stan_wyjścia_A , stan_wyjścia_B).
obracając w jedną stronę (0,0) dalej (1,0)-->(1,1)-->(0,1)-->(0,0)
a w przeciwną odwrotnie.
zauważ że np. po (1,1) będzie albo (1,0) albo (0,1) a po (0,1) będzie (0,0) albo (1,1) ,zależy w którą stronę kręcisz.
Więc to wykorzystaj w kodzie licznik++; else

pozdrawiam

Wiem, o tym co napisałeś, ale nie wiem jak to wykorzystać w kodzie. W tej chwili, jak napisałem wcześniej zliczam impulsy timerem1, nie wiem jak mogę zmieniać kierunek zliczania zależnie od kierunku obrotu. Jak to "wychodzi" z encodera to wiem (to o czym napisałeś) zresztą bardzo ładnie to widać na oscyloskopie 2-u kanałowym. Powiedz mi tylko jak tą właściwość wykorzystać w praktyce. Licznik timera1 zlicza autonomicznie podawane impulsy na swoje wejście T1 i nie mogę nic przestawić, chyba że mogę tylko nie wiem jak. Oczywiście nie upieram się, że tak musi być jak zrobiłem, chętnie dowiem się jak to zrobić inaczej. Na razie zrobiłem tak jak wyżej chociażby po to żeby sprawdzić elektrycznie czy wszystko gra.

Ja uwazam ze takie rzeczy jak te to wlasnie granica gdzie juz nie nalezy stosowac tych biednych avr a postawic nawet na jakis najmniejszy stm32 przykladowo f030 kosztuje 4zl a ma timer z sprzetowym zliczaniem impulsow z enkodera, dzieki czemu procek tylko czyta jeden rejestr i wynik na tacy.

Tutaj maksymalna czestotliwosc to 32 kHz ale z jednego kanalu wiec na atmedze bedzie to bardzo trudne do zrobienia.

_________________
sig off ;(

Od jakiegoś czasu zaczynam podzielać Twój pogląd, tylko że nic a nic o ARM-ach nie wiem. Czekam aż Mirek napisze kolejną książkę, tym razem o ARM-ach.

Zastanawia mnie co to za silnik DC masz, który potrafi się wałem ustawić na jednej z 400 pozycji... Zastanów się czy potrzebna ci tak naprawdę tak wysoka precyzja enkodera. Może wystarczy dzielnik zrobić sprzętowy aby ograniczyć impulsowanie, to raz. Dwa to - czy potrzeba badać sygnał kierunkowo (czyli przesunięte impulsy)? W wielu sytuacjach jest to kompletnie nie uzasadnione i niepotrzebne, bo przecież uruchamiając motor program wie, w którą stronę rusza wałem, a więc wystarczy tylko liczyć ilość przybywających impulsów tyle, że w przerwaniu (to ważne!), bo wtedy nawet po odłączeniu napięcia silnik posiada bezwładność i parę impulsów doliczy do kierunku, w którym ostatni się obracał.

_________________
http://www.sylwekkuna.com

ad1)
Trochę się nie zrozumieliśmy. Ja takiej rozdzielczości nie potrzebuję, po prostu mam taki encoder z silnikiem. Encoder ma rozdzielczość 400 impulsów na obrót i nic z tym nie zrobię. Myślałem nad zmniejszaniem/podzieleniem ilości impulsów, ale chciałbym wreszcie ogarnąć temat z encoderami dla tego nie chcę stosować półśrodków. Jak wspomniałem wcześniej robiłem już podejście do tego tematu. Miałem wtedy silnik z encoderem 500 impulsów na obrót, silnik rozkręcał się do 6000 obr/min i nie udało mi się tego ogarnąć. Mam też drugi silnik (dla prób na biurku) i ten ma 100 impulsów na obrót. To nie o to chodzi, że potrzebuję tak wysoka rozdzielczość, jak wspomniałem po prostu mam taki encoder i takie silniki a jak mówią "darowanemu koniowi w zęby się nie zagląda".
ad2)
Spodziewałem się tego pytania . Muszę badać kierunek obrotu ośki encodera. Silnik napędza za pośrednictwem niewielkiej przekładni spore ramię, coś w stylu odwróconego wahadła, Na pewno może się zdarzyć sytuacja, że ramie poruszy silnikiem przestawiając ośkę. Silniki są dwa i z założenia maja pracować zależnie/synchronicznie, ale nie, nie jest to SEGWAY . Dla tego muszę kontrolować i korygować położenie również w sytuacji gdy mikrokontroler nie porusza silnikiem(nie ma rozkazu ruchu). Gdyby mogło być tak jak mówisz miałbym problem rozwiązany. Inna rzecz to, że taka metoda jaką proponujesz to nie jest sprzężenie zwrotne, to będzie działać mniej więcej jak silnik krokowy który ma wykonać ileś tam kroków ale czy je wykonał to tego mikrokontroler nie wie. Bazując na tym co napisałem to te 400 impulsów jest całkiem dobrą rozdzielczością więc chyba nie jest dobrym pomysłem zmniejszanie rozdzielczości.

No to przynajmniej wiemy już o co chodzi. W sytuacji, o której piszesz faktycznie potrzeba dokładności rozpoznawania kierunku. Możesz mieć problem z prędkością małych avr'ków. Można bhy jeszcze wstawić pośrednuka na jakimś tiny13, który zajmie się enkoderem, i do głownego procka będzie wysyłał gotowe impulsy na dwóch pinach - jeden pin lewo, drugi prawo. Ja tak zrobiłem w jednym z projektów gdzie czasy przerwań miałem trochę wyśrubowane.

_________________
http://www.sylwekkuna.com

Kurcze, ale widzę na Youtube że ludzie budują "servomotory" na AVR i to działa! Niestety nie dostałem się do kodów żeby podpatrzeć jak to jest zrobione.
Na start chciałbym uruchomić chociaż ten testowy "na biurku" gdzie mam 100 impulsów, zobaczyć jak to ruszyć. Nie chce mi się wierzyć, że się nie da na pewno jest to do ogarnięcia tylko się źle za to zabieram.

No chyba inaczej nie da się obsłużyć enkodera, bo jak? Tak jak mówisz - dajesz sygnał A na przerwanie, np. na zbocze narastające. W momencie wystąpienia przerwania badasz stan wyjścia B - jak jest niski, to znaczy że kręci się w jedną stronę, jak wysoki to w drugą. Chyba tylko tak można określić kierunek.

Tak zoom, ale wydaje mi się, że nie moge tego zrobić w przerwaniu INT0 lub INT1 bo zapcham procesor obsługą tylko przerwania.

Panowie, ładowanie attiny13 a może jeszcze drugiego do czegoś innego - to nie kierunek. Co do STmek czy LPC to o ile ktoś wie jak działa dane peryferie nie trzeba nawet przeglądać wykresów itp. od razu przechodzimy do rejestrów. W końcu na ile sposobów można przedstawić wykres SPI, a peryferia jak np. timery mają pełna listę kroków co zrobić aby odpalić go w danym trybie. Jeżeli ktoś potrafi obsłużyć GPIO w AVR zrobi to samo na arm, i już na samych gpio zobaczy jakie one mają fajne funkcje.
Nie mówię żeby od razu na dma się porywać czy usb, ale rejestry SPI, I2C, USART są bardzo podobne do AVR
No i nie rzucać się od razu jak pies na mięso na f4 czy f7, bo niby cena podobna a zegar kilkukrotnie większy, ale rzeczywiście można tam się na samym początku już na zegarach pogubić. Ale F0/L0 czy F1/L1 to pikusie z paroma rejestrami

_________________
sig off ;(

Tom277. Chodzi tylko o to, że gdy się silnik kręci w prawo to dodaje impulsy do licznika, a gdy się kręci w lewo to nie odejmuje, a nadal dodaje, czy jak? Wydaje mi się, że na jednym wejściu tego nie da się opanować. Po to enkodery mają dwa wyjścia aby obydwa podłączyć, w dodatku są takie sterowniki których jedynym zadaniem jest pilnowanie tego by stan z enkoderów był zgodny ze stanem zadanym nawet gdy są siły zewnętrzne które mają ochotę to zmienić a więc podglądanie jak to działa trzeba rozpocząć od strony sprzętowej.

http://www.elektroda.pl/rtvforum/topic2659141.html

Tak o to chodzi. Encoder ma dwa wyjścia i jaki przebieg z nich mam to wiem, ale nie wiem jak to liczyć procesorem w górę i w dół.

To na jednym sygnale się nie da, podglądałeś tamten projekt?

Jest jeszcze inny czysto programowy i o to samo chodzi.

http://sheepdogguides.com/arduino/FA1updwn.htm

Jeszcze podgląd na ten wynik liczenia to ma być na wyświetlaczu czy jak, bo podałeś informację "mam komunikację z terminalem do wyświetlania impulsów(też działa)", ale co masz na myśli to można się tylko domyślać, że może to okienko w programie, niestety nie wiem jakim, albo nie wiem nic.

Wynik wysyłam na terminal po RS-sie, ale tylko podczas testów, chciałem podpatrzeć jakie wyniki mam z encodera i czy jest "po mojej myśli". W docelowym układzie RS-a będę wykorzystywał do innych celów.
Jakiś czas temu trafiłem na projekt tej frezarki, musiałbym jeszcze raz się temu przyjrzeć, tym razem pod kątem serwomotorów.