On Wed, 29 May 2013 11:33:13 +0200, "zapinio" <z...@g...com>
wrote:
> Przerwanie na zboczu opadajacym .Potem sprawdzenie czy sygnał dalej
niski,

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

--
Marek

do góry

W dniu 2013-05-29 11:33, zapinio pisze:
> 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.).
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.


--
| Bartłomiej Kuźniewski
| s...@d...org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338
173

do góry

W dniu 2013-05-29 11:33, zapinio pisze:
> 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.

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.

> 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.).

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.

--
Michał

do góry

W dniu 2013-05-29 12:03, BartekK 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.

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).


--
Michał

do góry

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

> 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.

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

do góry

On 2013-05-29 11:33, zapinio wrote:
> Przerwanie na zboczu opadajacym .Potem sprawdzenie czy sygnał dalej
> niski, potem sprawdzenie na drugim czy wysoki itd.

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).

do góry

W dniu 2013-05-29 13:12, Michał Lankosz pisze:
> W dniu 2013-05-29 12:03, BartekK 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.
>
> 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ą.
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)


--
| Bartłomiej Kuźniewski
| s...@d...org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338
173

do góry

W dniu 2013-05-29 19:15, Sebastian Biały pisze:
> On 2013-05-29 11:33, zapinio wrote:
>> Przerwanie na zboczu opadajacym .Potem sprawdzenie czy sygnał dalej
>> niski, potem sprawdzenie na drugim czy wysoki itd.
>
> 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).

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 :)

--
Michał

do góry

W dniu 2013-05-29 22:52, Michał Lankosz pisze:
> 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 :)
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ć.


--
| Bartłomiej Kuźniewski
| s...@d...org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338
173

do góry

W dniu 2013-05-30 00:46, BartekK pisze:
> Ale bez sensownego filtru RC styki zawsze generują problemy. Czasem

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


--
Michał

do góry