microgeek.eu

Cześć.

Mam pewną zagwozdkę i proszę, by ktoś z cyfrowym oscyloskopem sprawdził, która z poniższych wersji lepiej nadaje się do stosowania przy enkoderze inkrementalnym. Jedna z wersji jest propozycją Mirka Kardasia, druga wprost z dokumentacji enkodera.

A tutaj wrzucam schemaciki obu wersji:

lpf.png

Gdyby komuś się chciało sklecić pojedynczy kanał obu wersji tych filtrów i sprawdzić na oscyloskopie...

Dlaczego chcę sprawdzić, który lepszy? Ano tylko dlatego, bo wersja B ma o dwa elementy mniej i zawsze trochę łatwiej jest rozmieścić elementy na płytce.

Pozdrawiam.

Ja przepraszam, że nieco offtopic, ale czy jesteś pewien, ze chcesz walczyć z drganiami filtrem RC?
Debouncing można zrealizować czysto programowo (jeden kanał wyzwala sprzętowe przerwanie /to, że może polecieć seria wynikająca z drgań - nie przeszkadza/, stan logiczny na drugim kanale jest badany po czasie jaki przyjmiemy, że drgania niby ustały, a czas ten mierzymy od przerwania właśnie, do ustalenia doświadczalnie i jako łatwo poprawialny const w programie) i to wszystko.
Ja się już kiedyś przewiozłam strasznie na takim wyklikanym enkoderze z wylutu, takie harce na oscyloskopie styki robiły że o matko... no chyba że robisz coś na zwykłych cyfrowych kostkach...bardzo to pilne jest?

Nie jest pilne, choć jest to element, którym właśnie się zajmuję. Generalnie program w miarę kulturalnie reaguje na pracę enkodera, ale czasami widać, że się pomyli. Obecnie nie mam żadnego filtra w układzie - po prostu gołe druty idą do MCU. Program sprawdza położenie enkodera z częstotliwością 200Hz i nie korzysta z przerwania INT. Częstotliwość zmian położenia enkodera nie powinna przekraczać kilkunastu Hz, bo wykorzystywany jest jedynie do ręcznego ustawiania godzin, minut itp. w budziku.

Antystatyczny pisze:Nie jest pilne, choć jest to element, którym właśnie się zajmuję.

no czyli jest pilne....grepuję swoje szpargały, miałam przykład jak z tym walczyć, ale jak potrzebne to akurat nie widzę....słuchaj, a może wystaw mi kod źródłowy, ale całość, może uda się coś wydumać, chce spróbować, na priv albo na e-mail, jak wolisz

Ok, za chwilę się tym zajmę.

Projekt w eclipse:

zgrałam sobie, fajnie to napisane, no, długi wieczór się szykuje

Folderem switch nie zaprzątaj sobie głowy. Takie tam bazgroły, które dziś zacząłem pisać. Ani to skończone, ani działające, a tym bardziej zoptymalizowane.

Może wieczorem uda mi się to skręcić na stykówce, ale wersja B wygląda na bardziej "wyrównaną" kondensatory są zarówno ładowane jak i rozładowane przez taką samą rezystancję 10k czyli zbocza będą do siebie podobne, w wersji A jest nieco inaczej zbocze narastające jest bardziej nachylone a opadające znacznie bardziej strome.

Pytanie na jakim zboczu ci bardziej zależy? stromym czy łagodnym, oraz czy w ogóle badasz zbocza czy tylko poziomy.

Podobno strome zbocze jest milej widziane przez MCU, ale to by się musieli wypowiedzieć mądrzejsi ode mnie.

Jak pisałeś swojego posta ja edytowałem dopisując czy badasz zbocza czy poziomy, wyliczyć stałą czasową też można wówczas będziesz jakiś pogląd o zboczach.

A czy strome zbocze jest mniej widoczne to nie wiem ja bym bardziej podejrzewał że większy problem może być przy łagodnym zboczu. Wejścia mają zazwyczaj przerzutnik Shmita i zawsze jest jakieś "okienko" i chyba lepiej je przejść szybciej, żeby przerzutnik szybciej zareagował ale może tylko tak mi się wydaje

Zdecydowanie badam poziomy, ponieważ nie wykorzystuję przerwań wyzwalanych zboczami. Próbkuję stany pinów 200 razy na sekundę.

Można przyjąć że przerzutnik Shmita zareaguje przy stałej czasowej równej 2, czyli 86% naładowania kondensatora 10n*10k*2 = 200u sek. tyle można przyjąć czas trwania po jakim stan będzie odczytany jako pewne 0 lub 1.
Ty badasz stan co 0,005 sekundy. W sumie mógłbyś chyba zwiększyć rezystory do 25k wówczas miałbyś na ustalenie jakieś 500u sek.

Nie jestem pewien, czy ATmega ma wejścia Schmitta. Rozumiem, o co chodzi, ale trudno mi powiedzieć, czy na łagodnym zboczu detekcja stanu przebiegnie prawidłowo.

jestem przekonany na 99% ze ma shmitta na wejsciu.

EDIT

widać, że jest:

Faktycznie, jest.

Nie mam enkodera ale testowane na buttonach:

Wersja A ma bardziej nachylone zbocze narastające a strome opadające (ok. 3us):


Natomiast przebiegi wersji A:


Wersja B ma bardziej nachylone zbocza, szczególnie narastające (ok 400us)


Przebiegi wersji B:

Tutaj jeszcze przebiegi z modułu enkodera z wbudowanymi 10k pull-up do VCC oraz dołożonym filtrem z obrazka B.

O takie coś mi chodziło. Serdecznie dziękuję, Matty! A teraz wnioski. Wersja A zapewnia lepsze zbocza (bardziej strome), a przede wszystkim zbocze opadające. Obie dość dobrze usuwają śmieci spomiędzy stanów ustalonych. Poruszony został również wątek programowej eliminacji zakłóceń, więc zaczekam jeszcze na wyniki badań, które przeprowadzi Tasza.

ale fajne screeny

yyyy, no z tym czekaniem to ja nieśmiało proponuję model asynchroniczny, może w międzyczasie RTC się zajmiesz albo no nie wiem...
czymś innym niż encoder? bo ja się dopiero ogarnęłam i mam tak:

mój encoder (ten z fotki) to http://www.tme.eu/pl/Document/8a385285d ... -ECW1J.pdf
żelazo to and-tech EVB 5.1, zapięte w/g komentarzy w kodzie, a kod bez zmian, jedyne co to że kwarc 16MHz
makefila sobie napisałam do tej zabawki - załącznik, trzeba usunąć .txt a plik ma być w podfolderze /src archiwum , co załączono wyżej.
make clean - czystka, make all - buduje projekt, (sudo) make install - programuje kostkę
hmm, po odpaleniu jest jakoś dziwnie
powolutku, ostrożnie kręcąc ośką - licznik na ekranie pracuje spoko, zwiększa, zmniejsza wartość zgodnie z kierunkiem.
`szarpnięcie`, takie ostrzejsze zakręcenie - albo gubi wartości, albo przeskakuje o kilka albo wręcz błędnie (odwrotnie) interpretuje kierunek obrotów i robi to zupełnie niedeterministycznie
zastanawiam się ile w tym zasługi nieco większego kwarca (16 vs 11) i jakości encodera (co z tego, że drogi, jak parę lat przeleżał w pudle w garażu)

no nic, zaczynam męczyć ten temat, bo zagadka ciekawa

Enkodery mają cudowne predyspozycje do samoistnego psucia się, bo śniedzieją w środku. Być może wzrost częstotliwości pracy zegara również ma swoje negatywne skutki, o ile pozostawiłaś ustawienie timera sprzętowego bez zmian. Zamień, proszę, linię 46 pliku main.c na następującą:


To zapewni automatyczne dopasowanie pracy timera niezależnie od częstotliwości zegara taktującego. (oczywiście w granicach rozsądku, bo obliczenie zakłada, że włączony jest preskaler 1024)

Aha, jeszcze jedno. Zerkam w dokumentację Twojego enkodera i czy dobrze widzę, że możliwe opcje to ćwierćkrokowy lub pełnokrokowy? Jeśli masz pełnokrokowy, spróbuj w pliku encoder.h ustawić parametr ENCODER_FULL_STEP na wartość 1.

Antystatyczny pisze:Enkodery mają cudowne predyspozycje do samoistnego psucia się, bo śniedzieją w środku

wypadałoby dodać - nieużywane, niebiegane encodery, bo ja popełniłam parę zabawek ze ``scrollerami``, głównie wylutki ze złomu z Wolumenu i jakoś do dziś działają, ale są bez przerwy używane i to w trudnych warunkach czasem - timerki kuchenne, wilgoć, para etc
Ok, kod zmienię ale to potem, jak tylko moi pójdą spać, to najpierw poszukam kwarca 11.059, typowy pod '51 przecież, ja całe pudełko ich miałam..gdzieś chce mieć punkt startu identyczny jak u ciebie
jak coś się wykluje nowego to będę pisać tu, albo na f.

Zerknij jeszcze na mój poprzedni post, bo go edytowałem, a w tym czasie napisałaś swój.

tasza pisze:wypadałoby dodać - nieużywane, niebiegane encodery

Tak, dokładnie to miałem na myśli. Pomyślałem o tym, ale nie przelałem na "papier"

Z ciekawości sprawdzę potem jak radzą sobie STMki ze sprzętową obsługą enkoderów. Dla magnetycznych z obrotami silników w robociku działało idealnie, ciekawe jak dla mechanicznych.

w sumie to już sama nie wiem czy kolejny offtopic czy ostrzeżenie dla innych - encoder, ale zaniedbany, wyleżany w pudełku i mający kontakt z odrobiną wilgoci przez spory czas (vide co pisał Antystatyczny - zaśniedziałe styki)

bo tak wygląda w miarę na żywo, na analogodiscoveroskopie, możliwe że trigger nieumiejętnie ustawiłam, nie zmienia to faktu że .... to jest jakaś masakra normalnie
https://youtu.be/h4mzjrOxHjc
no i jeszcze jedna sprawa sytuacyjna - nie mam odpowiedniej gałki, więc ośkę kręciłam palcami, aby płytka stykowa nie latała po stole - czasem dociskając to do blatu - to ostatnie sekundy filmy - kształt przebiegu zupełnie inny, styki robią co chcą....

@Antystatyczny - no serio szacunek, że twój program w ogóle z tym moim enco. ruszył, bo przypadek zaiste trudny mi się trafił.

Sorki, ale temat parkuje do czasu zdobycia nowego (sklepowego) encodera, jak na Górzystej w Ostr. nie będzie, to Wol. i Warszawa, ale w weekend dopiero....