markcomp77 pisze:hehe... 20lat temu to i ja programowałem... ale w Z80 (wiadomo - spektrum, ca80 itd)

No to sami swoi Ja też bawiłem się na Z80, a i ZX-80 oraz Elwro 800 junior wpadł mi w ręce.

baxter12 pisze:Wtedy Amiga była moją miłością. Na Amosie cały program do obsługi firmy popełniłem.

Amigi też później miałem 600 i 1200, a w Amosie gierkę pisałem z kolegą, ach ile człowiek miał wtedy czasu na hobby. Nie to co teraz

baxter12 pisze:zdawłem sobie sprawę ŻE NIE DA SOBIE RADY, no bo niby dlaczego WSZYSCY przenosza obliczenia do kompa?

Może trochę z lenistwa, bo tu trzeba trochę podejścia jakie było dawniej (jak komputery były dosyć wolne i trzeba było sobie radzić). Ja kiedyś programowałem dużo w asemblerze. Co prawda było to ze 20 lat temu na Atari 65XE. Teraz na mikrokontrolerach już mi się nie chce, ale czasem jeszcze jakąś wstawkę popełnię w asemblerze. Akurat problem szybkiego kreślenia linii miałem rozwiązany jeszcze na Atari - bo stadnardową procedurą systemową nie dało się animacji 3D robić (takie tam sześciany latające, nie to co teraz widzisz na komputerach - 6502C miał zegar 1,77MHz!).

W twoim przypadku trzebaby własną bibliotekę do generowania impulsów napisać. Nie wgłębiałem się w twój kod, a to przecież sam początek

baxter12 pisze:Małe przypomnienie z fizyki z podstawówki się przyda.
Bez komentarza.

baxter12 chyba jakoś opatrznie to zrozumiałeś. Chciałem tylko pokazać, że to jest proste i warto to uwzględnić.

baxter12 pisze: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.

To nie ma żadnego znaczenia, czy na kroki, czy na metry. Z tą fizyką to tylko analogia, nie dosłownie.

Pokazałem Ci jak ja bym się za to zabrał. To twój program, ty tu rządzisz

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.

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.

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.

Pobieżnie patrząc, nie widzę abyś uwzględnił przyspieszanie i zwalnianie silników. Masz zamiar to wprowadzić?

baxter12 pisze:Wiem że raczej sie nikomu nie przyda, ale chciałem sie pochwalić i pokazać że tez można.

Chyba nikt w to nie wątpi, że można