GRBL dla tokarki

Rozmowy dotyczące oprogramowania sterującego maszynami CNC i sterowników CNC obrabiarek numerycznych
Awatar użytkownika

Autor tematu
tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 15
Posty: 7759
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

GRBL dla tokarki

#1

Post napisał: tuxcnc » 29 wrz 2022, 13:31

Długo szukałem, a dzisiaj trafiłem zupełnie przypadkiem:
https://github.com/Schildkroet/GRBL-Advanced

Nie mam zielonego pojęcia jaka jest jakość tego kodu, tylko rzuciłem okiem, trzeba by to sprawdzić.
Kod jest napisany dla STM32F411RE, ale powinien dać się uruchomić też na STM32F411CE, który jest montowany na chińskich płytkach dostępnych na Aliexpress poniżej 50 PLN z wliczoną wysyłką. STM32F411CE jest produkowany w mniejszej obudowie, jest mniej pinów do dyspozycji, ale tokarka i tak niewiele ich potrzebuje.
Nie wiem czy i jak duże zmiany trzeba by wprowadzić w kodzie, bo jeszcze w to nie wnikałem.

Najważniejsze, że autor deklaruje obsługę G7, G8 i G33, czyli to czego najbardziej w GRBL brakuje i co w praktyce uniemożliwia stosowanie go w tokarce.

Jeżeli program działa prawidłowo i stabilnie, to nie należy się po nim spodziewać takich cudów jak w Linuxcnc, PikoCNC albo Mach3, ale zapewnia podstawową funkcjonalność dla tego typu maszyny.

Jest ktoś chętny to wypróbować?

Dodane 55 minuty 37 sekundy:
https://alle gro.pl/oferta/stm32-nucleo-f411re-stm32f411re-arm-cortex-m4-12567561337
Żadna reklama, po prostu informacja.
Można wpiąć CNCshield od Arduino i do testów wystarczy...




tristar0
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 5
Posty: 2825
Rejestracja: 21 sty 2020, 17:48
Lokalizacja: Toruń miasto Tadeusza R

Re: GRBL dla tokarki

#2

Post napisał: tristar0 » 29 wrz 2022, 16:58

tuxcnc pisze:Kod jest napisany dla STM32F411RE, ale powinien dać się uruchomić też na STM32F411CE
łatwiej będzie na KA-Nucleo-F411ce piny w programie trzeba będzie zmienić.

Dodane 10 minuty 50 sekundy:
tyle że pewnie zauważyłeś że w programie jest obsługa 3 osi a nie 2 wiec skąd pomysł że do tokarki ?
Mam wyrypane na wszelkiej maści proroków ,mędrców i wszystkich którzy stawiają się ponad innymi ,i tak ich zjedzą robaki

Awatar użytkownika

Autor tematu
tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 15
Posty: 7759
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: GRBL dla tokarki

#3

Post napisał: tuxcnc » 29 wrz 2022, 17:29

tristar0 pisze:
29 wrz 2022, 16:58
tyle że pewnie zauważyłeś że w programie jest obsługa 3 osi a nie 2 wiec skąd pomysł że do tokarki ?
Jakbyś czytał posty na które odpisujesz, tobym nie musiał odpowiadać na głupie pytania...
tuxcnc pisze:
29 wrz 2022, 13:31
Najważniejsze, że autor deklaruje obsługę G7, G8 i G33, czyli to czego najbardziej w GRBL brakuje i co w praktyce uniemożliwia stosowanie go w tokarce.


tristar0
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 5
Posty: 2825
Rejestracja: 21 sty 2020, 17:48
Lokalizacja: Toruń miasto Tadeusza R

Re: GRBL dla tokarki

#4

Post napisał: tristar0 » 29 wrz 2022, 17:44

tuxcnc pisze:Jakbyś czytał posty na które odpisujesz, tobym nie musiał odpowiadać na głupie pytania
czytałem i program też otworzyłem i jest jak to powiedzieć minimalistyczny będzie dobrym określeniem w samym sofcie jest 6 błędów których nie sprawdzałem ale nie wiadomo na co będą wpływać .

Dodane 7 minuty 50 sekundy:
a właściwie już wiem w hal \stm /system_stm32f4xx.c i hal \usart .c
Mam wyrypane na wszelkiej maści proroków ,mędrców i wszystkich którzy stawiają się ponad innymi ,i tak ich zjedzą robaki

Awatar użytkownika

Autor tematu
tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 15
Posty: 7759
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: GRBL dla tokarki

#5

Post napisał: tuxcnc » 29 wrz 2022, 19:25

tristar0 pisze:
29 wrz 2022, 17:44
w samym sofcie jest 6 błędów których nie sprawdzałem ale nie wiadomo na co będą wpływać .
A użyłeś narzędzi polecanych przez autora?
Bo ja użyłem i niczego przy kompilacji nie wywala...


******** Dotyczy wyłącznie STM32F411CEU6 Blue Pill ********

No więc skompilowałem, wgrałem i płytka zachowywała się jakby martwa była...
Dokumentacji to praktycznie nie ma wcale, nie wiedziałem gdzie szukać przyczyny i w ogóle myślałem że szlag mnie trafi...
Z ciekawości zacząłem szukać w Issues, potem w zamkniętych Issues i znalazłem...
Dlaczego to jest tam, zamiast na głównej stronie projektu nie wiadomo...
W każdym razie wszystko wygląda na to, że będzie działać na Blue Pill.
Na razie tyle sprawdziłem, że mam komunikację na porcie szeregowym (nie przez USB !!!) na pinach A2/A3 i trzeba użyć konwertera USB/serial, ja użyłem PL2302. To jest kilka PLN więcej, ale idzie przeboleć. Zresztą można tam wstawić zamiast konwertera moduł Bluetooth...
Problem sprowadza się do użycia w Blue Pill innego kwarcu niż w Nucleo, więc trzeba inaczej ustawić dzielniki zegara...
Na szczęście to tylko kilka zmian w dwóch plikach.
Opis jest tutaj https://github.com/Schildkroet/GRBL-Adv ... -608307432

**********************************************************

Co ciekawe, program po skompilowaniu zajmuje niecałe 70 kB pamięci flash, więc całkiem rozsądne jest pytanie, czy nie da rady użyć płytki z procesorem STM32F401CCU6, która jest dwukrotnie tańsza.
Mam taką płytkę, ale nie ma wlutowanych goldpinów, więc program wgrać mogę, ale sprawdzić już nie, a lutować już mi się dzisiaj nie chce. Może jutro polutuję.
F401 to trochę inny procesor jak F411, kod z 401 zadziała na F411, ale w drugą stronę niekoniecznie, Do tego autor napisał "might be because of the smaller size of the flash. Settings are stored in last sector of flash, which is missing here. Try commenting out the Settings_Init-Function and try again."
W każdym razie spróbować warto...


tristar0
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 5
Posty: 2825
Rejestracja: 21 sty 2020, 17:48
Lokalizacja: Toruń miasto Tadeusza R

Re: GRBL dla tokarki

#6

Post napisał: tristar0 » 29 wrz 2022, 20:33

żeby ruszył na innym stm potrzebna jest zmiana kilku plików na początek starup_stm . pomijając zmianę pinów to jeszcze w pliku main.c



jutro się po bawie na stm32f411ce ka-nucleo

Dodane 22 minuty 30 sekundy:
tuxcnc pisze:A użyłeś narzędzi polecanych przez autora
ja używam Keil_v5 do stm.
Mam wyrypane na wszelkiej maści proroków ,mędrców i wszystkich którzy stawiają się ponad innymi ,i tak ich zjedzą robaki

Awatar użytkownika

Autor tematu
tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 15
Posty: 7759
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: GRBL dla tokarki

#7

Post napisał: tuxcnc » 29 wrz 2022, 20:55

tristar0 pisze:
29 wrz 2022, 20:33
tuxcnc pisze:A użyłeś narzędzi polecanych przez autora
ja używam Keil_v5 do stm.
Może twoje narzędzia są dobre kiedy program jest w nich pisany, ale nie pierwszy raz spotykam się z tym problemem, że w STM32 poprawny kod napisany na dany toolchain w ogóle nie daje się skompilować na innym...
Ściągnij narzędzia używane przez autora, to nie będziesz musiał wyważać otwartych drzwi.

Co do STM32F401CCU6, to na razie temat odpuszczam.
Autor gdzieś napisał, że program powinien się skompilować, bo są używane zasoby dostępne w F401, ale jest inny zegar (64 zamiast 96 MHz), więc trzeba poprzestawiać dzielniki i jeszcze w kompilatorze jakiś linker skądś ściągnąć, czy coś w tym stylu.
Na razie poprzestanę na F411CEU6. Może do tematu kiedyś wrócę.

Niestety nie mogę nic znaleźć na temat gwintowania.
Wiem tylko że piny enkodera A i B trzeba podłączyć do PB6 i PB7, oraz w którymś pliku zmienić definicję rozdzielczości enkodera. Tu nie ma nic dziwnego, bo to jest timer ustawiany jako enkoder kwadraturowy. Problem jest taki, że W STM32F4 nie jest obsługiwany indeks enkodera, a to on jest potrzebny do synchronizacji początku gwintu. Cholera wie jak autor to rozwiązał, bo dokumentacji nie ma żadnej...


tristar0
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 5
Posty: 2825
Rejestracja: 21 sty 2020, 17:48
Lokalizacja: Toruń miasto Tadeusza R

Re: GRBL dla tokarki

#8

Post napisał: tristar0 » 29 wrz 2022, 21:01

tuxcnc pisze:ale jest inny zegar (64 zamiast 96 MHz),
no właśnie w keil można to zmienić i sprawdzić działanie programu przed flaszowanie i sprawdzaniem na żywym procesorze

Dodane 4 minuty 15 sekundy:
on tu wrzucił tylko w pliku encoder.h że #define PULSES_PER_REV 360

Dodane 8 minuty 14 sekundy:
w pliku stm32f4xx_sdio.h coś jest na temat enkodera
#define SDIO_ClockEdge_Rising ((uint32_t)0x00000000)
#define SDIO_ClockEdge_Falling ((uint32_t)0x00002000)
#define IS_SDIO_CLOCK_EDGE(EDGE) (((EDGE) == SDIO_ClockEdge_Rising) || \
((EDGE) == SDIO_ClockEdge_Falling))
Mam wyrypane na wszelkiej maści proroków ,mędrców i wszystkich którzy stawiają się ponad innymi ,i tak ich zjedzą robaki

Awatar użytkownika

Autor tematu
tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 15
Posty: 7759
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: GRBL dla tokarki

#9

Post napisał: tuxcnc » 29 wrz 2022, 21:52

tristar0 pisze:
29 wrz 2022, 21:10
on tu wrzucił tylko w pliku encoder.h że #define PULSES_PER_REV 360
Enkoder 360 cpr jest bardzo popularny, zapewne dlatego jest taka wartość.
Tutaj enkoder jest czytany sprzętowo, więc z dużą rozdzielczością nie powinno być problemów, choć oczywiście da to niewiele, ale jest to dość istotne gdyby ktoś chciał napędzać wrzeciono serwem, bo wtedy można impulsy podebrać z wbudowanego enkodera (zwykle 1000-2000 cpr).

Natomiast problem jest zupełnie inny.
W Linuxcnc, Mach3 itd. synchronizacja początku gwintu odbywa się indeksem enkodera, nawet w ostateczności sam indeks wystarczy, a odczyt kwadratury jest tylko po to, żeby ustalić chwilową prędkość obrotową wrzeciona.
Zastanawiam się czy tutaj jest w ogóle indeks?
Tak sobie pomyślałem, że ponieważ w STM32F4 nie ma indeksu enkodera (licznik nie jest zerowany po pełnym obrocie), to może być użyty indeks wirtualny, uzyskany z podzielenia zawartości licznika przez rozdzielczość enkodera i sprawdzenia czy reszta z dzielenia zawiera się w określonym przedziale. Jak licznik jest sprzętowy, to będzie działał non-stop, nawet kiedy formalnie nie jest potrzebny...
Taki wirtualny indeks będzie działał tak długo, jak długo sterownik będzie zasilany, ale straci pozycję po wyłączeniu zasilania...

W każdym razie jakoś to musi działać, bo się dopatrzyłem że oprócz G33 jest też G76 (nacinanie gwintu w wielu przebiegach), a to już nie są żarty...

Ale może jest spieprzone i po zerwaniu synchronizacji następne G33/G76 zacznie się w innej pozycji kątowej?

Niestety będzie problem z testami, bo w tokarce mam LinuxCNC i nie będę jej bebeszył.
Tak więc muszę wykombinować jakiś model, na którym będzie widać synchronizację lub jej brak...

Awatar użytkownika

Autor tematu
tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 15
Posty: 7759
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: GRBL dla tokarki

#10

Post napisał: tuxcnc » 04 paź 2022, 12:10

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

ODPOWIEDZ Poprzedni tematNastępny temat

Wróć do „Ogólne Dyskusje na Temat Systemów Sterowania CNC”