Impulsator a właściwie enkoder obrotowy,

taki posiadam egzemplarz, o rozdzielczości 20 kroków

bo tak powinno się go nazywać jest bardzo wygodnym manipulatorem łączącym świat człowieka i „system” µC. W układzie elektronicznym jest urządzeniem wejściowym oprogramowanym tak, aby za jego pomocą można było modyfikować wymyślne nastawy układu/urządzenia weń wyposażonego. 😉

Bardzo dobry artykuł z opisem tego wynalazku wygrzebałem tutaj. Biorąc pod uwagę że ten, którym się zajmuję jest elementem stykowym można spodziewać się wielu utrudnień i komplikacji. Pierwszy raz świadomie z impulsatorem jako podzespół miałem do czynienia kilka lat temu w układzie nabytym od browara, który do teraz używam ;-p Był to wtedy dla mnie nie lada wynalazek, a gdy jeszcze usłyszałem o kodzie Graya … powiedzmy, że miałem oczy jak pięć złotych. ;-D Niemniej był bardzo interesującym elementem.

Impulsator można nabyć dziś łatwo, może mieć różną rozdzielczość, i jakość wykonania co zdecydowanie przekłada się na komfort obsługi i „jakość” działania w układzie. Po prostu może zdarzać się, że poszczególne impulsy podczas obrotu mogą nie zostać rozpoznane lub w trakcie szybkiego obrotu będą się gubić …
Aby sprawdzić jakiej jakości element posiadam podłączyłem swój impulsator do analizatora stanów logicznych i … teraz wiem, że kiedy kręcę w jedną stronę działa wyśmienicie, natomiast kiedy kręcę w drugą już tak dobrze nie jest. Załączam kilka obrazków z generowanymi przebiegami podczas kręcenia, do przeanalizowania.

ładny wykres generowany podczas kręcenia gałką impulsatora, obroty w lewo a potem w prawo

na samym końcu widać „rozjechany” przebieg, moim zdaniem gdy nie kręcę ośką na obu wyjściach powinien być stan wysoki!

tutaj widać dokładnie problem z wysterowaniem jednego z wyjść, w stanie spoczynkowym

kilka „cyknięć” w prawo, przerwa – i tu znowu niezgodność, i kilka cyknięć w lewo …

widok w mniejszej rozdzielczości

tu już więcej nieścisłości zostało zidentyfikowanych. Jak wiadomo jest to element stykowy. Ciekawe co by wyszło gdybym posiadał lepszej jakości – droższy impulsator.

Podczas żwawego kręcenia częstotliwość przebiegu może zbliżyć się do 100Hz oczywiście w moim przypadku – posiadam impulsator o podziałce 20 kroków na obrót. Nie jest to bez znaczenia, szczególnie dla mnie, gdyż zdecydowałem się oprogramować ten wynalazek bez używania przerwań µC. Właściwie przed chwilką zakręciłem jeszcze raz, ale tak zwariowanie jak nigdy ;-D wyszło ponad 500Hz. Podczas normalnego użytkowania wynik mieści się w granicach pierwszego zapisu ;-p

Mój impulsator podłączony jest do µC za pośrednictwem Expandera IO pracującego na magistrali I²C. Po zbadaniu częstotliwości jaką można „wykręcić” wiem jak często odpytywać dodatkowe piny o zmianę stanu logicznego. W ten sposób wszystko powinno działać prawidłowo, a kod powinien być dobrze dostosowany do sprzętu. Sprawą istotną są też kondensatory blokujące na wyjściach impulsatora wiem to z moich obserwacji jak i utwierdzał mnie w tym dodatkowo kolega browar 😉 za co mu teraz dziękuję.
Zanim zabrałem się do samodzielnego opracowania tematu, przeglądałem na stosownych forach co wykombinowali inni. Jak wspomniałem wcześniej temat interesował mnie od dawien dawna.
Przykładowe rozwiązania, z którymi się zetknąłem opierały się na analizowaniu poszczególnych stanów na pinach, i w dodatku najczęściej z angażowaniem przerwań zewnętrznych. JA tam postanowiłem sprawę maksymalnie uprościć i sprowadzić do można by rzec banalnej obsługi przycisku. Jak tego dokonałem? Odczytuję dwa bity jednocześnie i przedstawiam je jako cyfrę. Ponieważ są to dwa bity więc cyfra może być z zakresu 0 do 3. W takim wypadku nie ma nic prostszego jak szybkie i mało kłopotliwe przeanalizowanie ciągu następujących po sobie liczb ;-p generowanych przez obrót ośki impulsatora.

Podczas testów w konsoli terminala otrzymywałem ciągi liczb. Program wykrywa zmiany stanów logicznych na pinach ekspandera i kiedy taka ma miejsce wysyła wynik na konsolę terminala RS w postaci odczytanej cyfry.  Pełen cykl przebiegu dla jednego impulsu z enkodera (bez wprowadzania jakichkolwiek opóźnień, lub kluczowania odczytu) zawiera ciąg czterech cyfr. Dla obrotu w prawo są to kolejno 2, 0, 1, 3 a dla obrotu w lewo 1, 0, 2, 3.

zobrazowany wynik obrotu gałką impulsatora, bez kluczowania

kluczowany obrót w lewo  (co 25ms), oraz wynik z konsoli – widoczne „zakłócenia”

kluczowany obrót w prawo (co 25ms), oraz widoczny wynik w konsoli

Na prezentowanych screen-ach widzimy wynik obrotu cyklicznego jak i pojedynczego „cyknięcia” w prawo bądź lewo 😉 Za każdym razem stanem „spoczynkowym” jest liczba 3. W przypadku wprowadzenia kluczowania co 25ms regularny ciąg liczb skrócił się praktycznie do 2 liczb. Czasem widoczne są „wtrącenia” zależne od szybkości ruchu gałki. Zatem mam już trzeci czynnik wpływający na „jakość” funkcjonowania tego manipulatora. Można by zwiększyć odstęp czasu między kolejnymi testami wyprowadzeń impulsatora. Ale pogorszy to znacznie „jakość” obsługi tego podzespołu co będzie objawiało się brakiem reakcji w programie na zadawany ruch ośki impulsatora. A Tego chcę uniknąć. Zresztą każdy może poeksperymentować samodzielnie i dobrać odpowiadające mu parametry.

W związku z przeprowadzonymi doświadczeniami odczyt ruchu impulsatora staje się dla mnie nieskomplikowany. Każdym razem po wykryciu zmiany i wystąpieniu nowej liczby po liczbie 3 (stan spoczynkowy), należy zbadać nową wartość i już wszystko wiadomo ;-D Jeśli to 2 nastąpił obrót w prawo, a gdy jest to 1 nastąpił obrót w lewo.

Volia, i taki to mój patent ;-D

Posiedziałem trochę i pokręciłem ośką po dostosowaniu kodu. Przy zastosowaniu kluczowania 25ms program nie interpretował prawidłowo bardzo szybkiego kręcenia (pewno takie nie miało by miejsca przy obsłudze układu). Bez kluczowania nawet ekstremalnie szybkie obroty wykrywane są znakomicie. Dla moich zastosowań będę pewnie wykorzystywać kluczowanie 10ms. Przy zastosowaniu przerwania generowanego przez expander, µC był by trochę odciążony a kluczowanie nie potrzebne. Dodatkowo stwierdziłem, że trochu badziewiasty ten mój impulsator ale działa 😀