FluidNC

Jakiś czas się nie interesowałem i ominęła mnie premiera, ale dzisiaj znalazłem nowy projekt oparty na GRBL i ESP32.
Na razie zainstalowałem na próbę na płytce Espduino32 i pierwsze wrażenia są rewelacyjne.
Jest taka ciekawa sprawa, że z nieznanej przyczyny, na Aliepress strasznie zdrożały klony Arduino i ogólnie układy oparte na ATmega328 i lepszych procesorach Atmela... Wytłumaczenie jakieś na pewno jest, ale ja go nie znam. W każdym razie nieporównywalny co do możliwości i zasobów ESP32 wychodzi sporo taniej od archaicznej ATmegi, co zapewne wróży koniec skansenu opartego na ośmiu bitach i 32 kB flasha... Ja się co prawda wychowałem na 8080 i 8048, znam ich potęgę kiedy są właściwie wykorzystywane do tego do czego się nadają, ale masochizm polegający na płaceniu kilka razy więcej za coś kilka razy gorszego musi w końcu ustąpić ekonomii...
Tak więc na Aliexpress Espduino32 idzie kupić poniżej 20 PLN z wliczoną dostawą, a za klon Arduino UNO krzyczą dwa razy więcej...
Identyczna sytuacja jest z gotowymi kontrolerami GRBL, te na ESP32 idzie dostać za 80 PLN, podczas gdy te na ATmedze 328 kosztują ponad stówkę.
Na razie nic nie wskazuje na to, żeby ten trend miał się zmienić, raczej różnica będzie coraz większa...
Wracając do FluidNC, to podobno działa na Makerbase DLC32 (w tej chwili na Aliexpress 75 PLN z wliczoną dostawą).
Płytkę mam, ale jeszcze nie sprawdzałem, bo to do nowego projektu, który dopiero co rozpocząłem.
Co do samego FluidNC, to jest on "skonstruowany" nieco inaczej. To znaczy jest kompatybilny z GRBL na tyle, że współpracuje z programami pisanymi dla GRBL, czyli zarówno g-kodem jak i senderami (ja testowałem na bCNC), natomiast są spore różnice jeśli chodzi o kompilację i konfigurację.
Ogólnie to są dwie wersje prekompilowanego firmwaru, które "powinny wystarczyć każdemu" (wi-fi albo bluetooth), bo nawet przypisanie pinów układu do funkcji GRBL odbywa się w pliku konfiguracyjnym, wczytywanym przez sterownik przy każdym uruchomieniu, co dla użytkownika jest niewidoczne.
Inaczej mówiąc, wgrywamy do ESP32 jeden albo drugi firmware, potem dogrywamy plik konfiguracji i nie trzeba się babrać w kodzie źródłowym i kompilatorze.
Fajnie to działa, choć przy pierwszym razie można się pogubić.
Także wiele poleceń $ działa inaczej, albo ma inne nazwy, więc tak zupełnie bezboleśnie nie będzie, ale na pewno warto, bo i taniej i lepiej...
I to na razie tyle, jak prace posuną mi się naprzód, to dam znać.

https://github.com/bdring/FluidNC
https://github.com/bdring/FluidNC/wiki/ ... onfiguring
https://github.com/bdring/FluidNC/releases/tag/v3.4.5
https://github.com/diruuu/FluidNC/blob/ ... -v2.0.yaml

Dodane 45 minuty 6 sekundy:
Nie jest malinowo, dokumentacja jest dopiero tworzona...
Chciałem zmienić nazwę urządzenia bluetooth i żadnych informacji nie znalazłem...
Poszukałem jednak w kodzie źródłowym i znalazłem wartość "Bluetooth/Name"...
No i bingo, $Bluetooth/Name wyświetla nazwę urządzenia bluetooth, a $Bluetooth/Name=nazwa ją zmienia...
Ciekawe co jeszcze ten soft potrafi, choć dokumentacja o tym milczy...

Zapomniałem jeszcze dodać, że FluidNC obsługuje kartę SD, można odpowiednią komendą $ uruchomić program z karty...
Natomiast jeśli wgrasz go do Makerbase DLC32, to zapomnij o ekranie dotykowym, bo to tajny wynalazek Makerbase i kod źródłowy nie jest udostępniony. Ja akurat wyświetlacza nie mam zamiaru kupować, mam złe doświadczenia z TFT35, co opisywałem na forum, za to potrzebuję bluetooth zamiast wi-fi, a Makerbase twierdzi że wie lepiej i jest na odwrót...
To jeszcze jeden dowód na to, że jak coś nie jest GPL, to szkoda na to czasu, bo kiedy coś naprawdę będzie potrzebne, to się okaże że nie da rady...

Znalazłem czas żeby się zająć posiadanym MKS DLC32 V2.0.
Najprościej było wymienić sterownik w CNC1310, bo tam też jest GRBL, tylko 8-bitowy.
Nie pasowało tylko wrzeciono, mechanicznie, bo w jednym sterowniku jest gniazdo, w drugim złącze śrubowe, ale elektrycznie to to samo.
Firmware wgrał się bez problemu, dwie osie chodziły w przeciwnych kierunkach niż potrzeba.
Tutaj jest właśnie problem z różnym sposobem konfiguracji. W GRBL jest to maska w odpowiednim parametrze $, we FluidNC wpis w pliku konfiguracyjnym.
Oczywiście plik konfiguracyjny jest z samej natury rozwiązaniem lepszym, ale przy brakach w dokumentacji można stracić trochę czasu i nerwów. Ostatecznie okazało się, że trzeba dodać wpis :low albo :high do odpowiedniej linii, co znaczy tyle, że stan uznawany za aktywny jest niski albo wysoki. Działa to zarówno przy wyjściach (np. dir) jak i przy wejściach (np. limit albo probe).
Wypróbowałem też kartę SD i tu był poważny problem.
Nie będę się rozpisywał, ale w wersji 3.4.5 karta SD nie działa.
Autorzy doszli już do przyczyny, ale plików w folderze releases nie zmienili.
Zapewne następna wersja będzie wolna od błędu, ale póki co, to jak ktoś musi mieć kartę SD, to niech wgra wersję 3.4.4.
Nawiasem mówiąc, FluidNC ma swój system plików w pamięci flash, dużo miejsca tam nie ma, ale jakiś krótki program można tam umieścić i uruchomić...
W 1310 nie mam krańcówek, więc nie testowałem bazowania.
Załączam plik dla DLC32-CNC1310, parametr max_travel_mm jest z sufitu, ale to w niczym nie przeszkadza.

Niestety, są problemy.
Karta SD działa w najnowszej wersji, czego można się było spodziewać, ale wyszło inne szydło z worka i to poważniejsze.
Otóż program w wersji Bluetooth zawiesza się w czasie wykonywania niektórych programów, np. zawierających M0, ale nie tylko.
Problem ewidentnie dotyczy obsługi Bluetooth, przez kabelek USB wszystko działa pięknie.
Zgłosiłem problem twórcom programu, ale jak na razie jest to rozmowa niemowy z głuchym. Autor wadliwego kodu w końcu zakumał że coś jest nie tak, ale nie bardzo łapie co nie działa, więc naprawia to chaotycznie i póki co bez rezultatu.
Ponieważ bardzo zależało mi na komunikacji BT, więc poszedłem po bandzie i dolutowałem cztery kabelki do nóg 1,2,3,16 CH340.
Numer chamski, ale udało mi się podłączyć moduł HC-06.
W necie wyczytałem, że JDY-31 nie pójdzie w takiej konfiguracji (wydajność prądowa czy coś podobnego) i faktycznie, komunikacja jest tylko w jedną stronę - do sterownika, w drugą stronę milczy. Nie ma co się czepiać, trzeba zapamiętać że HC-06 zadziała a JDY-31 działać nie będzie.
Teraz mam wgrany firmware wi-fi, komunikację BT przez moduł HC-06, ale on jest transparentny dla danych i sterownik jest święcie przekonany że to UART/USB.
To na czym mi zależy działa już bez problemu, wi-fi jeszcze nie testowałem, bo przeróbkę kończyłem już w nocy.
Oczywiście jeżeli ktoś chce używać sterownika z kablem USB, to powyższy problem go nie dotyczy.

Dodane 40 minuty 21 sekundy:
Sprawdziłem wi-fi - działa.
Trzeba poustawiać parametry sieci, ale do tego akurat dokumentacja jest wystarczająca.
Co dość ważne, można się podłączyć do istniejącej sieci, także ze stałym IP, a nie tylko w trybie AP.
Interfejs jest bardzo prosty, niestety nie wykonamy programu bez karty SD, co ma jednak taką zaletę, że program puszczony z karty jest odporny na zakłócenia transmisji, co niby jest oczywiste. Nie musimy wyjmować karty żeby dograć nowy program, działa upload, zarówno przez Fluidterm i porty szeregowe (tragicznie wolno, ale działa), jak i przez wi-fi.
Mały problem sprawił mi Firefox, który uparcie chce się łączyć przez HTTPS, a FluidNC obsługuje HTTP. Niby drobiazg, a irytuje.

Wygląda na to, że twórcy programu naprawili wersję Bluetooth i już działa.
Oczywiście zmiany będą dopiero w nowym wydaniu (3.4.8 ).
Przy okazji testów odkryłem jeszcze coś ważnego. Jeżeli ktoś zechce pójść w moje ślady i podłączyć moduł HC-06, to niech nie lutuje do niego kabelków na stałe, tylko użyje złącza. Chodzi o to, że moduł działa prawidłowo w czasie normalnej pracy, ale jego obecność uniemożliwia przeprogramowanie ESP32. Coś się po prostu gryzie, nie ma sensu w to wnikać, trzeba po prostu na czas programowania moduł HC-06 odłączyć.

Jest wersja 3.4.8 z poprawionym Bluetooth.
To niestety koniec mojego skromnego udziału w projekcie, bo moje zdrowie jest ważniejsze.
Jak pisałem, zgłosiłem problem z Bluetooth na githubie autorów.
Najpierw było że to nieistotne i żebym im du** nie zawracał.
Potem było że im działa i żebym im du** nie zawracał.
Potem nerwy mi puściły i zrobiła się awantura.
Padł debilny argument, że oni robią to za darmo, więc powinienem być im wdzięczny i nie czepiać się że nie działa.
Potem mnie zbanowali.
Na koniec doszli do wniosku że jednak ich kod jest do du** i trzeba go zmienić, a teraz z dumą się tym chwalą :

Fixes to Bluetooth/Telnet/Websockets When commands were being sent via Bluetooth (and also telnet websockets), certain operations like homing would discard sent-ahead GCode commands. Those other channels now behave almost identically with regard to send-ahead.

Cóż, świat jest pełny urażonych narcyzów...
Teraz to ja będę mówił, że u mnie działa to czego potrzebuję, a resztę mam w du***...

FluidNC mimo wszystko polecam.

Są do pobranie nowe wersje.
Nie testowałem, bo mam teraz inne priorytety.

Jest już wersja 3.5, wgrałem ale poważniejszych testów nie robiłem, bo poszła do wyjątkowo prostej maszyny.

Moja nowa zabawka to ploter do styroduru XYUVA, zbudowany na V-slotach i NEMA 17 0.4 Nm, ze sterownikiem Makerbase Tiny Bee.
Ploterek działa i przeszedł już pierwsze testy, ale to materiał na inny wątek.
Dlaczego do tak prostej maszyny wybrałem skomplikowane sterowanie?
Bo co prawda więcej czasu trzeba poświęcić na konfigurację, ale za to użytkowanie będzie sporo prostsze...

Najpierw drobne wyjaśnienie.
Ploter jest XYUVA, czyli dwa niezależne wózki umożliwiające ustawienie drutu pod kątem. Jak ktoś nie wie o co chodzi, to niech sobie poszuka materiałów o cięciu ze styroduru skrzydeł modeli latających.
Natomiast GRBL jest doskonałym przykładem na to, że nawet ludzie tworzący skomplikowane i użyteczne projekty potrafią być kretynami i ignorantami.
Otóż wszelkie dostępne normy mówią, że osie liniowe to XYZUVW, a osie obrotowe to ABC.
Nie da się ogarnąć rozumem, dlaczego w GRBL są tylko osie XYZABC, z tym że ABC mogą być zarówno obrotowe jak i liniowe.
Każdy kto ma jakiekolwiek pojęcie o programowaniu, wie doskonale, że nadanie osi absolutnie dowolnej nazwy to raptem kilka dodatkowych linii kodu, choć zapewne właśnie o oszczędzanie nie licząc się z kosztami chodziło, żeby program upchnąć na siłę w 32 kilobajtach...
Tak więc osie muszą się nazywać XYABC, gdzie A to oś obrotowa, bo z kolei pasuje to do przycisków "jog" w używanym przeze mnie bCNC. Znowu nie wiadomo dlaczego A to odpowiednik Z, ale to już mało ważne...
Tak więc GRBL obsługuje co prawda sześć osi, ale nie jest kompatybilny z żadnym poważnym oprogramowaniem zgodnym z powszechnie obowiązującymi normami.
Oczywiście można sobie napisać własne postprocesory do używanego CAM, ale to znowu kupa niepotrzebnej roboty...
W każdym razie FluidNC jest zgodny z GRBL, więc dalej będę używał nomenklatury GRBL.

Wracając do meritum, ploter XYAB to świetna sprawa do cięcia wspomnianych skrzydeł, czy innych stożków, ale stanowi poważny problem gdy chcemy ciąć tylko bryły 2,5d, czyli z projektu dwuwymiarowego, a takich prac jest większość.
Rozwiązania są dwa.
Pierwsze to napisać własny postprocesor do CAM, który będzie dublował parametry, czyli np. zamiast G1X5 będzie dawał G1X5B5.
Drugie rozwiązanie jest prostsze i polega na zmianie konfiguracji maszyny z osi niezależnych na zależne, czyli sterowane tym samym sygnałem.
Można poprzepinać kabelki, można wgrać inny firmware, albo można użyć właśnie FluidNC.
Otóż do FluidNC można wgrać wiele konfiguracji i dość łatwo się pomiędzy nimi przełączać.
Służy do tego zmienna $Config/Filename
Czyli na przykład wpisujemy w terminalu $Config/Filename=druga.yaml i po zresetowaniu kontrolera wstanie on z konfiguracją "druga".

Plik konfiguracyjny FluidNC pozwala przypisać jednej osi dwa silniki.
Bazowania nie testowałem, bo nie mam założonych krańcówek, ale same silniki pracują mi prawidłowo - w konfiguracji gdzie każda oś ma jeden silnik maszyna działa jako XYABC, a w konfiguracji gdzie po dwa silniki są przypisane do jednej osi jako XYA.
Znakomicie ułatwia to życie, bo tam gdzie jest taka potrzeba można używać g-kodu pisanego na dwie osie.

Będę budował kolejną maszynkę, w sumie prosta maszyna 3 osiowa. Chciałbym użyć GRBL ale ponieważ z zestawem UNO miałem sporo cyrków, tym razem chciałem użyć wersji bezprzewodowej i kupić ESPDUINO i FluidNC.
I teraz pytanie, czy jest tu jakiś konkretny model/producent tego badziewia który działa? Chodzi o to, że z arduino UNO trafił mi się raz jakiś klon, który nie dawał się zaprogramować przez arduino IDE (miał chyba jakiś inny bootloader).
Wypatrzyłem sobie taki:
https://all egro.pl/oferta/wemos-d1-r32-esp-wroom-32-espduino-r3-11805836676

drzasiek90 pisze: ↑

22 lip 2022, 09:44

Będę budował kolejną maszynkę, w sumie prosta maszyna 3 osiowa. Chciałbym użyć GRBL ale ponieważ z zestawem UNO miałem sporo cyrków, tym razem chciałem użyć wersji bezprzewodowej i kupić ESPDUINO i FluidNC.
I teraz pytanie, czy jest tu jakiś konkretny model/producent tego badziewia który działa? Chodzi o to, że z arduino UNO trafił mi się raz jakiś klon, który nie dawał się zaprogramować przez arduino IDE (miał chyba jakiś inny bootloader).
Wypatrzyłem sobie taki:
https://all egro.pl/oferta/wemos-d1-r32-esp-wroom-32-espduino-r3-11805836676

Ale po jasną cholerę utrudniać sobie życie?
https://www.aliexpress.com/item/1005003528709178.html
https://www.aliexpress.com/item/1005003824258637.html
Na DLC32 zbudowałem frezarkę z serwokrokowcami 3 Nm.
Na TinyBee zbudowałem ploter do styroduru, stepsticki, cztery niezależne osie liniowe i piąta obrotowa.
Obie maszyny na FluidNC
Oprócz widocznych różnic jest jedna dość istotna, której nie widać - TinyBee ma trzy potężne mosfety mocy, ale one nie obsługują PWM. Po prostu tą płytkę zaprojektowano do drukarek 3d, a tam sterowanie on/off w zupełności wystarczy.
DLC32 ma natomiast PWM.
Oczywiście ESPduino jest tańsze, ale to oszczędność która się w żaden sposób nie opłaca...

tuxcnc pisze: ↑

22 lip 2022, 13:41

Ale po jasną cholerę utrudniać sobie życie?

Nie po jasną cholerę i nie utrudniać.
Po pierwsze nie robię tego dla zabawy i dla mnie jest różnica jak coś przyniesie kurier jutro a za tydzień czy za trzy. Po drugie potrzebuje faktury VAT na elementy, które kupuje. Po trzecie espduino w kanapce z cncshield zajmuje najmniej miejsca i to też jest ważne.