Mały, prosty sterownik krokowca pod AVR

SylwekK pisze: Micro Motors

Jak wygląda backlash? Kupowałem kiedyś do robota kilka sztuk z serii HL149 i pod tym względem wypadły nieciekawie(pomijając ten parametr całkiem fajne), a akurat szukam czegoś w tym stylu, tylko z mniejszymi luzami.

No są minimalne luzy, ale nie takie jak w większości silników po 30-40zł. Poza tym trafiają się egzemplarze, w których luz jest prawie niezauważalny. Prawdę mówiąc nie wiem czy w twoim przypadku taki luz miałby jakiekolwiek znaczenie... Jeśli związane by to było ze zmianą kierunku (wtedy faktycznie ma to znaczenie, przynajmniej w urządzeniach do wideo) to zawsze można ominąć to programowo jak na filmie poniżej (UWAGA! Włączyć dźwięk podczas oglądania - to istotne)
https://youtu.be/Szy1RE_rcRo

Hej

Wracając do tematu. Kupiłem A4988 - działa. Niestety trafiłem na mały problem - reszta kodu
zakłóca pracę silnika. Początkowo skorzystałem z gotowej biblioteki obsługującej krokowce.
Sam silnik pracował idealnie, niestety z resztą kodu pracuje nierówno i wolniej niż powinien.
Przeanalizowałem kod i wychodzi na to, ze niektóre pojedyncze elementy wykonują się
dłużej nić wynosi czas pojedynczego kroku silnika i blokują jego działanie.
Najgorsza sprawa z termometrami typu DS18B20. Samo wywołanie pomiaru trwa bodaj
pojedyncze uS więc nie powinno stanowić problemu, ale już odczyt pojedynczego
termometru to kilkanaście mS (piszę z głowy). Termometrów mam pięć wiec 5x na sekundę
program staje na te kilkanaście mS. Oczywiście jeśli w tym czasie wypadnie moment
gdy sterownik krokowca powinien dostać impuls to go nie dostanie - krok zostanie pominięty...

AHA - dość ważne - u mnie krokowiec napędza pompkę perystaltyczną. Nie potrzeba więc
dynamicznych zmian prędkości, byle prędkość była taka jak powinna. Sama reakcja na
polecenie zmiany prędkości może nastąpić ze zwłoką nawet 1S. Świat się nie zawali

Zastanawiam się jak to zwalczyć. Jeden z pomysłów to dodać do sterowania krokowcem
dodatkowy procesor (choćby Arduino Mini) i powierzyć mu wyłącznie generowanie impulsów
dla sterownika silnika. Informację o tym jaka ma być prędkość podawać mu portem
szeregowym tylko gdy potrzebna jest zmiana (za potwierdzeniem odbioru).
To mogę zrobić sam...

Alternatywa - przerwanie na timerze. Tu nie znam się dlatego pytam. Czy wywołanie
co np. 5uS funkcji generującej impulsy przerwaniem wchodzi w rachubę (tak często).
Grosza sprawa - czy takie przerwanie nie będzie kolidować z opisanymi termometrami?
Chodzi o sytuację gdy główny kod wywołuje odczyt DSa, czeka te naście mS, w tym czasie
wypada moment przerwania, przerwanie wywołuje funkcję i wraca do DSa. Czy to nie
zakłóci odczytu temperatury?...

Z góry dzięki za podpowiedzi...

Póki co po południu zmienię podział kroków z 1/4 na 1/1 żeby wydłużyć czas między impulsami
i zobaczę co to da...

Jakub

Przerwanie na 5us w Arduino... no nie wiem czy to dobry pomysł. Biblioteki w tym środowisku są dość ociężałe, a i w czystym C mogły by być problemy. Na 10us pisałem obsługę silników, ale tram nie było termometrów (nawet jednego). Jeszcze w bascomie problem z opóźnieniami badania DS rozwiązałem jego czytaniem w przerwaniach - cyklicznie (tzw. maszyna stanów) wykonywałem po jednej operacji za każdym obiegiem i dało to rewelacyjny efekt. Tylko, że tam nie chodziło o silnik, a o przekłamania wskazań. Po tym zabiegu miałem 100/100 poprawnych wskazań.
W Twoim przypadku chyba faktycznie drugi procek mógłby się okazać najłatwiejszym i najprostszym obejściem problemu. Tylko teraz z drugiej strony - czy ta płynność obrotu w tym przypadku jest taka istotna? Przecież co ma obrócić to obróci. Czasem warto zaniżyć jakiś mniej istotny parametr na korzyść tego ważniejszego

oprawcafotografii pisze: ↑

08 sty 2020, 09:36

Póki co po południu zmienię podział kroków z 1/4 na 1/1 żeby wydłużyć czas między impulsami
i zobaczę co to da...

To powinno rozwiązać problem, ale zrobi się głośniej.

Jak często ten silnik się obraca? Czy w trakcie jego pracy potrzebne jest odczytywanie temperatury? Czyli czy pracuje przez zadany czas, czy do skutku w postaci uzyskania poprawnego odczytu temperatury?

Płynność nie jest zbytnio ważna - ważna jest ilość kroków, żeby ilość ml się zgadzała...
Niestety jeśli program jest blokowany to kroki się marnują

Zrobiłem STEPowanie na przerwaniu timera - ustawiam częstotliwość przerwania
jak potrzebna częstotliwośc ktoku / 2 i jedyne co zrobię w przerwaniu to:

void rtSTEPPER()
{ digitalWrite (stepperSTEPpin, !digitalRead(stepperSTEPpin)); }

Jest znacznie lepiej - generalnie silnik kręci się z poprawną prędkością,
ale niestety nadal coś go blokuje na ułamek sekundy tak ze 2x na sekundę.
Daje to około 10% mniejszą wydajność pompy niż powinno.

Próbowałem wyczaić która z części programu daje taki lagi ale nie mogę
znaleźć. Na pewno wyświetlanie na LCD po I2C daje laga, przepisałem
program tak, że wyświetla tylko to co się zmienia, pomogło trochę.

Niestety wygląda na to, że któreś z używanych bibliotek lagują...
Sam tych bibliotek nie przepiszę więc muszę inaczej.

Na razie chyba wystarczy jak jest, w wolnym czasie zrobię autonomiczną pompkę
z własnym prockiem i będę ją tylko informował o zmianie prędkości...

Jakub

Dodane 1 minuta 54 sekundy:

TOP67 pisze: ↑

08 sty 2020, 17:53

...
Jak często ten silnik się obraca? Czy w trakcie jego pracy potrzebne jest odczytywanie temperatury? Czyli czy pracuje przez zadany czas, czy do skutku w postaci uzyskania poprawnego odczytu temperatury?

Silnik obraca się cały czas - pompka ma pracować ciągle przez kilka godzin.
Odczyt temperatury też niestety "ciągły" czyli w moim wypadku co 800ms.

Silnik w danym etapie procesu (te kilka godzin) pracuje ze stałą prędkością...

q

Jeśli liczy się tylko przebieg, to po prostu zrób licznik kroków i puść pompkę trochę szybciej. A co jakiś czas niech odczeka.

Czyli zamiast kombinować czas * prędkość, mierz wprost ilość przepływającej cieczy.

Niestety to akurat odpada - wydajność pompki steruje procesem chemicznym,
nie mogę lać 2x szybciej i potem czekać

Jak znajdę chwilę to spróbuję znaleźć to co laguje... a jak nie to drugi procek.

q

Jakbyś to zrobił na silniku DC, to by problem nie wystąpił.

oprawcafotografii pisze:void rtSTEPPER()
{ digitalWrite (stepperSTEPpin, !digitalRead(stepperSTEPpin)); }

To bardzo powolny kod. Szczególnie w przerwaniach powinien być jak najkrótszy. Należy sprawdzić, do jakich portów należą te piny i użyć kodu, który działa bezpośrednio na rejestrach mikrokontrolera. Będzie szybciej i to kilkudziesięcio jeśli nie kilkusetkrotnie.