Enkodery obrotowe

W dniu 2013-05-28 11:27, Stachu Chebel pisze:

Zdecydowanie źle pytasz. 3zł to rozsądna cena?

W dniu 2013-05-28 11:27, Stachu Chebel pisze:

A co to jest rozsądna cena? Optyczne czy mechaniczne?

Tu szukałeś?

uważnie przeglądaj, bo chyba mnie mają przycisku

Albo tu:

Tu o cenę musisz zapytać To tak na szybko.

Pozdrawiam

DD

Użytkownik "BartekK" napisał w wiadomości grup dyskusyjnych:ko1v8c$iqi$ snipped-for-privacy@mx1.internetia.pl...

Albo z duzym narzutem, ale w "uznanej" firmie

J.

W dniu 2013-05-28 11:51, BartekK pisze:

Tylko uważaj. One mocno trzeszczą, a niedokładność wykonania powoduje, że w zależności od położenia skok mechaniczny różnie pokrywa się ze stykiem elektrycznym. Często grzechotka cyknie, a impulsu jeszcze brak i odwrotnie. Ze względu na jakość (która jest odwrotnością upierdliwości przy obsłudze) polecam Bourns, Alps już troszkę mniej.

ostatnio kupowałem na aksotronik.pl kilka jest też na stronach trim-pot'a

To chyba nie wpływa na dekodowanie sygnału kwadraturowego jesli trzeszczy na jednej lini podczas zmiany położenia. A może trzeszczy na obu?

Próbowałem kilku algorytmów i niestety wysypują się. Teoretycznie nie powinno być problemów, ale to co napisałem niestety wszystko komplikuje. Oczywiście można robić filtrację, ale im 'lepiej' sygnał wygląda tym mniejszą częstotliwość (prędkość obrotową) można uzyskać. Mowa oczywiście o ręcznym kręceniu. Ja stosuję prosty filtr RC. Ale dobijające jest też to, że grzechotka stuknie a tu nic, trzeba 'wejść' na górkę następnej zapadki. Gdyby na jedną zapadkę impulsator generował połowę cyklu to już by było łatwiej... chyba.

Sorry, ale...nie wiem jakich enkoderów używasz,w przypadku Bourns i Alps mój program chodzi znakomicie. (Inna sprawa, że badziewia nie należy używać.) Napisałem go w dwóch wersjach (asm i C), obsługa w przerwaniach. Żadnych problemów. Przerwanie na zboczu opadajacym .Potem sprawdzenie czy sygnał dalej niski, potem sprawdzenie na drugim czy wysoki itd. To raptem paręnaście linii kodu. Nie korzystaj z gotowców. Napisz swoje własne procedury starając się zrozumieć zjawiska fizycznie. Również te niepożądane (odbijanie styków etc.).

To "Potem sprawdzenie..." jak realizujesz, delay w tym samym przerwaniu ? :-)

W dniu 2013-05-29 11:33, zapinio pisze:

Zależy co ten enkoder ma enkodować, ale jeśli tylko obrotowa obsługa menu/funkcji, to można to zrobić na różne lepsze sposoby - np przerwanie zapisuje tylko stan "o było obrócenie" a realnie obsługa obrócenia jest robiona w przerwaniu od timera, cyklicznie, tak by ograniczyć predkość kręcenia (i równocześnie wyrzucić wszystkie fałszywe kliknięcia od drgań styków). W każdym razie (poza filtrem RC fizycznym) wypada ograniczyć czasowo wrażliwość na impulsy z enkodera, bo wiadomo że nikt z ręki nie będzie robił np >10obr/s, czyli po każdym impulsie przez 100ms można ignorować następne impulsy.

W dniu 2013-05-29 11:33, zapinio pisze:

Ależ w przypadku Bourns ja nie mam problemu i to co piszesz wyżej zaimplementowane u mnie działa znakomicie. Widać nie miałeś do czynienia z tymi tanimi enkoderami. Dlatego napisałem, że testowałem też inne algorytmy, które mogły być odporniejsze na zakłócenia.

Napisałem własne, też w asm i C :P. Pierwszą procedurę, z zastosowaniem przerwań, napisałem na '51 jakieś 17 lat temu, gdy na oś potencjometru założyłem optykę z myszki (kulkowej). Potem bawiłem się impulsatorem mechanicznym (tzn. z zestykami) nieznanej firmy. Działał przyzwoicie. W

2008 roku kupiłem to badziewie ze zdjęcia i po krótkiej gimnastyce stwierdziłem, że nie ma się co pocić i kupiłem Alps i Bourns.

Zatem moja uwaga wzięła się z praktyki stosowania wymienionego przez BartekK impulsatora.

W dniu 2013-05-29 12:03, BartekK pisze:

Enkoder przez Ciebie podpowiedziany ma 20 impulsów na obrót. 20*100ms=2 sekundy na jeden obrót!? Może w Twoich projektach to wystarcza, ale mnie wkurza gdy gała nie działa z taką prędkością z jaką jestem ją w stanie kręcić, albo nawet trochę mniejszą. W amplitunerze Pioneer mam gałę z impulsatorem. Kręcenie nim nie jest wygodne, ale średnio 3 obroty na sekundę wypada. Max 4. Przy prędkości nawet mniejszej niż 1 obrót na sekundę gubi impulsy i zaczyna liczyć lewo i prawo wskutek czego szybsze kręcenie tylko zmniejsza szybkość przestrajania. W przypadku tego impulsatora to by było 80 impulsów na sekundę ->

12,5ms. Pytanie co w tym przypadku oznacza impuls. Mój noname ma 30 'ząbków' (detents), pełen okres zmian na jednym wyjściu to 4 'ząbki'. W każdym razie dobre impulsatory mają krótszy okres 'drgań' styków i znacznie łatwiej osiągnąć wystarczającą prędkość zmian na drodze filtracji sprzętowej jak i programowej. Tą drugą nawet udało mi się wyeliminować z pozytywnym skutkiem, chociaż w ostatnim projekcie na Alpsie czasem 'przeskakuje' nie tak jak trzeba. (Gała jest i do menu i do kręcenia parametrami).

W dniu 2013-05-29 12:23, Michał Lankosz pisze:

Właśnie dostałem do ręki płytkę z zainstalowanych impulsatorem, najwyraźniej kiepskiej klasy. Potrafi się przełączyć w połowie następnego kroku, a nawet jeszcze później. Potrafi kilka kroków z żalem pominąć i uważa, że tak jest lepiej. Wprawdzie nie widziałem procedury obsługi, ale na moje oko to właśnie problem z jakością styków. Jak się uda, to obmierzę i zobaczę co i jak jest.

Pozdrawiam

DD

I chyba juz wiadomo na czym polega problem jeśli Michał ma coś takiego. Algorytm odporny nadrgania zestyków *nie* działa na przerwaniach "zboczowych" bo można je przoczyć jeśli za szybko występują. Działa na poolingu i obliczaniu stanu znając aktualny i poprzedni. Wtedy nie istnieje żadna specjalna obsługa drgań, po prostu działa w każdych warunkach. Jedyny problem że pooling należy robić częściej niż spodziewana zmiana impulsu na drugiej lini. Na AVRku wyrabiam się z tym w przerwaniu co 256 cygli zegara i nie gubie żadnych impulsów przez miesiące mimo drgań i zakłuceń (przetwornik na wale). I jestem w stanie co 256 cykli wykryć poprawny impuls bez znaczenia czy były czy nie drgania o ile tylko wygasają wcześniej niż impuls na drugiej lini (ale mogą sobie dzwonić przez dowolną ilość odczytów i tak na koniec wynik jest poprawny).

W dniu 2013-05-29 13:12, Michał Lankosz pisze:

Dobrze napisałem, ale źle policzyłem ;) Napisałem 10obr/2, a liczyłem impulsy (zamiast obrotów, lub impusów*impulsów na obrót, co daje

100ms/20im/obr = 5ms zamiast 100ms)

Jak będę miał dostęp do oscyloskopu cyfrowego zarejestruję oba kanały. Tyle co dało się zobaczyć na oscyloskopie analogowym nie wyglądało dobrze i pooling nie wydawał mi się wyjściem z sytuacji. Dlatego próbowałem kilku algorytmów z myślą, że ktoś ma lepsze rozwiązanie. Zdaje się drgania były niewiele krótsze od czasu trwania impulsu... tak na oko. Pooling w przypadku impulsatora musi być niestety dużo częstszy niż dla klawiszy, w związku z czym zostaje mało czasu na pozostałe działania. Pozostaje dać osobny uC tylko do obsługi gały, taki 6-pin Atmela. ALBO dobrej jakości impulsator - i tak zrobiłem :)

W dniu 2013-05-29 22:52, Michał Lankosz pisze:

Ale bez sensownego filtru RC styki zawsze generują problemy. Czasem mniejsze, czasem za "od biedy RC" robi impedancja wewnętrznego pullupa i pojemność wejścia uC, ale ja uważam, że sensownie dobrany filtr do każdego sygnału wypada dać. Choćby to generuje problemy, ze styki mechaniczne lubią pracować przy pewnych prądach. Wiadomo że taki impulsator 1A nie będzie lubił, ale używanie pull-upa >100kOhm to też nie jest dobre - przy zbyt małych prądach są większe szaleństwa. Jeśli styk zwiera tylko przy krótkim impulsie przy obróceniu, to i 1kOhm bym dawał, jeśli nie musimy każdego uA zasilania oszczędzać.

W dniu 2013-05-30 00:46, BartekK pisze:

Dlatego i przy Bourns stosuję filtr RC. Bez niego sygnał jest za bardzo zaszumiony.