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 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.

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?

Avalyah pisze: ↑

07 paź 2022, 09:28

Ja tam obsługuję sobie enkoder na arduino uno w tokarce, enkoder 400 imp o ile dobrze pamiętam, z czego wykorzystuję go do gwintowania, więc czytam 1600 imp na obrót. Tokarka rozkręca się do 2200 rpm i nie przekracza to możliwości tego jakby nie było mało potężnego procka. A do odczytywania impulsów używam zwykłego przerwania na pinie.

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

IMPULS3 pisze: ↑

06 paź 2022, 19:39

A czego się spodziewasz skoro coś tam sam sobie dłubiesz i meldujesz o problemach. Skoro nikt więcej tego nie robi to znaczy że czekamy na efekt końcowy. Jak coś pokażesz to pewnie odzew będzie jakis większy. Póki co to nic poza problemami nie widać. Pokaż finał a najlepiej nagraj filmik jak czymś sterujesz wtedy będzie widać czy warto czy nie.

Widzisz, to nie jest rozwiązanie z kategorii "wziąć i użyć".
Albo dzieło przerosło autora, albo po prostu nie ma on czasu.
Większość kodu ma dwa lata, tylko kilka plików zmieniono osiem miesięcy temu i jest to opisane jako zrobienie porządków...
Natomiast program ma ogromny potencjał, bo użyto narzędzi odpowiednich do zadania. STM32F411 ma sprzętową obsługę enkodera, więc da się na nim robić rzeczy niewykonalne choćby na ESP32, który jest potężniejszy, ale akurat do tego się nie nadaje.
Owszem w kodzie jest sporo bałaganu, część funkcji rozbabrano i porzucono w połowie, ale sto razy łatwiej ten burdel posprzątać, niż zaczynać wszystko od zera...
Nie ma budżetowego sterowania do tokarki "zamontuj i tocz".
Jest LinuxCNC, program dobry, ale skomplikowany w konfiguracji i nie każdy sobie poradzi.
Wiem, można sobie kupić jakieś tam Piko, Mach3 albo SZGH, ale to koszt od tysiąca PLN w górę...
Natomiast STM32F411CCU6 w Polsce kosztuje 50 PLN...
Natomiast co do mojego dłubania, to są duże postępy i już za kilka dni powinna być gotowa wersja do testów na maszynie.
Po prostu myślałem, że zainteresowanie będzie większe...

A szlag by to trafił...
Najpierw pół dnia próbowałem uruchomić oś C, działy się cuda i w końcu dałem sobie spokój...
Potem cały dzień usiłowałem uruchomić bazowanie osi A i B, coś się działo, ale na koniec wywalało błąd...
Zupełnie przypadkiem zauważyłem, że częstotliwość impulsów STEP na A i B jest zupełnie z sufitu i nie reaguje na zmiany ustawień...
W końcu się wyjaśniło...
Szukałem przyczyny w kodzie, a winny był EEPROM.
Ustawienia ewidentnie zostały z Arduino, chociaż STM32F411 ma od cholery pamięci i nie trzeba się kisić w jednym kilobajcie...
Ustawione było maksimum 100 zmiennych , zmieniłem na 255 i zaczęło działać, ale dla pewności zwiększyłem pojemność EEPROM do 2 kB, żeby się znowu nie zdziwić...
Teraz już chyba nic nie powinno mnie zaskoczyć i wreszcie przygotuję kod gotowy do testów na maszynie...

Widzę ogromne zainteresowanie tematem...
W tematach o tym że Kaczyński jest winny 17% inflacji w Niderlandach wszyscy mają coś do powiedzenia, a tutaj chyba raptem kilka osób zagląda...
Mnie to akurat nie zraża, bo sterownik robię dla siebie, ale to nie najlepiej świadczy o tym forum...

Sprawy poszły naprzód...

Uruchomiłem oś B.
Niby wiedziałem co nie działa i gdzie szukać przyczyny, ale gapiłem się w kod jak sroka w gnat i nie widziałem rzeczy oczywistej...
Otóż kiedy ja komentuję jakiś fragment kodu, to stawiam znaki komentarza na początku linii, żeby od razu rzucały się w oczy.
Autor programu ma natomiast głupią manierę przyklejania ich do kodu...
W edytorze bez kolorowania składni można // nie zauważyć, a kolorować nie lubię bo mnie albo razi, albo nie widzę szarego na szarym...
Po jasną cholerę autor zakomentował te linie to mnie nie pytajcie, bo logiczne wytłumaczenie nie istnieje...

Zawiesiłem sprawę enkodera.
Doszedłem do wniosku, że bez sensu jest dłubać w kodzie bez sprawdzenia jak on działa na rzeczywistej maszynie.
Na razie dodałem kilka warunków i G33/G76 działają tylko po M3 z niezerowym S, czyli gwintować da się tylko na prawych obrotach.
Użycie tych kodów po M4 albo S0 wywala błąd i przerywa program.

Dodałem wyjścia pomocnicze i wejścia "wait on input".
Trochę po chamsku wcisnąłem je do Gcode.c, co jest rozwiązaniem nieeleganckim, ale prostym, szybkim i działającym.
Są one sterowane kodami M100 i kolejnymi. Na przykład M100 ustawia stan wysoki na wyjściu AUX1, a M101 stan niski.
Natomiast z wejściami jest trochę bardziej skomplikowana sprawa.
Założyłem że mechanizmy włączane wyjściami pomocniczymi potrzebują trochę czasu na zadziałanie (np. siłownik pneumatyczny) i w tym czasie maszyna musi czekać na sygnał potwierdzający wykonanie operacji.
Tak więc np. po kodzie M110 sterowanie czeka np. 10 sekund. Jeśli w tym czasie na wejściu WOI1 (wait on input) pojawi się stan niski, to przerywa czekanie i wykonywana jest następna komenda. Jeśli się natomiast nie doczeka, to wywala błąd i przerywa program. Na razie czas oczekiwania jest ustawiany na sztywno przed kompilacją programu i nie ma możliwości podania go w postaci parametru, ale w sumie to chyba ma małe znaczenie...

Chcę zrobić porządek z komunikatami błędów. Pamięci jest od cholery, więc bez sensu jest wyświetlanie w rodzaju "error:7" i szukanie potem w dokumentacji co to znaczy...
Mają być komunikaty z pełnymi opisami.
Do tej roboty inteligencji wielkiej nie potrzeba, natomiast sporo czasu i chęci, więc może to potrwać.

Kilku spraw po prostu nie wiem...
Po dodaniu sygnałów pomocniczych na Black Pill zrobiło się chytro z pinami.
Z czegoś po prostu trzeba zrezygnować....
O przetrwanie walczą: oś C, limity A,B,C i sygnały pomocnicze...
Wszystko na raz się nie zmieści, trzeba by ustalić jakąś optymalną konfigurację...

Z STM32F401CCU6 (401 nie 411) zaczynam się coraz bardziej zastanawiać czy warto.
Produkować tych sterowań nie mam zamiaru, a walka jest o dwadzieścia PLN na sztuce...
Formalnie to ta robota się nie opłaci...

Kod opublikuję kiedy uznam że jest gotowy do testów na rzeczywistej maszynie.

Trochę lipa z tym g33.
Otóż enkoder liczy tylko w jedną stronę.
Znaczy się licznik TIM4 liczy w obie, ale przepełnienia są tylko dodawane, niezależnie od kierunku obrotów.
Mówiąc w skrócie, toczyć można tylko na prawych albo tylko na lewych obrotach, zależnie jak podłączymy piny enkodera.
W "złym" kierunku dzieją się cuda.

Chyba będzie z tym sterowaniem sporo roboty, zanim wszystko zacznie działać jak powinno...

Jest postęp !!!

Przy okazji coś się wyjaśniło...

Zacznijmy od fake-ecoder: Skompilowane na Arduino IDE z "płytką" microcore.
Daje piękną kwadraturę o częstotliwości około 250 Hz, stan niski na PB2 blokuje "zliczanie".
PB0/PB1 ATtiny13 podpięte pod PB6/PB7 Black Pill, PB2 ATtiny13 podpięte pod wyjście SPINDLE_ENABLE Black Pill, tu nie podaję numeru pinu, bo można go różnie skonfigurować, natomiast piny enkodera są przypisane na sztywno.
Trzeba mieć ustawione $33=1 (LATHE_MODE), inaczej G33 wywali "unsuported code" czyli "error 20".
Teraz, jeśli wrzeciono stoi (M5), to G33 Z3 K1 wywala "error 8". Sensu to nie ma żadnego, ale widocznie autor programu nie miał lepszego pomysłu...
Potem dałem M3 S1000, co zmieniło stan wyjścia SPINDLE_ENABLE i fake-encoder ruszył.
Teraz po G33 Z3 K1 wyświetla najpierw "HOLD" a potem "RUN" i jedzie... (Używam bCNC, co tutaj ma drugorzędne znaczenie).

No więc na pewno sterowanie nie używa sygnału INDEX, tylko go sobie tworzy z jakiejś wartości licznika TIM4, zliczającego impulsy enkodera.
Nie jestem w stanie sprawdzić co będzie kiedy w programie wykonamy kilka razy G33, czy się będzie synchronizować w tym samym miejscu, czy za każdym razem gdzieś indziej, ale ponieważ jest to sprawa programowa, więc na pewno da się to zrobić tak, żeby było dobrze.
Natomiast na pewno, synchronizacja po wyłączeniu zasilania zostanie utracona i po następnym włączeniu maszyny wystąpi w przypadkowym położeniu wrzeciona. Myślę że z tym to da się żyć...

Walczę uparcie, ale kończą mi się pomysły...
W programie jest straszny burdel, a do tego autorskie wizje...
No na przykład w pliku nagłówkowym są deklaracje pinów wejściowych, a programie piny przypisane na sztywno.
Nie czepiam się "zwykłych błędów", jakie się mogą każdemu przydarzyć, tylko bałaganiarstwa, kiedy jakąś poprawkę przerywa się w połowie i zaczyna następną...
Czytanie cudzego kodu z zasady jest męczarnią, ale takie akcje że się zmienia numer pinu a sygnał jest nadal tam gdzie był, to potrafią doprowadzić do szału...
Ale jest też dobra strona, program źródłowy jest pisany "normalnie", bez udziwnień i stosowania kretyńskich konstrukcji, więc idzie się w nim połapać..
Chodzi o to, że ludzie którym się coś udaje, dzielą się na tych którzy dobrze rozumieją i tych którzy dobrze pamiętają.
Kretyni z dobrą pamięcią są prawdziwą plagą, bo jak im coś (choćby i przypadkiem) raz zadziała, to oni pamiętają że taki ciąg znaków rozwiązuje problem i stosują go zawsze i wszędzie. Doskonałym przykładem jest powszechnie stosowane <int LED_PIN = 13;>. Niby wiadomo że numer pinu to stała a nie zmienna, ale działa więc po co wnikać?

Na razie uruchomiłem oś A i usunąłem kretyński pomysł żeby "LATHE_MODE" ($33=1) blokowało możliwość użycia osi Y.
Oczywiście w tokarce są tylko osie X i Z, ale jak będzie potrzebny dodatkowy krokowiec do czegokolwiek, to niech się dowolnie nazywa, byleby działał...
Osi B uruchomić nie potrafię, niby jest skonfigurowana, ale wyjścia STEP/DIR są martwe. Pewnie gdzieś jest jakaś kretyńska literówka, albo coś podobnego, ale to szukanie igły w stogu siana.
Oś C w ogóle nie jest skonfigurowana i chyba tak zostawię, a piny wykorzystam jako wyjścia dodatkowych sygnałów włącz/wyłącz sterowanych jakimiś kodami M... W tokarce to się chyba bardziej przyda...
STM32F411CCU6 (Black Pill) ma wystarczająco dużo wyjść żeby obsłużyć sześć osi, wrzeciono, probe i te pozostałe wejścia kontrolne, nawet jeden pin zostaje wolny. Przy mniejszej ilości osi da się dopisać dodatkowe funkcjonalności jak pisałem wyżej.
Stosowanie Nucleo ma średni sens. Niby można włożyć CNCshield, a różnica w cenie to tylko ~50 PLN, ale czy warto to już pozostawiam do samodzielnej oceny...

Co do G33 i G76, to na razie dużo nie wiem. wklepałem G33Z3K1 i dostałem error8. Nie wiem czy powodem jest brak enkodera, czy błąd w programie. To będę sprawdzał później.

Co do enkodera, to zamierzam napisać fake-encoder na ATtiny13. ma mieć wejście ENABLE i wyjścia A/B, niby prosta sprawa i nawet na delay() da się zrobić, ale póki co nie miałem kiedy się za to zabrać...

Co do publikacji poprawionego kodu źródłowego, to jest na to za wcześnie.
Zrobię to jak już zacznie działać, no chyba że wcześniej zarobię bana, bo znowu jednemu Moderatorowi nadepnąłem na odcisk...