GRBL dla tokarki

tuxcnc pisze:Masz ten enkoder w GRBL, czy po prostu musisz sobie pogadać?

A co za różnica? Ja napisałem sobie własny sterownik. Mam na myśli, że trudno mi uwierzyć, że jakiś procesor miałby być zdyskwalifikowany tylko ze względu na to, że nie ma sprzętowej obsługi enkodera.

pitsa pisze:czyli jednak wolisż żeby siedzieć cicho? ;-D

To jest znany dualizm tuxa. Ale ja się nie obrażam, wiem, że piszę trochę zaczepnie. Ale, jak to mówią w marketingu, nieważne jak się mówi, ważne, że się mówi

pitsa pisze:Nie widzę całości jak w normalnym linuxcnc i w czym to by mi się mogło przydać.

Obejrzalem sobie ten ponizej filmik i jakiegoś wielkiego zachwytu tam nie widze. Coś tam sie porusza ale do realnej roboty to musi być coś w rodzaju subów plus latwa obsługa wszelkich prędkosci. Bo jak ma byc pisanie każdego Gkodu do każdej roboty to tylko chyba pod CAD albo seryjne roboty a nie codzienne różne roboty.

pitsa pisze: ↑

07 paź 2022, 10:30

W LinuxCNC sprawę prostoty obsługi można załatwić za pomocą subów.

Suby to nie jest sterowanie, tylko CAM.
LinuxCNC jest dość specyficznym rozwiązaniem, wykorzystującym do sterowania obrabiarką komputer klasy PC. To się wydaje oczywiste, ale konsekwencje już niekoniecznie. Na obrabiarce z LinuxCNC można sobie oprócz programu CAM przeglądać Internet, oglądać filmy albo grać w grę... Jednemu to się będzie podobać, inny woli robić to przy biurku...
Istotą GRBL jest oddzielenie komputera z CAM od sterowania obrabiarką, czyli innymi słowami, komputer może stać dalej od maszyny. Nawet bardzo daleko, a do przeniesienia programu na maszynę wystarczy smartfon albo karta SD...
Natomiast wyższość LinuxCNC nie polega na zintegrowaniu takiego czy innego programu CAM, tylko na bardziej zaawansowanym g-kodzie.
No i znowu wracamy do sprawy skomplikowania obsługi. Nie każdy potrzebuje w programie funkcji sinus i nie każdy potrafi jej użyć...

Jeszcze raz napiszę, to co na początku wątku.
GRBL nie nadaje się do tokarki, bo nie obsługuje enkodera wrzeciona, a tokarka bez gwintów to pół tokarki...
Jeżeli GRBL zacznie obsługiwać enkoder wrzeciona i kody G33/G76, to się znajdą chętni żeby go używać na tokarce, bo takie sterowanie zaspokoi ich potrzeby.
Cóż, nie każdy chce do tokarki za trzy tysiące dołożyć sterowanie za drugie trzy tysiące, żeby potem maszyny użyć raz na miesiąc...
I nie każdy ma ochotę dochodzić, dlaczego na jednym kernelu ma jitter 20000 a na drugim 1000000...

pitsa pisze: ↑

07 paź 2022, 10:30

czyli jednak wolisż żeby siedzieć cicho? ;-D

Nie, po prostu nie trawię partaczy, druciarzy i ludzi którzy twierdzą że to co ich przerasta do niczego się nie nadaje.
Wątek jest o GRBL dla tokarki, na STM32F411 i po jasną cholerę ktoś ma tu pisać że sobie zbudował na Arduino coś zupełnie innego, więc mu się wydaje?

A jednak potrwa dłużej...

Przy dodaniu parametrów osi A i B coś się posypało z EEPROM i parametrami $. Niby wszystko działa, ale jakieś kretyńskie komunikaty wyświetla... Trzeba to naprawić.

Znalazłem sposób na testowanie G33/G76 bez fizycznej tokarki.
Dopisałem do fake-encoder dodatkowe wyjścia, dwa bo tyle miałem do dyspozycji, ale i jedno by wystarczyło.
Stan tych dodatkowych wyjść zmienia się co 256 impulsów enkodera (można zrobić dowolną liczbę, ale nie widziałem sensu w tej chwili).
Trzeba jeszcze w pliku <ścieżka>/Libraries/Encoder/Encoder.h zmienić na PULSES_PER_REV 256 i nasze dodatkowe wyjście będzie sygnalizowało pełne obroty wrzeciona. Oczywiście nadal na ATtiny13.

Napisałem testowy g-kod: Nic nadzwyczajnego, trzy razy ruch synchronizowany z wrzecionem i szybki powrót.
Na analizatorze Saleae wygląda to tak:

Białe i brązowe przebiegi pomocnicze z fake-encoder, czerwony DIR, żółty STEP.
Te krótkie pakiety to kasowanie backlash.
Niebieskie markery wstawiałem ręcznie, więc nie są precyzyjne, ale wygląda na to, że synchronizacja jest.
Natomiast mam wrażenie, że synchronizacja obowiązuje tylko w czasie trwania jednego programu, a przy puszczeniu go ponownie może występować w innym położeniu wrzeciona...
Pewny nie jestem, ale i tak będę to musiał sprawdzić, bo jest poważna kicha - parametr K nie działa.
On określa posuw w mm/obr, a właściwiej powinien określać, bo czego by nie wpisać, to i tak jedzie tak samo...
Sprawa niby prosta, gdzieś trzeba posuw przemnożyć przez K, tylko cholera wie gdzie...

Upewniłem się co do enkodera.
Gwintowanie działa tylko w jedną stronę, na lewych obrotach albo z odwrotnie podpiętym enkoderem wychodzą cuda...

Na dzisiaj to tyle.

Postęp...

Szczerze mówiąc miałem już ochotę pieprznąć ten projekt w cholerę, bo szukając błędu w programie kręciłem się jak zwierzak goniący własny ogon...
Albo wszystkie podejrzenia upadały, albo okazywało się, że i owszem błąd był, ale bez wpływu na tę akurat funkcję...

Cóż, problem polegał na tym, że szukałem takiego błędu, jaki sam mógłbym popełnić.
Mogłem sobie szukać tak do usranej śmierci, bo ja bym takiego badziewia nigdy nie napisał...
Szukałem jak igły w stogu siana, gdy nagle do mnie dotarło, że autor użył do zliczania enkodera zmiennej typu uint16_t.
Gdyby ktoś nie rozumiał o co chodzi, to jest to zmienna całkowita bez znaku o długości 16 bitów, czyli na przykład 65535+1=0 (co się nazywa przepełnieniem zmiennej). Nie wdając się w szczegóły, takie przepełnienie może nastąpić już po kilkunastu obrotach wrzeciona (zależy jakiego enkodera użyjemy). Autor programu nieudolnie ominął ten błąd, czego efektem było prawidłowe liczenie tylko w jedną stronę...
Jest to debilizm totalny, bo w STM32 mamy do dyspozycji zmienne typu uint64_t o pojemności 18446744073709551615 co jest liczbą astronomiczną i nawet przeczytać ją trudno.... Wystarczy jako wartość początkową wpisać połowę tej wartości i na przepełnienie zmiennej można się nie doczekać nigdy...

Po poprawieniu kodu enkoder chyba działa prawidłowo, gwintować się da na prawych i na lewych obrotach...

Pozostała kwestia pamięci EEPROM i zmiennych $.
Sprawa jest po prostu upierdliwa, coś działa źle przy zapisywaniu wartości, ale za drugim czy trzecim razem się udaje...
Niby można z tym żyć, ale obciach coś takiego wypuścić w świat...

A ty jeszcze się zmagasz z tym gniotem , Tux idź do lasu na grzyby przynajmniej odpoczniesz od prowizorycznych prototypów które nie spełniają swych podstawowych założeń .