Witam serdecznie, Podczas mojego projektu z laboratorium natknąłem się na problem którego nie umiem pokonać. Mianowicie steruję silnikiem krokowy przez sterownik ssk-b02 przy pomocy m8 (takowanie wewnętrzne 8MHz). Sterowanie obsługiwane jest w przerwaniu. CTC na Timerze2 8bitowym
Chciałbym przy pomocy joysticka płynnie przyśpieszać silnikiem. Niestety przy aktualizacji rejestru OCR2 silnik mi zrywa, nie działa płynnie. Dzieje się to zapewne z powodu omijanych przerwać przez aktualizację rejestru OCR2. Jak Wy byście rozwiązali ten problem ? Bo ja niestety nie mam pomysłu.
A gdyby tak zrobic rampowanie? Dajmy na to masz jakis czas rampowania a sekund. Timer programowy co 100 ms. Dzielisz czas rampowania przez timer i masz ilosc krokow. Odczytujesz wartosc ADC i dzielisz przez ilosc krokow, Otrzymujac wartosc o jaka masz zwiekszac OCR2 wykorzystujac timer programowy. A wnim tez masz flage ktora ci mowi ze juz dorampowales...
A mógłbyś mnie trochę nakierować jak wykonać to rampowanie ? To co napisałeś nie jest dla mnie zrozumiałe. Rozumiem, że chodzi o płynne przyśpieszanie silnika. Zostawmy więc Joystick (bo to za pewnę trudniejsze) i chciałbym spróbować płynnie przyśpieszyć silnik przez zmienną kroczki. Twoje rozwiązanie proponuje obsługę silnika w pętli głównej(?) ja chciałbym pozostać w przerwaniu ponieważ w głównej obsługuję lcd oraz klawiaturę a tam używam funkcji delay i to mogło by spowodować nieregularną pracę silnika i z zbyt małą prędkością .(może się mylę to mnie poprawcie).
W sumie nie znalazłem w sieci jakiegoś prostego przykładu z kodem w języku c. Może ktoś z was ma prosty przykład i chciałby się podzielić ? Czy dorampowanie oznacza, że już osiągnąłeś maksymalne przyśpieszenie ?
W petli glownej lic delte z wartosci adc. Dziel ja przez np 100 (szybkosc rampowania). Wyjdzie ci o ile zwiekszac ocr2. Ale zwiekszaj / zmniejszaj ocr2 w przerwaniu tak dlugo az dojdzie do aktualnej wartosci adc. Teraz ustawiasz w petli glownej ocr2 skokowo dlatego ci zrywa silnik.
Dobrze kombinujecie z tą rampą Aby silnik działał płynnie to faktycznie dobrze jest zrobić główną jazdę w przerwaniach, ale już z pętli głównej wszystkim sterować chociaż jeśli się dobrze napisze program czyli nieblokująco to i spokojnie w pętli głównej cały ruch można zrobić, a w przerwaniach zostawić tylko timer programowy taktujący krokami silnika. Robiłem już sterowniki w obu wymienionych przypadkach i nie było z tym problemu. U Ciebie jednak raczej wszystko się pogryzie, bo jak piszesz masz obsługę klawiszy z delay'em, a płynne sterowanie silników to uwierz może nie jest trudne, ale wymaga sporej dyscypliny od programisty. Nie mogę Ci niestety zdradzić jak rozwiązuje ruch w swoich sterownikach, bo to raczej komercyjne urządzenia, ale podpowiem jedno z rozwiązań jakie czasem stosuję. Skorzystaj ze zmiennej doganiającej (tak sobie ją kiedyś nazwałem przy pierwszym sterowniku). Chodzi o to, że główna zmienna sterująca prędkością jest przyrównywana do tej doganiającej, która z kolei jest inkrementowana lub dekrementowana aby dogonić wartość z głównej zmiennej sterującej prędkością z zadanym opóźnieniem ustalającym właśnie ten tajemniczy próg RAMP. Na wyjściu funkcji do właściwego (ostatecznego) ustalenia prędkości jest już wykorzystywana wartość właśnie tej zmiennej doganiającej, a nie tej wstępnej sterującej prędkością. Może troszkę chaotycznie wytłumaczone, ale nie mam pedagogicznego wykształcenia. Zapewniam jednak, że jak to przetrawisz to zobaczysz, że samo rozwiązanie to dosłownie KILKA linijek kodu Przykład joy'a i krokowego gdzie użyłem tego algorytmu:
(To była przeróbka sterownika zrobionego przez kogoś kto raczej nie wiedział jak właściwie powinien działać kran kamerowy)
No ja niestety tez nie potrafie tlumaczyc ale wydaje mi sie ze mowimy o tym samym czyli o rampowaniu licznik ocr2 zmieniac o jakis krok az dojdzie do wartosci jaka ma miec a nie z kopyta mu zmieniac wartosc...
eMCe2 nie obraź się ale przyznam Ci rację, nie umiesz tłumaczyć ni w ząb. Ale dzięki za zainteresowanie tematem bo dzięki temu co napisałeś zacząłem szukać w internecie we właściwym kierunku. Tzn rampowanie, wcześniej słyszałem tę nazwę ale nie wiedziałem co oznacza.
SylwekK dzięki bardzo za nazwę "doganiacz" właśnie tego mi było trzeba , a przynajmniej mam taką nadzieję bo to co napisałem na sucho będę mógł przetestować jutro w laboratorium. Rozumiem, że nie możesz mi podać kodu, ale możesz chyba uchylić rąbka tajemnicy i podzielić się ilością instrukcji w asemblerze ? Chciałbym wiedzieć czy mój kod jest mało optymalny czy bardzo mało optymalny Chodzi mi o ten sposób kiedy silnik krokowy obsługujesz w przerwaniu.
...możesz chyba uchylić rąbka tajemnicy i podzielić się ilością instrukcji w asemblerze ?
No właśnie nie bardzo, bo to co mam jest w Bascom'ie, a tam podglądu asemblera nie mam. Odkąd zacząłem programować w C to zrobiłem w nim dopiero jeden pełny duży projekt i akurat w nim zamiast jednego silnika krokowego użyłem dwóch motorów DC - takie zapotrzebowanie . Poniżej szybki test z działania jeszcze bez wszystkich funkcji w programie (wersja beta). Jakość kiepska, bo to nie film reklamowy tylko nagrany na szybko dla wąskiej grupy oglądaczy. Wersja "ładna" będzie już na działającym sliderze i wtedy szerzej zademonstruje opcje.
Mam dopiero w planach kilkukanałowy ster krokowców, ale z tym jeszcze zejdzie, bo w kolejce czeka następny sterownik dla silników DC - tym razem będzie to całe stado tych silników i muszę go w ciągu miesiąca-dwóch skończyć.
Przede wszystkim musisz pozbyć się z pętli głównej programu wszystkich(!) delay. Bez tego szkoda czasu na zabawę w elastyczne sterowanie silnikami. Przyciski obsługuj za pomocą Mirkowej SuperDebounce, albo moich funkcji (też są na forum). Obsługa timerów programowych to podstawa. To na timerze ustalasz interwał i prędkość narastania ramp. Dla standardowych prędkości silnika przy ich normalnym zasilaniu (nie mówimy tutaj o czoperach) pętla spokojnie się wyrobi i jeszcze będzie duuużo czasu na inne rzeczy dlatego zarówno cały ruch możesz zrobić w programie głównym. Jak wspominałem przerwania wykorzystaj tylko do odmierzania przerw czasowych aby wszystko płynnie chodziło. Poniżej wczesna faza alfa mojego pierwszego sterownika s.krokowego na AVR w bascom gdzie cały ruch odbywa się na zasadzie wyżej opisanej. Nawet nie pytam czy widzisz tu jakieś zakłócenia...
Przy silnikach DC jest trochę trudniej - w pierwszym filmie cały ruch jest w przerwaniach natomiast wszelkie jego parametry zadawane są z pętli głównej, w której mam tyle czasu, że mogę sobie przy nawet bardzo wysokich niezakłóconych obrotach wyświetlać bajerki w postaci pasków postępu czy innych migadełek. Nie ma co gdybać - pokażesz kod to będzie można coś więcej powiedzieć.
Z gory sorki za offtopa ale @SylwekK przejrzalem te twoje filmiki na youtube i silniczkami krecisz ladnie ale w gary walisz zaj...efajnie... Zazdroszcze bo zawsze mialem smaka sie tego nauczyc ale chyba nie mam takich precyspozycji... Mega wypas
Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 0 gości
Nie możesz rozpoczynać nowych wątków Nie możesz odpowiadać w wątkach Nie możesz edytować swoich postów Nie możesz usuwać swoich postów Nie możesz dodawać załączników
Kanał - ATNEL tech-forum
Zaloguj
Zarejestruj
Informacje o cookies
FAQ
Szukaj
Aby silnik działał płynnie to faktycznie dobrze jest zrobić główną jazdę w przerwaniach, ale już z pętli głównej wszystkim sterować chociaż jeśli się dobrze napisze program czyli nieblokująco to i spokojnie w pętli głównej cały ruch można zrobić, a w przerwaniach zostawić tylko timer programowy taktujący krokami silnika. Robiłem już sterowniki w obu wymienionych przypadkach i nie było z tym problemu. U Ciebie jednak raczej wszystko się pogryzie, bo jak piszesz masz obsługę klawiszy z delay'em, a płynne sterowanie silników to uwierz może nie jest trudne, ale wymaga sporej dyscypliny od programisty. Nie mogę Ci niestety zdradzić jak rozwiązuje ruch w swoich sterownikach, bo to raczej komercyjne urządzenia, ale podpowiem jedno z rozwiązań jakie czasem stosuję. Skorzystaj ze zmiennej doganiającej (tak sobie ją kiedyś nazwałem przy pierwszym sterowniku). Chodzi o to, że główna zmienna sterująca prędkością jest przyrównywana do tej doganiającej, która z kolei jest inkrementowana lub dekrementowana aby dogonić wartość z głównej zmiennej sterującej prędkością z zadanym opóźnieniem ustalającym właśnie ten tajemniczy próg RAMP. Na wyjściu funkcji do właściwego (ostatecznego) ustalenia prędkości jest już wykorzystywana wartość właśnie tej zmiennej doganiającej, a nie tej wstępnej sterującej prędkością. Może troszkę chaotycznie wytłumaczone, ale nie mam pedagogicznego wykształcenia. Zapewniam jednak, że jak to przetrawisz to zobaczysz, że samo rozwiązanie to dosłownie KILKA linijek kodu 
. Poniżej szybki test z działania jeszcze bez wszystkich funkcji w programie (wersja beta). Jakość kiepska, bo to nie film reklamowy tylko nagrany na szybko dla wąskiej grupy oglądaczy. Wersja "ładna" będzie już na działającym sliderze i wtedy szerzej zademonstruje opcje.
