Arduino steruje ploterem.

Nie planowałem takiej funkcji. Bardziej chciałem zaimplementowac obsługę I jesti i J. Ale już mi nie zależy. Nauczyłem sie to w CamBam omijać. chce dodać obsługę wrzeciona i samoczynnie zerwanie osi po włączeniu.
Myślałem o funkcji która przy długich kodach (NP.15000linii ) co jakiś czas , ileś linii sprawdzalaby czy na skutek bledu obliczeń nie pojechały sie parametry.
Zdaje sobie sprawę że kiedyś będę musiał arduino wymienić na coś "normalnego".

ja mam arduino due... ale dla arma nie ma biblioteki stepper - więc zamieszczony programik nie kompiluje się
Arm to już zapewne coś

baxter12 pisze:"normalnego"

Bez uwzględnienia przyspieszeń i zwolnień mocno obniżasz wydajność pracy. Może przy dużej ilości krótkich linii G0 będzie to mniej widoczne, ale jak masz dużo przejazdów G1 to frezowanie będzie trwało wieki.

nie przeanalizowałem dokładnie kodu...
ale odnoszę wrażenie, że przyśpieszenia to kwestia programu zewnętrznego... ten odlicza impulsy dla określonej prędkości

a... jeszcze jedno --- czy ten kod nie traktuje oś Z inaczej niż XY dla kodu G1?
mi wydawało się że pozycji z (x0,y0,z0), polecenie G1 x1y1z1 powinno wygenerować ścieżkę w postaci odcina łączącego punkty (0,0,0) i (1,1,1)

kod dotyczący Z wykonuje przesunięcie dla osi Z "górką"

Oś Z jest traktowana inaczej. Najpierw wykonujemy polecenie dla osi Z, a potem wypadkową ruchów X i Y. Tak być musi bo to nie jest frezarka 3D. Ma zdejmować materiał warstwa po warstwie. Gdyby było inaczej to przy frezowaniu np. kieszeni wyszła by pochyla płaszczyzna.
Tak to sobie wymyśliłem.
A odnośnie przyspieszenia. Nie bardzo wiem jak to zrobić prędkość. Nie no dobra już wymyśliłem.
Od kroku 1 do kroku końcowego co jeden krok.
od kroku 1do np. 10 zwieksz prędkość do max.
zrób krok
pętla
Jeszcze tylko nie wiem jak zahamować.
już wiem
jeżeli krok równą sie krok końcowy minus 10 zmniejsz prędkość . potem 9 itd...

markcomp77 pisze:odnoszę wrażenie, że przyśpieszenia to kwestia programu zewnętrznego... ten odlicza impulsy dla określonej prędkości

Raczej nie, bo program zewnętrzny wysyła np. G0 x50 y100 z10 i tyle a program w arduino musi już rozbić to na impulsy dla silników.

baxter12 pisze:A odnośnie przyspieszenia. Nie bardzo wiem jak to zrobić prędkość. Nie no dobra już wymyśliłem.
Od kroku 1 do kroku końcowego co jeden krok.
od kroku 1do np. 10 zwieksz prędkość do max.
zrób krok
pętla
Jeszcze tylko nie wiem jak zahamować.
już wiem
jeżeli krok równą sie krok końcowy minus 10 zmniejsz prędkość . potem 9 itd...

Musisz najpierw zdefiniować prędkości maksymalne dla silników i przyspieszenia/opóźnienia. Małe przypomnienie z fizyki z podstawówki się przyda. Trzeba posortować przyspieszenia silników, które aktualnie biorą udział w ruchu i wybrać te najmniejsze, bo ono będzie determinowało ruch pozostałych. Silniki muszą interpolować linię, więc te żwawsze nie mogą pogonić szybciej - muszą się dopasować do niego. Z tego przyspieszenia trzeba policzyć przyspieszenie ruchu interpolowanego. Dzięki niemu możesz policzyć w jakim czasie frez rozpędzi się do prędkości zadanej w parametrze F. Trzeba sprawdzić czy podczas rozpędzania nie przekroczy połowy drogi, bo to będzie oznaczać, że nie rozpędzi się do prędkości zadanej i od połowy będzie musiał zwalniać (czyli czas przyspieszania będzie skrócony). Masz już czas w jakim musisz zwiększać prędkość wszystkich silników, w jakim będą hamować i jeśli rozpędzanie trwało krócej niż połowa drogi to czas prędkości stałej. Trzebaby tu jeszcze wcześniej sprawdzić, czy przypadkiem jakaś oś nie przekroczy, podczas przyspieszania, zdefiniowanej dla siebie prędkości maksymalnej, bo to będzie moment ograniczający czas przyspieszania (oprócz granicy połowy drogi - zależy co wyjdzie wcześniej).

To jest wariant uproszczony sterowania, bo w takim układzie silniki będą kreślić linie "skacząc żabką". Trzeba dodać do tego jeszcze sprawdzanie czy wszystkie osie jadą w jedną stronę przy następnej linii, bo wtedy nie trzeba zwalniać do zera, tylko jedziemy dalej. Generalnie, najlepiej zrobić z wyprzedzeniem analizę iluś tam wektorów, żeby uzyskać płynny ruch, zgodny zapisem w kodzie.

Wsadzę mały kijek w koło... ku przestrodze...

W ten sposób łatwo wpadniesz w pułapkę gdy odległość ruchu będzie krótsza niż ramp-up i ramp-down.

Argument z odmiennym traktowaniem osi Z również mało praktyczny - akurat wejścia po krzywej się czasami stosuje... gdybyś napisał, że to pod ploter gdzie tylko dwa poziomy są, to bym się zgodził, że "ok".

Rozpędzanie się i hamowanie osi jest trochę bardziej skomplikowane - nie możesz tego liczyć na krokach a na odległości do pokonania.

Nie mam linka w głowie, ale był cały wątek na temat rampy na arduino - znajdziesz tam dużo informacji.

ezbig pisze:

markcomp77 pisze:przyśpieszenia to kwestia programu zewnętrznego... ten odlicza impulsy dla określonej prędkości

Raczej nie, bo program zewnętrzny wysyła np. G0 x50 y100 z10 i tyle a program w arduino musi już rozbić to na impulsy dla silników.

arduino rozbija na impulsy.. tak
ale dobrze aby serię kolejnych poleceń gcodu kontroler ruch (komp+arduino), traktował jako trasę przejazdu (w machu nazywa się to constant velocity)... gdyby arduino każdą linie traktował z przyśpieszaniem i hamowaniem - to wyszło by zatrzymywanie po każdej linii

dlatego - to PCet powinien decydować o przyśpieszeniach i hamowaniach -- bo to on zna cały gcode do wykonania...

oczywiście... tak pewnie to powinno wyglądać, a jak to jest dokładnie w tej realizacji wciąż się tylko domyślam

[ Dodano: 2013-09-09, 21:41 ]

Raven pisze:temat rampy na arduino

kolega pitsa dużo na ten temat napisał tutaj:
https://www.cnc.info.pl/topics65/rampa- ... t35799.htm

Musisz najpierw zdefiniować prędkości maksymalne dla silników i przyspieszenia/opóźnienia.
To jest logiczne. Zawsze trzeba ustalić gdzie są maksymalne możliwosci maszyny.
Małe przypomnienie z fizyki z podstawówki się przyda.
Bez komentarza.
Trzeba posortować przyspieszenia silników, które aktualnie biorą udział w ruchu i wybrać te najmniejsze, bo ono będzie determinowało ruch pozostałych. Silniki muszą interpolować linię, więc te żwawsze nie mogą pogonić szybciej - muszą się dopasować do niego.
Nie bardzo, u mnie jest to rozliczone na kroki, krok jest zawsze taki sam, zmienia sie tylko prędkość wykonania kroku.
Z tego przyspieszenia trzeba policzyć przyspieszenie ruchu interpolowanego. Dzięki niemu możesz policzyć w jakim czasie frez rozpędzi się do prędkości zadanej w parametrze F.

Trzeba sprawdzić czy podczas rozpędzania nie przekroczy połowy drogi, bo to będzie oznaczać, że nie rozpędzi się do prędkości zadanej i od połowy będzie musiał zwalniać (czyli czas przyspieszania będzie skrócony). Masz już czas w jakim musisz zwiększać prędkość wszystkich silników, w jakim będą hamować i jeśli rozpędzanie trwało krócej niż połowa drogi to czas prędkości stałej. Trzebaby tu jeszcze wcześniej sprawdzić, czy przypadkiem jakaś oś nie przekroczy, podczas przyspieszania, zdefiniowanej dla siebie prędkości maksymalnej, bo to będzie moment ograniczający czas przyspieszania (oprócz granicy połowy drogi - zależy co wyjdzie wcześniej).
Prędkość maksymalna jest zdefiniowana wiec nie ma prawa wzrastać bez ograniczeń. z tego co napisałem wyżej wynika że może wzrastać o rózne wartości dla każdej osi (dot. mojego programu). A jeżeli chodzi o hamowanie to po prostu w pętli musi mieć wyższy priorytet i hamowanie przerywa przyspieszanie.
Będę miał kilka godzin czasu to zamienię to na kod, choć na tej maszynie która mam obecnie to... i tak jej nic nie pomoże... Musze zbudować cos prawdziwego.
Wiem że może inne programy obsługujące CNC w inny sposób "rozliczaja" ścieżkę do pokonania w osiach X i Y, a właściwie ich wypadkową. Ja z moja marną znajomością zasad programowania, oraz ze znajomością fizyki wyniesiona z technikum oraz borykając sie z takimi a nie innymi komendami dostępnymi w interpreterze Arduino. Przyjąłem że kroki rozliczam "odległościowo". Wymyślenie algorytmu podiału tych kroków zajęło mi tydzień. Jest skuteczny, krok ma 0.005mm, a obliczenia wykonuje do 6 miejsca po przecinku.

markcomp77 pisze:arduino rozbija na impulsy.. tak
ale dobrze aby serię kolejnych poleceń gcodu kontroler ruch (komp+arduino), traktował jako trasę przejazdu (w machu nazywa się to constant velocity)... gdyby arduino każdą linie traktował z przyśpieszaniem i hamowaniem - to wyszło by zatrzymywanie po każdej linii

dlatego - to PCet powinien decydować o przyśpieszeniach i hamowaniach -- bo to on zna cały gcode do wykonania...

oczywiście... tak pewnie to powinno wyglądać, a jak to jest dokładnie w tej realizacji wciąż się tylko domyślam

Masz rację, ale jak wysyłasz gkody do sterownika to już nie masz możliwości kontrolowania przyspieszeń. Napisałem na końcu, że trzeba badać kierunek obrotów silników, jak się nie zmieniają przy kolejnym wektorze, to nie trzeba zwalniać. Wygodniej jest to zaprogramować na komputerze, bo nie masz wielu ograniczeń. Ja bym zrobił to na zupełnie innej zasadzie. Dane przygotowałbym na komputerze, a mikrokontroler wykorzystałbym tylko do odbierania danych generacji impulsów. Wtedy i atmaga8 się wyrobi.