[A.....k]

Szybka analiza tego, co wypluwa FlatCam pozwala stwierdzić, że w gkodzie nie pojazują się nawet G2 czy G3 czyli nie trzeba implementować interpolacji kołowej. Tylko ruch po prostej.
Za to #grbl działający na STM32F103 (od chińczyka ofc) potrzebuje jakieś ułamki sekundy, które normalnie widać, żeby np. wyłączyć laser po zakończonym g1. To go zupełnie dyskwalifikuje. Zawsze ostatni wektor na samym końcu będzie mieć losowe nadpalenie (w przypadku pracy z ploterem laserowym). Gówno, krótko mówiąc.
Czy mam alternatywę?
Otóż tym razem mam.
Kiedyś sam sobie napisałem kod do sterowania xy, którym nawet coś tam wyciąłem ale z różnych powodów przestałem się tym zajmować. Za to mam taki kod, napisany już, który czyta Gkod, rozpoznaje znaczną część jego składni (a w interesującym mnie przypadku całą) i wypluwa maszynie współrzędne, po jakich powinna się poruszać (zakładając, że została zbazowana i jest ustawiona w pozycji zerowej). Tych danych jest okropnie więcej niż linijek gkodu ale spowolnienie na ich wykonywaniu jest rzędu nanosekund a nie milisekund. A że i tak chcę przesyłać te dane przez #eth (udp, bufor cykliczny) to nie ma to znaczenia.
Krótko mówiąc zrobie swoje sterowanie #cnc do robienia #pcb.
Zrobię wpisy z postępów a jak ktoś chce śledzić to udostępnię też repo na github.
Interpreter G powstanie w C#, kod na uC w C++ (Na procek ATSAME70B21 na płytce SAME70 Xplained).
#elektronika #arduino