Sterowanie silnikiem krokowym przez sterownik - nietypowe działanie

Witam, do rzeczy:

- sterowanie: raspberry pi 4
- język: Python3
- sterownik: TB67S249FTG
- silnik: JK42HM34-1334


Dokumentacja:
- TB67S249FTG: https://www.pololu.com/product/2973
- JK42HM34-1334: https://nettigo.eu/products/stepper-motor-nema17-0-22nm-400-steps


Co ustawiłem:
- napięcie wejściowe 10V DC
- VREF = 1V (ponieważ prąd na jedną fazę = 1,33 to: 1,33/1,25 = 1,064)
- wszystkie GND są podłączone (rpi, masa drivera prawego i lewego)


Podłączenie silnika do sterownika:
- WYJŚCIE B+ → RED
- WYJŚCIE B - → BLUE
- WYJŚCIE A - → GREEN
- WYJŚCIE A + → BLACK

Reszta jest podłączona do Raspberry Pi 4:


Połączenia zostały sprawdzone, czytałem dokumentacje i tematy z forum.
Zwiększyłem napięcie do 30 V DC (jak sugerował jeden z użytkowników w temacie ze wzmianką o driverze: TB67S249FTG), ale nic nie dało, im większe napięcie tym mocniej się grzeje. Doprowadzone 5V do AGC0/1.

Poniżej nieprawidłowe działanie silnika.
Na pierwszym charczy jakby prąd był zbyt duży, parametry
Rozdzielczość: 1/4
CLK: 0.0002 sekundy (5 kHz)



Tutaj ta sama rozdzielczość ale zmiana CLK na 0.001 sekundy (1kHz)



Repozytorium na github-ie jest moje, program jest wykonywany:



gdzie rotation_time jest tym 5 kHz i 1 kHz
rotation_time = .0002 -> pierwszy filmik
rotation_time = .001 -> drugi filmik

Nie wiem gdzie popełniłem błąd, posiadamy w firmie drukarki 3D i frezarki CNC i to co ja poskładałem nie brzmi jak silnik krokowy.

Z zaobserwowanych wniosków może napisać, że:
- silnik się mocno grzeje podczas katorgi jaką mu serwuje (nie dziwi mnie to)
- przy niskich obrotach (rotation_time) charczy, im większe to jakby gubił je - nie potrafię ustalić odpowiedniej częstotliwości
- sterownik przestał się grzać jak podłączyłem AGC0/1 do 5V DC (wiem czemu, z filmu instruktarzowego) jednak przy większym napięciu grzeje się (proporcjonalnie)

Wydaje mi się też, że jest jakiś błąd
Wątek: Basic function of stepping motor control (strona 11)
pkt. ósmy: OSCM (internal oscillator) function

Treść: ...Please connect the pull-up resistor to the VCC when PWM
frequency is set by the external components. Also, to use an internal ‘fixed value OSCM frequency’ (not using any external
components), disconnect the ROSC resistor and short the OSCM pin to the GND...



Na stronie 23 jest schemat elektroniczny podłączenia:



I poniżej mamy tabelę wartości tych elementów (wiadomo - domniemywana)



ALE na stronie producenta Pololu dotyczącej tego sterownika, na dole strony pokazany jest schemat elektroniczny z elementami i ich wartościami:



Z tego schematu wynika, że ten kondensator COSC jest zamieniony na rezystor 0 Ohm który zwiera bezpośrednio do GND. Czyli z tego opisu z punktu 8 o OSCM wynika, że 'na stałe' jest skonstruowany driver tak, żeby działał wykorzystując wewnętrzny oscylator.

Czy ja dobrze myślę?

Ale to nie ma sensu na systemie operacyjnym, który nie jest real-time, system będzie od czasu do czasu uruchamiał ten wątek, wykona kilka kroków, a później procesor będzie mielił coś innego robiąc przerwę w pracy silnika, przerwa może być kilka ms, a może kilkadziesiąt jak będzie miał coś ważniejszego do roboty, więc o jakich kHz mowa?

Takie prymitywne metody działają na Arduino, gdzie nie wykonuje się nic poza twoim kodem, na RPI to albo trzeba przejść na Linuxa real time i pisanie niskopoziomowego kodu który te możliwości wykorzysta, albo niech generowaniem impulsów zajmie się hardware.

rg6502 napisał:

Teoretycznie nie ma sensu, w praktyce nie ma się co przejmować - silnik tak czy siak wykona te kroki czy mu się częstotliwość zgadza czy nie, nawet jak złapie czkawkę od czasu do czasu to co z tego?

To że wirnik ma moment bezwładnosci, jeśli impulsy nie pojawiają sie wtedy kiedy wirnik obróci się na właściwą pozycję to mamy bardzo ograniczone osiągi. Po prostu kroki które są nie wtedy kiedy trzeba, łatwiej mogą spowodować gubienie kroków. To nie ma znaczenia czy silnik pracuje w obrabiarce, ale czy wykonuje jakąkolwiek pracę - oddaje jakikolwiek moment, jeśli tak to ten tryb sterowania pokaże swoje niedostatki.

rg6502 napisał:

Może się okazać ze ten silnik i tak nie ma się ochoty kręcić szybciej niż 2 kHz i żaden real time mu nie pomoże.

Porównaj sobie jak silnik działa sterowany z LinuxCNC a Mach3 przy użyciu LPT a przekonasz się że w tym drugim przypadku maksymalne obroty i moment przy obrotach poniżej maksymalnych wypadają marnie

2kHz przy takim gównianym sterowaniu to przesada, ale 100Hz jest ok

@rg6502 Racja, szczególnie w amatorskich projektach, po prostu trzeba sprawę jasno postawić, co można oczekiwać od danego rozwiązania. W tym przypadku będzie działać, ale oczekiwanie że będzie szybko działać jest nierozsądne.

W tym przypadku zrób porządnie, sprowadza się do użycia 10 razy tańszego hardware, na którym nie chodzi żaden OS i na którym bardzo podobny program na pięć linijek (ale nie bloatware-Python tylko C) wygeneruje impulsy w równych odstępach.
To chyba nie jest duży nakład pracy?

Dziękuje za podpowiedzi, właśnie już się zorientowałem wcześniej aby użyć PWM, na innym forum po prostu ktoś zasugerował wykonywanie w taki sposób impulsów: Forum Pololu.

jarek_lnx napisał:

takie prymitywne metody działają na Arduino, gdzie nie wykonuje się nic poza twoim kodem, na RPI to albo trzeba przejść na Linuxa real time i pisanie niskopoziomowego kodu który te możliwości wykorzysta, albo niech generowaniem impulsów zajmie się hardware.

No właśnie napisałem inną jeszcze bibliotekę do generowania impulsów w zależności od nadanego RPM. Przy 5 mln RPM (83,3 kHz) miałem 99,131 % sprawności.
Arduino kiepsko sobie z tym radzi (jako software), ale będę dobrej myśli, że PWM załatwi sprawę.
Dam znać co z tego wyszło.

Dodano po 11 [minuty]:

jarek_lnx napisał:

@rg6502 Racja, szczególnie w amatorskich projektach, po prostu trzeba sprawę jasno postawić, co można oczekiwać od danego rozwiązania. W tym przypadku będzie działać, ale oczekiwanie że będzie szybko działać jest nierozsądne.

W tym przypadku zrób porządnie, sprowadza się do użycia 10 razy tańszego hardware, na którym nie chodzi żaden OS i na którym bardzo podobny program na pięć linijek (ale nie bloatware-Python tylko C) wygeneruje impulsy w równych odstępach.
To chyba nie jest duży nakład pracy?

Ale nie rozumiem po co ten ton, nie kupiłem RaspberryPi tylko do tego projektu, mam kilkanaście na stanie RPi różnych wersji, Arduino też, nawet mam Nvidia Jetson AGX Orin, zapewne PWM załatwi sprawę, po prostu nie jest jasno to nigdzie napisane a jak ktoś nie miał z tym wcześniej do czynienia to ciężko się połapać.

RebellionArts napisał:

No właśnie napisałem inną jeszcze bibliotekę do generowania impulsów w zależności od nadanego RPM. Przy 5 mln RPM (83,3 kHz) miałem 99,131 % sprawności.

Co to znaczy 99,131 % sprawności?

RebellionArts napisał:

Arduino kiepsko sobie z tym radzi (jako software), ale będę dobrej myśli, że PWM załatwi sprawę.

Arduino jako software? przecież tam nie ma software-u poza inicjalizacją i tym co napiszesz. Może miałeś na myśli mało wydajny hardware?
Na Arduino PWM załatwi sprawę całkowicie, na RPI może się zdarzyć że twój proces nie dostanie czasu procesora kiedy trzeba będzie zaingerować w PWM i przykładowo timer będzie generował impulsy kiedy powinien zostać zatrzymany.
Jest to postęp w stosunku do programowej generacji impulsów, ale nadal rozwianie zawodne.

RebellionArts napisał:

Ale nie rozumiem po co ten ton, nie kupiłem RaspberryPi tylko do tego projektu, mam kilkanaście na stanie RPi różnych wersji, Arduino też, nawet mam Nvidia Jetson AGX Orin, zapewne PWM załatwi sprawę, po prostu nie jest jasno to nigdzie napisane a jak ktoś nie miał z tym wcześniej do czynienia to ciężko się połapać.

Nie wiem o jaki ton masz pretensje, uwaga o nakładzie pracy, była argumentem przeciw temu co napisał rg6502.
Po prostu kiedy użyjemy produktu o dużo większych możliwościach, ale włożymy tyle samo pracy (tu bardzo mało), efekt będzie gorszy niż na low-endowej płytce.

jarek_lnx napisał:

Co to znaczy 99,131 % sprawności?

Napisałem 'bibliotekę' pod to (nie ma jej jeszcze na Pypi.org), do generowania RPM w zadanym czasie, przy 5 mln ma całkiem dobre wyniki (dla 10 niezależnych pomiarów / 10 uzyskałem 99,131 % wykonanych obrotów)
Nie użyłem jej jeszcze do nadawania 'impulsów' bo chciałem sprawdzić 'na sucho' z przerywaniem po sleep no i jak widać kicha.

jarek_lnx napisał:

Arduino jako software? przecież tam nie ma software-u poza inicjalizacją i tym co napiszesz.

Użyłem software jako nazewnictwo tego programu co jest wgrywany do Arduino. Nie chce się o to sprzeczać , jeśli wprowadziłem Ciebie w błąd to przepraszam.

jarek_lnx napisał:

Nie wiem o jaki ton masz pretensje, uwaga o nakładzie pracy, była argumentem przeciw temu co napisał rg6502.

Wydawało mi się wtedy że dyskusja schodzi na czyjeś podejście do tego jak powinien wyglądać program do sterowania elektroniką To co tutaj widzicie z kodu jest do testowania. Po co mam pisać 10 razy więcej linijek w C żeby tylko 'potestować'

jarek_lnx napisał:

Po prostu kiedy użyjemy produktu o dużo większych możliwościach, ale włożymy tyle samo pracy (tu bardzo mało), efekt będzie gorszy niż na low-endowej płytce.

No i właśnie odbiłem się od ściany, użyłem pwm na RPi i działa dobrze dla f > 1 kHz oraz dla wypełnienia poniżej 30/40 (najlepiej na 0,0001)

Napisałem coś takiego:



I tak:
- silnik kręci się cały czas tą samą prędkością....
Ani zmiana wypełnienia ani zmiana Hz nic nie dała ....

Obawiam się, że @rg6502 ma rację:

rg6502 napisał:

Powiedział bym nawet że PWM nadaje się 'tak sobie', tzn nadaje się jak interesuje nas stała prędkość obrotu, ale w silniku krokowym raczej chodzi o precyzyjne liczenie kroków przy zmiennej częstotliwości. Z tego też względu nie podniecam się bardzo tym że któryś tam mikrokontroler ma PWM w hardwarze - no co z tego jak nie liczy kroków i nie da się płynnie sterować częstotliwością, bez tych rzeczy nie będzie dobrego pozycjonowania

Jak na razie to silnik chodzi gładko (czasem chrumka - delikatne zgrzytanie co sekundę lub więcej mniej - zależy trochę od Hz i wypełenia) ale nie da się sterować szybkością obrotów

RebellionArts napisał:

jarek_lnx napisał:

Co to znaczy 99,131 % sprawności?

Napisałem 'bibliotekę' pod to (nie ma jej jeszcze na Pypi.org), do generowania RPM w zadanym czasie (package) - przy 5 mln ma całkiem dobre wyniki (dla 10 niezależnych pomiarów / 10 uzyskałem 99,131 % wykonanych obrotów)

Marny wynik jak dla silnika krokowego. Oznacza to że gubi kroki, powinno być 100%.

RebellionArts napisał:

jarek_lnx napisał:

Po prostu kiedy użyjemy produktu o dużo większych możliwościach, ale włożymy tyle samo pracy (tu bardzo mało), efekt będzie gorszy niż na low-endowej płytce.

No i właśnie odbiłem się od ściany, użyłem pwm na RPi i działa dobrze dla f > 1 kHz oraz dla wypełnienia poniżej 30/40 (najlepiej na 0,0001)

PWM do sterownika silnika krokowego? Tam wystarczy podać narastające zbocze na wejście CLK(STEP), żeby wymusić jeden krok (albo μkrok, zależy co jest ustawione pinami DMODE0..2). Wypełnienie jest tu bez znaczenia, na wejściu CLK jest jakiś filtr więc kilkaset tysięcy impulsów(kroków) można posłać ale tak wysokie obroty są nierealne.

RebellionArts napisał:

Kod: Python

Zaloguj się, aby zobaczyć kod

1. "pwm.start(0.0001)" takie ustawienie daje rozdzielczość 100.0/0.0001 czyli co najmniej 1mln różnych wartości dla wypełnienia a to wymaga jakiegoś 20-bitowego licznika. Sprzętowy o takiej rozdzielczości raczej nie istnieje w RPi. Ta wartość jest jednak bez znaczenia dla sterownika silnika bo on tylko rejestruje zbocze narastające. Czy dasz tam 0.055 czy 50.0, to jest bez znaczenia.

Nawet jak ci się uda wygenerować tak wąski impuls to na płytce stykowej i przy twoim okablowaniu (linie długie) zostanie on "zjedzony" przez pojemności pasożytnicze i indukcyjność przewodów, i po prostu nie dotrze do układu TB67S249FTG. Być może oscyloskop coś w tej materii rozjaśni. Najlepiej wypełnienie ustawić na stałe na 50%.

2. "pwm = gpio.PWM(pin, 5000)" nie da się tak z kopyta kręcić z tak dużą zadaną prędkością. Trzeba zacząć łagodnie:

jak powoli zaczniesz rozpędzać silnik to on nie zgubi tak łatwo kroków, ale powyżej pewnej częstotliwości spada mu moment obrotowy i zaczyna je gubić. Poza tym jak dostanie sterownik impuls CLK to przełączy odpowiednio uzwojenie. Wał zaczyna się przemieszczać i jak w trakcie znowu nadejdzie sygnał CLK, to wymusi to ponowne przełączenie uzwojeń i gdy poprzednio wał nie osiągnął docelowego położenia to "szarpnie" go do tyłu i silnik zacznie wydawać dziwne dźwięki.

Spróbuj włączyć dodatkowo mikro-kroki, powinno to zmniejszyć nieprzyjemne dźwięki ale zwiększając prędkość i tak trafisz na "ścianę". Gubienie kroków, rezonans, dziwne odgłosy od silnika, etc.

TB67S249FTG potrzebuje sygnałów DIR i STEP (ENABLE i DMODE mogą być podane na stałe), i na każdy impuls STEP silnik powinien wykonać jeden krok, o ile te impulsy nie są za szybko (bo wtedy silnik nie nadąża). Nie podawaj tam PWM!

Witam
spróbuj uruchomić program sterujący silnikiem na osobnym rdzeniu, żeby inne procesy mu nie przeszkadzały.

Pozdrawiam.

rg6502 napisał:

Powiedział bym nawet że PWM nadaje się 'tak sobie', tzn nadaje się jak interesuje nas stała prędkość obrotu, ale w silniku krokowym raczej chodzi o precyzyjne liczenie kroków przy zmiennej częstotliwości. Z tego też względu nie podniecam się bardzo tym że któryś tam mikrokontroler ma PWM w hardwarze - no co z tego jak nie liczy kroków i nie da się płynnie sterować częstotliwością, bez tych rzeczy nie będzie dobrego pozycjonowania. Na końcu wyjdzie że i tak trzeba zrobić w software a przynajmniej ręcznie oprogramować timery/przerwania.

Nie wiem jakie możliwości ma timer w tym procku, ale niezależnie na czym się to robi, wypadało by żeby hardware wygenerował impuls i przerwę pomiędzy impulsami, a po każdym impulsie przerwanie załadowało nową wartość do rejestru okresu. Kod działający ponad tym wyliczył rampy hamowania i rozpędzania silnika tak aby uzyskać przynajmniej niezawodny przejazd z punktu do punktu i sensowną prędkość (a nie taką z którą silnik da radę bez rozpędzania). Sterownie point-to-point, to jest minimum, gdziekolwiek cokolwiek ma się poruszać z użyciem silnika krokowego, bardziej zaawansowane systemy kontrolują prędkość i trajektorię ruchu wielu napędów pracujących jednocześnie - ale nie będę dobijał leżącego.

Jak uczyłem się programować mikrokontrolery, zrobiłem sterownie silnikiem krokowym z rozpędzaniem i hamowaniem (bez gubienia kroków) udało mi się zrobić na gównianym mikrokontrolerze posadającym 2kB FLASH 128B RAM i wartym 2,5zł, ani ja nie jestem dobrym programistą, ani sprzęt nie był wyjątkowy, ani kodu nie było dużo, ani nie był super-zaawansowny, ani nie pisałem tego przez cały dzień. Nie ma się czym chwalić, to tylko pokazuje w jak bardzo złym kierunku poszły sprawy opisane w tej dyskusji.

RebellionArts napisał:

To co tutaj widzicie z kodu jest do testowania. Po co mam pisać 10 razy więcej linijek w C żeby tylko 'potestować'

Skąd absurdalne założenie że 10x więcej? Prawie identyczny kod (nadal zbyt prymitywny do praktycznego użycia) napisany w C, bez systemu operacyjnego, nie będzie gubił kroków.

Sterowanie silnikami wymaga wiedzy jak długo i kiedy, kod się wykonuje, to jest niskopoziomowe. Masz zadanie wygenerować impuls, długość tego impulsu ma być ściśle określona, a w międzyczasie program ma ustalić długość następnego impulsu, w czasie pracy żadnego impulsu nie można zgubić ani dodać.
To są banalnie proste rzeczy, dopóki nie użyjesz nieodpowiednich narzędzi jakich próbujesz użyć, deterministyczny czas wykonania kodu jest w sprzeczności z działaniem systemu operacyjnego non-relatime oraz Pythona, bo zarówno system może przerwać twój kod przeznaczając czas na inne zadania, jak i sam Python może "uznać" że ma coś ważniejszego do roboty niż twoje instrukcje (np garbage collector).

Mi ten wątek przypomina dyskusję o wbijaniu gwoździ przy użyciu komputera - bo przecież komputer jest lepszym i bardziej uniwersalnym narzędziem niż młotek, więc napieprzanie laptopem w gwóźdź to oznaka wyrafinowania i nowoczesności.

Ja robiłem sterowanie wysyłając impulsy poprzez port szeregowy - on ma 16-bajtowe FIFO, więc nie ma problemu z ciągłością, ale czasy między impulsami muszą być dopasowane do ramek bajtowych - np. początek rampy może być (10), (6, 4), (4, 3, 3), (3, 3, 2, 2), (2, 2, 2, 2, 2)... - w nawiasie podaję czasy między impulsami w ramach jednego bajtu, suma musi być 10 (port ustawiony na 8,N,1, bit start zawsze jest 0, stop zawsze 1, pozostałe 8 zawierają to, co się wyśle).

Według instrukcji to pigpio może takie dokładne kroki generować na pinie. Trzeba wcześniej przygotować wzór, a biblioteka odtwarza go używając chyba DMA. Pigpio wave chain.
Problem taki jak z PWM, że nie można w dowolnym momencie zmienić prędkości albo zatrzymać silnika nie gubiąc położenia, albo nie czekając na zakończenie zadanego cyklu.
Myślę że warto sprawdzić działanie programu na osobnym rdzeniu, zwłaszcza jeśli autor planuje użyć kilku silników.

Panowie i Panie, udało mi się już poniekąd wyjść z sytuacji, okazało się, że wystarczy na zwykłym arduino nadać stan wysoki na pin, poczekać 2000 mikrosekund, nadać niski sygnał i znów 2000 mikrosekund (w pętli), czas odstępu między high/low to nasza prędkość.

Docelowo ma to siedzieć na jakimś AVR. [C]
Nie spodziewałem się, że python będzie miał taką różnicę w impulsach.

jarek_lnx napisał:

Jak uczyłem się programować mikrokontrolery, zrobiłem sterownie silnikiem krokowym z rozpędzaniem i hamowaniem (bez gubienia kroków) udało mi się zrobić na gównianym mikrokontrolerze posadającym 2kB FLASH 128B RAM i wartym 2,5zł, ani ja nie jestem dobrym programistą, ani sprzęt nie był wyjątkowy, ani kodu nie było dużo, ani nie był super-zaawansowny, ani nie pisałem tego przez cały dzień. Nie ma się czym chwalić, to tylko pokazuje w jak bardzo złym kierunku poszły sprawy opisane w tej dyskusji.

jarek_lnx napisał:

To są banalnie proste rzeczy, dopóki nie użyjesz nieodpowiednich narzędzi jakich próbujesz użyć, deterministyczny czas wykonania kodu jest w sprzeczności z działaniem systemu operacyjnego non-relatime oraz Pythona, bo zarówno system może przerwać twój kod przeznaczając czas na inne zadania, jak i sam Python może "uznać" że ma coś ważniejszego do roboty niż twoje instrukcje (np garbage collector).

Mi ten wątek przypomina dyskusję o wbijaniu gwoździ przy użyciu komputera - bo przecież komputer jest lepszym i bardziej uniwersalnym narzędziem niż młotek, więc napieprzanie laptopem w gwóźdź to oznaka wyrafinowania i nowoczesności.

@jarek_lnx Twoje wiadomości, z których można wyciągnąć jakąś wiedzę, są dla mnie bardzo pomocne, z kolei Twoje (nie zbyt miłe) komentarze sugerują raczej to, że się zasiedziałeś na tym forum i pora się wylogować na zawsze. Nie wiem skąd ludzie w Polsce bywają najmniej uprzejmi (głównie w Internecie, mam duży kontakt z innymi osobami z innych krajów), za te swoje wpisy zbanowali by Cię od razu (Github, stackoverflow, ...). A może wielkość poziomu na to pozwala?

RebellionArts napisał:

Docelowo ma to siedzieć na jakimś AVR. [C]
Nie spodziewałem się, że python będzie miał taką różnicę w impulsach.

To niekoniecznie musi być wina Pythona. Moduł, który używasz jest napisany w C ale znaczącą rolę odgrywa sam OS bo np. wywołanie uśpienia gwarantuje jedynie że czas drzemki nie będzie krótszy. Tam w tle działają jeszcze inne procesy, które walczą o zasoby komputera. Na Arduino działa jedynie twój program i nic więcej.

jvoytech napisał:

To niekoniecznie musi być wina Pythona. Moduł, który używasz jest napisany w C ale znaczącą rolę odgrywa sam OS bo np. wywołanie uśpienia gwarantuje jedynie że czas drzemki nie będzie krótszy. Tam w tle działają jeszcze inne procesy, które walczą o zasoby komputera. Na Arduino działa jedynie twój program i nic więcej.

Ktoś o tym pisał właśnie i miał rację, aczkolwiek dziwię się, że działanie innych wątków na OS wpływa na proces wykonywania się programu.

Wydawało mi się, że aż takiej różnicy nie będzie w wysterowaniu impulsów przez OS a przez całkowicie przeznaczony do tego mikrokontroler. Dlatego poszedłem w PWM, a potem wydawało mi się, że w dokumentacji przeznaczenie OSCM niszczy cały przebieg impulsów. No ale prosty program na Arduino imituje już czyste obroty.

Dla tych co chcą mi mówić że python nie da rady na RPi i że 3eba wykorzystać program 'niskopoziomowy' to mają rację i to teraz wiem, docelowo ma to działać na AVR (mam do odebrania jeszcze kilka danych z czujników) i potem po SPI do głównego komputera więc chyba znalazłem wyjście.

Na ten moment zacząłem pracować na innym sterowniku (DRV8825) i inny silnik (200 kroków, poprzedni miał 400) i działa.

Jak wszystko pójdzie gładko z tym TB67S249FTG to dam znać i zamknę temat.

RebellionArts napisał:

Ktoś o tym pisał właśnie i miał rację, aczkolwiek dziwię się, że działanie innych wątków na OS wpływa na proces wykonywania się programu.

Tego typy System Operacyjne rządzą się innymi prawami. Wyrabianie się idealnie w czasie nie jest ich priorytetem, to tego służą RTOSy i na RPi z pewnością można jakiś Linux RTOS znaleźć (LinuxCNC?). Łatwiej jest jednak do tego użyć MCU.

RPi idealnie się nadaje żeby postawić jakiś serwer, żeby można było np. przez aplikację webową wydawać polecenia sterowania silnikiem. RPi wysyłałby poprzez SPI/UART/etc. tylko rozkazy do mikrokontrolera na dodatkowej płytce, a on zajął by się generowaniem sygnałów idealnych czasowo.

jvoytech napisał:

RPi wysyłałby poprzez SPI/UART/etc. tylko rozkazy do mikrokontrolera na dodatkowej płytce, a on zajął by się generowaniem sygnałów idealnych czasowo.

Tak to ma poniekąd działać właśnie.
Wiesz, domyślałem się, że może być problem z powtarzalnością impulsów, napisałem do tego program, który zbierał impulsy wykonane przez zadany czas z odpowiednia prędkością (impuls czyli obrót), przekalkulowałem sobie to na Hz i działa to całkiem dobrze (dla > 35k RPM mam 100%). Program co prawda analizował tylko do milisekund, jak kazałem wykonać mu 5 mln RPM to to to zrobił ale w 99% (zawsze kilka brakowało) co było dziwne bo analizując tylko różnice w czasie do milisekund miał do czynienia z obrotami w mikrosekundach a i tak dał radę. To mi zapaliło lampkę, że program przy sleep(.001) powinien działać bez zarzutu ale jednak....

Ale czym te pomiary wykonywałeś? Czy mierzyłeś tachometrem? 35k RPM (580 obrotów na sekundę) to rzecz nieosiągalna dla silnika krokowego. Przy nieobciążonym wale dojdziesz do 1200RPM (12 obrotów na sekundę) i już będziesz na granicy. Dasz więcej i zacznie już gubić kroki. Jak do wału dołączone jest obciążenie to dwa obroty na sekundę może być granicznym RPM.

Twoje 35k RPM (580 RPS) oraz silnik z 400-oma krokami potrzebuje 230 tys. impulsów na sekundę! To jest jeden impuls co 4.4μs. Jeżeli impuls trwa 2.2μs i musi przejść po długich przewodach z wielką pętlą masy od RPi do drivera to może się okazać że są tam tak duże zakłócenia, że niektóre będą się gubić, ale trzeba by sprawdzić oscyloskopem co się tam dzieje. Na wszelki wypadek trzeba zrobić skrętkę, wziąć pin 12 (GPIO18) oraz sąsiadujący pin 14(GND) i puścić te dwa piny skrętką do drivera. Wtedy pin GPIO18 będzie mieć sąsiadujący przewód powrotny dla tego sygnału i krótkie impulsy będą bardziej strome. To tak od strony zniwelowania zakłóceń i warto o takich rzeczach pamiętać.

Twoje pomiary według mojej opinii są niewiarygodne. Raz piszesz 35k RPM co już jest potwornie dużo, a potem 5mln!? Podłącz oscyloskop do pinów RPi oraz do wejść drivera i pokaż oscylogramy, to się okaże czy takie coś faktycznie ma miejsce.

Wydaje mi się, że przy tak dużej częstotliwości podawania sygnału na SCK drivera, cewki silnika już nie rozróżniają poszczególnych kroków, tylko jako uśrednioną wartość stałą. Tak szybkie sygnały działa jak PWM, tylko że po niewłaściwej stronie.

jvoytech napisał:

35k RPM (580 obrotów na sekundę) to rzecz nieosiągalna dla silnika krokowego.

Zgaduję, że RebellionArts mógł mieć na myśli kroki, albo pełną sekwencję zmian sygnałów (dla 2 cewek bipolarnych bez half-, a tym bardziej mikrostep, to są 4 kroki).

Z mojego doświadczenia przy sterowaniu silnikiem krokowym duża bezwładność w połączeniu z małymi oporami ruchu powoduje problemy z rezonansem - jeśli trafi się z częstotliwością kroków blisko rezonansu, to nie pomoże wyliczenie najbardziej liniowej rampy - blisko rezonansu odchylenia narastają.

_jta_ napisał:

jvoytech napisał:

35k RPM (580 obrotów na sekundę) to rzecz nieosiągalna dla silnika krokowego.

Zgaduję, że RebellionArts mógł mieć na myśli kroki, albo pełną sekwencję zmian sygnałów (dla 2 cewek bipolarnych bez half-, a tym bardziej mikrostep, to są 4 kroki).

A to by się zgadzało, tyle że zamiast RPM powinno być chyba SPM (steps per minute). Podany silnik miał 400 kroków na pełny obrót (mikro kroki zdaje się wyłączone), 35k/400 to by dało 87.5 RPM, czyli wartość łatwo do ogarnięcia przez silnik. Przy 5mln wychodzi 12500 RPM a to zdecydowanie za dużo. Silnik już pewnie nie widzi poszczególnych kroków tylko napięcie uśrednione i to jest jakby PWM tylko od niewłaściwej strony.

Gdyby tak ustawić μkroki na 1/32, to na pełny obrót potrzeba wtedy podać 12800 impulsów na SCK. I wtedy jakby puścić 5mln impulsów na sekundę to by wychodziło około 390 RPM. Silnik powinien chyba sobie poradzić z taką wartością, i to byłby bardziej test dla RPi (albo okablowania i stykówki) czy jest w stanie tyle impulsów przesłać w ciągu sekundy.

_jta_ napisał:

Z mojego doświadczenia przy sterowaniu silnikiem krokowym duża bezwładność w połączeniu z małymi oporami ruchu powoduje problemy z rezonansem - jeśli trafi się z częstotliwością kroków blisko rezonansu, to nie pomoże wyliczenie najbardziej liniowej rampy - blisko rezonansu odchylenia narastają.

Dobrze wiedzieć. Pewnie będzie lepiej przykręcić jakieś cięższe kółko do wału silnika.

Właśnie cięższe kółko (jeśli będzie sztywne i sztywno zamocowane) zwiększy dobroć układu rezonansowego i obniży częstotliwość rezonansu, więc będzie czynnikiem ryzyka...

@_jta_ Cięższe kółko, ze sprzęgłem, zapewniającym suche tarcie - tłumi drgania (widziałem fabryczne rozwiązania), do tego praca mikrokrokowa zmniejsza amplitudę drgań.

Przy odpowiedniej charakterystyce tego tarcia, tak. Tylko jest kwestia, jaki powinien być ten sprzęg, by miał odpowiednią charakterystykę.

Cześć wszystkim aktywnym!

jvoytech napisał:

Ale czym te pomiary wykonywałeś? Czy mierzyłeś tachometrem? 35k RPM (580 obrotów na sekundę) to rzecz nieosiągalna dla silnika krokowego.

Nie pisałem, że podałem to na 'cewki silnika', ogarniam jak działa silnik, cała rzecz w tym że wykonywałem STEP z PRi i nie działało (ten prosty program z pętlą for i sleep). Ale objaśnię: program generuje tyle +R (obrotów) w czasie, zapisuje wynik i pokazuje na koniec ile wykonało przy zadanym RPM. Docelowo program miał wychodzić ze swojej klasy i wykonywać moduł, który to wykonuje ten STEP. Nie podawałem nigdy 5 mln RPM na silnik ani 35 tyś RPM. To były testy samego programu. I te +R wykonywał bardzo precyzyjnie (tak jak pisałem wyżej)

jvoytech napisał:

Twoje 35k RPM (580 RPS) oraz silnik z 400-oma krokami potrzebuje 230 tys. impulsów na sekundę! To jest jeden impuls co 4.4μs.

I testy by trwały nadal, gdyby to działało z programem z postu pierwszego ale nie zadziałało. Oczywiście chciałem później kalibrować że jeden RPM to 200 stepów.... ale podstawowy test nie przeszedł.

jarek_lnx napisał:

Cięższe kółko, ze sprzęgłem, zapewniającym suche tarcie - tłumi drgania (widziałem fabryczne rozwiązania), do tego praca mikrokrokowa zmniejsza amplitudę drgań.

Tak, silnik działa bez obciążenia i raczej te obciążenie nie będzie zbyt duże, więc samo działanie będę wykonywać zapewne na 1/16 kroku lub 1/32

Dodano po 3 [minuty]:

A moglibyście mi wyjaśnić czemu nie powinno się używać sygnału PWM do nadawania STEP?

RebellionArts napisał:

czemu nie powinno się używać sygnału PWM do nadawania STEP?

Bo sterownik (ten TB67S249FTG) potrzebuje sygnału cyfrowego 1 impuls / 1 krok, nie jakiegoś PWM.