Sterowanie silnikiem krokowym - przyśpieszenie etc.

Na tym forum rozmawiamy o elektronice nie związanej bezpośrednio z tematem CNC
Awatar użytkownika

ursus_arctos
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 5
Posty: 2083
Rejestracja: 11 cze 2011, 18:29
Lokalizacja: Warszawa / Lublin

#11

Post napisał: ursus_arctos » 24 paź 2014, 12:32

widać tu przewagę wiedzy nad sprzętem.
Kolego, to się nazywa insynuacja. Insynuujesz, że Twój rozmówca wiedzy nie ma. Mylisz się. Nie mam natomiast tyle czasu, żeby pieścić 8-bitowy procesor, kiedy mogę użyć czegoś bardziej współczesnego.
z submikronową precyzją numeryczną
Problem w tym, że na serach możesz wykonać efektywnie "skok" o kilka "kroków". Po prostu mówisz "teraz ma być X" i tyle. Napęd ma się dostosować. W przypadku napędu krokowego trzeba wygenerować wszystkie stany pośrednie, Serwomechanizm można sterować ze stałą częstotliwością - powiedzmy, 1kHz. Przy większej prędkości straci się trochę (sporo) precyzji - przykładowo, przy 1m/s korekta będzie co milimetr! - ale w ogóle da się to zrobić, nawet niezależnie od rozdzielczości enkoderów. Jeżeli masz silnik krokowy ustawiony na 200kroków/mm, to przy 1m/s trzeba generować impulsy z częstotliwością 200kHz. Z80 tego nie zrobi. AVR tego nie zrobi. Procesor taktowany 100MHz zrobi to z łatwością.



Tagi:


Autor tematu
bmajkut
Specjalista poziom 1 (min. 100)
Specjalista poziom 1 (min. 100)
Posty w temacie: 9
Posty: 284
Rejestracja: 02 lis 2012, 18:59
Lokalizacja: Wrocław

#12

Post napisał: bmajkut » 24 paź 2014, 12:37

Mam akurat na biurku Discovery stm32F4 :) Z tego co czytałem to właśnie nie musi być procek z FPU bo wszystkie operacje można przybliżać i najprawdopodobniej w starszych konstrukcjach tak to zostało zaprogramowane. Oczywiście jeśli założę sobie że Gcode będzie w pamięci przechowywany to lepiej już skorzystać z tego stm'a bo nie jest drogi a taktowanie bardzo duże.
Wielu korzysta z MACH'a albo LinuxCNC i teraz zacząłem się zastanawiać czy te programy są wyposażone w taki system przewidywania tego co będzie za chwilę, chodzi mi o te łuki itd. Jeśli tak to faktycznie poprzeczka postawiona jest wysoko i zagadnienie nie jest trywialne.
Szczerze mówiąc byłbym wielce zadowolony gdyby udało mi się stworzyć coś na wzór PikoCNC lub sterownika takiego jaki jest w reprapie.

Awatar użytkownika

ursus_arctos
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 5
Posty: 2083
Rejestracja: 11 cze 2011, 18:29
Lokalizacja: Warszawa / Lublin

#13

Post napisał: ursus_arctos » 24 paź 2014, 12:58

Wielu korzysta z MACH'a albo LinuxCNC i teraz zacząłem się zastanawiać czy te programy są wyposażone w taki system przewidywania tego co będzie za chwilę
Trudno powiedzieć. Ale skoro taki "amator" jak ja to zaimplementował, to raczej bardziej profesjonalne narzędzia też to mają.


mc2kwacz
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 12
Posty: 2920
Rejestracja: 27 maja 2013, 22:18
Lokalizacja: gdzieś

#14

Post napisał: mc2kwacz » 24 paź 2014, 14:11

Nic nie insynuuję. twierdzę tylko, że jak się wie jak i nie ma innego wyjścia, to można zrobić w elektronice niemalże wszystko ze wszystkiego. A jeśli się nie wie, to wtedy pozostaje rozwiązanie siłowe.

Kiedy się projektuje jakieś urządzenie, to zaczyna się od koncepcji. W skład koncepcji wchodzi ustalenie zakresu możliwości urządzenia. I już na tym etapie zasadniczo wybiera się rozwiązanie minimalne. Jeśli się to zrobi dobrze, to sam projekt jest formalnością. A jeśli się nie zrobi dobrze, to przedsięwzięcie może zakończyć się klapą.
raczej nie zachodzi potrzeba, żeby urządzenie które obrabia z prędkością 1m/s dysponowało jednocześnie chirurgiczną precyzją w każdym punkcie.

P.S.
Nie należy się wysilać i umartwiać, kiedy nie ma takiej potrzeby. Ale spokojnie rozpędzę zwykły napęd na silniku krokowym płynnie i płynnie wyhamuję co do kroku, osiągając w przelocie 200kHz step współczesnym procesorem 8-bitowym, wewnętrznie taktowanym 1-2MHz za ledwie. I wcale się przy tym nie napracuję.
Byle napęd dał radę :)

P.S.2
Sterownik CNC MUSI analizować co najmniej jedną (w praktyce co najmniej 2-4) linie komend do przodu w całości. Choćby dlatego, że inaczej nie będzie w stanie zrobić prostej korekty promienia ostrza. A do tego dochodzi jeszcze choćby tylko analiza pola roboczego, czyli nadzorowanie bezpieczeństwa, co dobre sterowania posiadają wbudowane.


Autor tematu
bmajkut
Specjalista poziom 1 (min. 100)
Specjalista poziom 1 (min. 100)
Posty w temacie: 9
Posty: 284
Rejestracja: 02 lis 2012, 18:59
Lokalizacja: Wrocław

#15

Post napisał: bmajkut » 24 paź 2014, 15:35

Wygenerowanie przebiegu o częstotliwości 200 kHz nie jest problemem przy użyciu avr. Problemem może być aktualizacja danych z taką częstotliwością czyli wczytywanie kolejnych linii kodu i ich interpretacja.
Oczywiście nie ma sensu ograniczać się do avr skoro za 30 zł można kupić procek o zdecydowanie większych możliwościach.
Może nie odbiegajmy od tematu.
Jak w końcu powinien wyglądać mechanizm aktualizacji odstępu pomiędzy następnymi impulsami? Być może dzisiaj wieczorem siądę do tego i spróbuje coś napisać.

Awatar użytkownika

ursus_arctos
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 5
Posty: 2083
Rejestracja: 11 cze 2011, 18:29
Lokalizacja: Warszawa / Lublin

#16

Post napisał: ursus_arctos » 24 paź 2014, 16:21

Kiedy się projektuje jakieś urządzenie, to zaczyna się od koncepcji. W skład koncepcji wchodzi ustalenie zakresu możliwości urządzenia. I już na tym etapie zasadniczo wybiera się rozwiązanie minimalne
Minimalizuje się koszt. Jak urządzenie ma być produkowane w milionach sztuk, to owszem, tak się robi. Jak mówimy o pojedynczych setkach czy nawet sztukach, to zwyczajnie bardziej opłaca się wziąć nieco przewymiarowany hardware i mieć święty spokój.
spokojnie rozpędzę zwykły napęd na silniku krokowym płynnie i płynnie wyhamuję co do kroku, osiągając w przelocie 200kHz step współczesnym procesorem 8-bitowym, wewnętrznie taktowanym 1-2MHz za ledwie
Na jakiej krzywej? Bo na prostym odcinku to faktycznie nie problem. Cały czas przypominam, że mówimy tu o "mądrym" sterowniku, a nie głjupawce jakiejś, która wymaga podawania prostych odcinków


mc2kwacz
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 12
Posty: 2920
Rejestracja: 27 maja 2013, 22:18
Lokalizacja: gdzieś

#17

Post napisał: mc2kwacz » 24 paź 2014, 16:28

Wygenerowanie przebiegu o częstotliwości 200 kHz nie jest problemem przy użyciu avr. Problemem może być aktualizacja danych z taką częstotliwością czyli wczytywanie kolejnych linii kodu i ich interpretacja.
A dopiero co pisałem o stosowaniu rozwiązań siłowych, gdy zrozumienia zagadnienia i pomysłów brakuje :)
Oczywiście nie ma sensu ograniczać się do avr skoro za 30 zł można kupić procek o zdecydowanie większych możliwościach.
Za 300zł można kupić peceta a za kolejne 300 gotowy sterownik, idąc tym tokiem rozumowania. I problem rozwiązany w kilka godzin :)
Jak w końcu powinien wyglądać mechanizm aktualizacji odstępu pomiędzy następnymi impulsami? Być może dzisiaj wieczorem siądę do tego i spróbuje coś napisać.
Obawiam się że pytasz o coś co musisz już zrobić sam ;) W innym przypadku będziesz musiał być już do końca za rękę prowadzony i z konstruktora zostaniesz zredukowany do wykonawcy cudzych pomysłów, z zerowymi zasługami.

Awatar użytkownika

ursus_arctos
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 5
Posty: 2083
Rejestracja: 11 cze 2011, 18:29
Lokalizacja: Warszawa / Lublin

#18

Post napisał: ursus_arctos » 24 paź 2014, 16:59

bmajkut:
Popatrz na to tak: im szybciej maszyna jedzie, tym prostsze odcinki robi. To logiczne, bo przyśpieszenia, które są wymagane do przejścia trajektorii o zadanym kształcie rosną do kwadratu prędkości.
Wniosek: możemy przybliżać prostymi odcinki o stałym czasie trwania (nie mylić ze stałą długością).
Dowcip w tym, że musisz mieć przygotowane parametry timera na zapas - zawsze jeden fragment do przodu, żeby po zakończeniu wykonania poprzedniego segmentu natychmiast podmienić parametry (przeliczyć nie zdążysz).
Aktualna pozycja to X0, pozycja w czasie (teraz+T) to X1.
Przygotowujesz dir = X1>X0 (albo odwrotnie, zależy od konfiguracji osi)
okres impulsów t = T/abs(X1-X0)
faza impulsów to bardziej złożony problem, teraz jestem w pracy i nie będę się rozpisywał.
generalnie, po osiagnięciu czasu T0 szybko ustawiasz powyższe parametry i przeliczasz nowe dla czasu T2. Koniec filozofii. Jest to przybliżenie, ale całkiem znośne. Używa hardwarowego timera. Czy oprogramujesz to bez oscyloskopu? Nie wiem, może są jakieś wirtualne oscyloskopy do emulatora.


mc2kwacz
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 12
Posty: 2920
Rejestracja: 27 maja 2013, 22:18
Lokalizacja: gdzieś

#19

Post napisał: mc2kwacz » 24 paź 2014, 18:03

ursus_arctos pisze:Minimalizuje się koszt. Jak urządzenie ma być produkowane w milionach sztuk, to owszem, tak się robi. Jak mówimy o pojedynczych setkach czy nawet sztukach, to zwyczajnie bardziej opłaca się wziąć nieco przewymiarowany hardware i mieć święty spokój.
Nie zrozumieliśmy się. Mnie chodziło o rozwiązanie minimalne, czyli takie które spełnia warunki. czyli takie poniżej którego nie można zejść, bo projekt się nie uda. A czy zrealizuje się rozwiązanie minimalne, czy z zapasem i z jakim, to już zależy. I wcale nie jest tak, przy współczesnych procesorach ze specjalizowanymi peryferiami, że większy oznacza lepszy i łatwiejszy do realizacji zadania. Powiem więcej - coraz częściej tak nie jest. W ramach układów tego samego producenta oczywiście i tej samej rodziny, bo inne zestawienia w ogóle nie mają sensu.
Na jakiej krzywej? Bo na prostym odcinku to faktycznie nie problem. Cały czas przypominam, że mówimy tu o "mądrym" sterowniku, a nie głjupawce jakiejś, która wymaga podawania prostych odcinków
Oczywiście że na prostym odcinku. I nie wiem czy taki "nie problem", ile osób sobie by z tym poradziło ;) W Piko, który wg Twojej nomenklatury jest tylko głupawką, potrafiącą co najwyżej jechać po okręgu, siedzi procesor z 32 bitowym rdzeniem ARM zasilanym ze skalowanego PLL.
Mówię o częstotliwości zegara napędzającego rdzeń a nie o cyklu maszynowym czy tym bardziej rozkazowym. O ile mi wiadomo, np w AVR jest standardowo PLL, który mnoży częstotliwość taktującą dla rdzenia przez 4. Tak więc w przypadku AVR mówimy o taktowaniu nie przed a na wyjściu PLL. I w tym momencie już nie jest tak łatwo ;)
Ale nie ważne. Ważne żeby nazywać problemy konkretnie i precyzyjnie. Bo jeśli najpierw mówisz o rozpędzaniu silnika do 1m/s z częstotliwością step 200kHz, a w chwilę potem o pełnym sterowaniu maszyną, jeszcze może z obsługą grafiki w kolorze, symulacji i systemu zabezpieczeń, to nie jest to takie samo zadanie? :lol:


Autor tematu
bmajkut
Specjalista poziom 1 (min. 100)
Specjalista poziom 1 (min. 100)
Posty w temacie: 9
Posty: 284
Rejestracja: 02 lis 2012, 18:59
Lokalizacja: Wrocław

#20

Post napisał: bmajkut » 24 paź 2014, 22:32

mc2kwacz pisze:
Wygenerowanie przebiegu o częstotliwości 200 kHz nie jest problemem przy użyciu avr. Problemem może być aktualizacja danych z taką częstotliwością czyli wczytywanie kolejnych linii kodu i ich interpretacja.
A dopiero co pisałem o stosowaniu rozwiązań siłowych, gdy zrozumienia zagadnienia i pomysłów brakuje :)
Oczywiście nie ma sensu ograniczać się do avr skoro za 30 zł można kupić procek o zdecydowanie większych możliwościach.
Za 300zł można kupić peceta a za kolejne 300 gotowy sterownik, idąc tym tokiem rozumowania. I problem rozwiązany w kilka godzin :)
Jak w końcu powinien wyglądać mechanizm aktualizacji odstępu pomiędzy następnymi impulsami? Być może dzisiaj wieczorem siądę do tego i spróbuje coś napisać.
Obawiam się że pytasz o coś co musisz już zrobić sam ;) W innym przypadku będziesz musiał być już do końca za rękę prowadzony i z konstruktora zostaniesz zredukowany do wykonawcy cudzych pomysłów, z zerowymi zasługami.
Dziwnie rozumujesz. Sterownik z trzema driverami to koszt procka i trzech driverów. Skoro procek koszuje ok 30 zł i drivery ok 200 - 400 zł to wychodzi to taniej niż drivery i PC.
Niestety bez oscyloskopu faktycznie taka zabawa nie ma sensu bo i tak niczego nie będę wiedział na pewno tylko na macajewa.
Będę musiał jeździć na uczelnię i próbować ;)

ODPOWIEDZ Poprzedni tematNastępny temat

Wróć do „Elektronika ogólna”