Dzisiaj nie miałem siły robić poważniejszych testów.
Wgrałem FluidNC 3.7.17 wifi do sterownika frezarki, trochę pojeździłem osiami, zrobiłem kilkadziesiąt bazowań, poustawiałem wymianę narzędzia z pomiarem i przetestowałem ją, czyli to, na czym Bluetooth się wysypywał, więc na pewno jest lepiej.
Tak na 100% to będzie wiadomo, kiedy puszczę kilka dłuższych programów, ale nie wiem czy w ten weekend znajdę czas i ochotę...
Nie pisałem o tym wcześniej, ale w kontrolerze przy frezarce wywaliłem tą niby-antenę i dałem prawdziwą https://www.aliexpress.com/item/1005005218090899.html
Także do komputera kupię takie dongle https://www.aliexpress.com/item/1005004204205121.html.
Powinno to poprawić jakość sygnału wifi, czyli podnieść odporność na zakłócenia.

pitsa pisze: ↑

10 maja 2024, 07:12

Czemu wcześniej po wifi nie działałeś? Coś przemawiało za tym żeby używać BT?

Autorzy sobie wymyślili wykorzystanie serwera www wbudowanego w ESP32, z którym się łączysz przez teoretycznie dowolną przeglądarkę internetową. Zasadniczo w takim rozwiązaniu nie ma niczego złego, jednak jego użyteczność jest ograniczona do tego, co serwer www oferuje, a oferuje niewiele.
Ja natomiast używam bCNC, który ma sporo rozszerzeń i udogodnień, ale wymaga zwykłej komunikacji szeregowej.
O komunikacji bCNC z FluidNC przez Telnet jest w necie kilka zdawkowych informacji, których nie znajdziesz nie wiedząc czego szukać.

Zmiana planów !!!
Nagle coś mi zaczęło świtać, że w bCNC są do wyboru jakieś dziwne porty, poszukałem w necie, i już po kilku minutach wiedziałem, że FluidNC może łączyć się z bCNC przez wifi, konkretnie telnet na porcie 23...
Podobno UGS też potrafi tę sztuczkę, ale tego nie testowałem.
Wgrałem więc do TinyBee FluidNC 3.7.17, ale firmware wifi.
Po resecie, z automatu uruchomił się acces point z domyślnym adresem 192.168.0.1 , hasłem dostępu 12345678 i nazwą FluidNC(można sobie to zmienić, ale na razie nie ma potrzeby).
Teraz trzeba w komputerze wybrać sieć FluidNC i się do niej zalogować.
W bCNC jako adres portu wpisujemy socket://192.168.0.1:23 którego niestety z automatu nie wykrywa, ale to naprawdę żaden problem.

Wielkich testów nie robiłem, bo to goły Tinybee do niczego nie podłączony, do tego od frezarki będę miał dostęp dopiero jutro.
To co dało się sprawdzić działa.
Jeżeli komunikacja po wifi będzie działać, to zabawa z Bluetooth traci sens...
Pod Linuksem działają groszowe dongle wifi na USB, natomiast z zasady nie działają tanie dongle BT na USB, w szczególności chińskie klony CSR domyślnie są zablokowane w kernelu, bo nie są w pełni kompatybilne z oryginałem.
Za dongla BT działającego na Linuksie, i to też tylko nowszym, dałem 50 PLN i to było tanio...
Teoretycznie, trzeba zrobić upload pliku index.html.gz z folderu wifi, żeby mieć dostęp do sterowania przez przeglądarkę internetową, ale telnet działa i bez tego.
Tutaj jest kolejna niedoróbka FluidNC w postaci debilnego spartycjonowania pamięci flash, gdzie na dane pozostawiono 170 kB, chociaż wolne jest co najmniej 2 MB... Po wgraniu index.html.gz naprawdę niewiele się tam zmieści...
Kiedyś robiłem bardziej sensowne partycjonowanie dla FluidNC, ale teraz nie pamiętam jak i muszę sobie to przypomnieć...

Podsumowując, do testów idzie 3.7.17 wifi.

Mam chwilę czasu, to wyjaśnię dokładniej problem z Bluetooth.
Jakieś dwa lata temu zgłosiłem ten problem na Githubie.
Rozmowa od początku się nie kleiła i najzwyczajniej chcieli mnie spławić.
Nie będę robił wykładu z informatyki, tylko posłużę się obrazowym przykładem.
Są trzy firmy kurierskie i w każdej z nich nadaję do Ciebie przesyłkę.
Przychodzą kurierzy z dwóch firm i oddają Ci paczkę, tak jak było umówione.
Przychodzi kurier z trzeciej firmy, wali Cię w zęby i tracisz przytomność.
Naprawdę nie potrzeba większej inteligencji niż u szympansa, żeby zrozumieć, że jeden z kurierów jest popieprzony i nie należy korzystać z jego usług.
Dokładnie to samo jest z komunikacją we FluidNC.
Przez USB i wifi wszystko jest ok, medium jest transparentne dla danych, tak jak być powinno. Natomiast przez Bluetooth niektóre pakiety nie przechodzą, bo coś jest popieprzone w procedurach obsługi tego medium, i te procedury ingerują w zawartość pakietów, czego robić nie powinny, tak jak listonosz powinien listy doręczać, a nie czytać i wyrzucać te, które mu się nie spodobają.
Niby wszystko jest oczywiste, ale autorom FluidNC nie udało się tego wytłumaczyć.
W końcu mnie zbanowali, czyli klasycznie, zamiast walczyć z gorączką, zbili termometr.
Po pewnym czasie, te błędy komunikacji które zgłaszałem zostały poprawione i myślałem że co prawda późno, ale do nich dotarło o co chodzi.
Okazuje się jednak że nie.
Coś tam poprawili i jakoś to działało, ale później, zapewne przy okazji jakichś poprawek czy wprowadzania nowych funkcji, komunikacja przez Bluetooth znowu się skasztaniła, bo najwyraźniej nadal korzystają z tych samych procedur, zamiast je zmienić na inne.
Wgrałem do kontrolera wersję 3.7.6 i będę ją testował.
Jeżeli nie będzie problemów, to jakoś to przeboleję, w końcu nie ma obowiązku korzystać wszędzie z najnowszych wersji.
Jeśli jednak pojawią się jakieś kwiatki, to będzie znaczyło, że Bluetooth we FluidNC nie działa i nie należy go używać.
Wracając do tamtej dyskusji na Githubie, jeszcze zanim mnie zbanowali, tak mnie wkurzyli, że po prostu przylutowałem cztery kabelki do odpowiednich końcówek układu CH340C (odpowiedzialnego za komunikację przez USB) i podłączyłem moduł HC05.
Oczywiście wtedy komunikacja przez Bluetooth działała bez zarzutu, bo FluidNC o niczym nie wiedział i był przekonany że rozmawia z komputerem po kablu...
Nie polecam jednak takiej partyzantki, bo to po prostu nie jest rozwiązanie profesjonalne i pewne w działaniu.
Ponadto, moduł Bluetooth i USB zakłócały się wzajemnie i żeby skorzystać z kabla trzeba było HC05 fizycznie odłączać.
Natomiast nic nie słyszałem o opisywanych powyżej problemach, kiedy korzysta się z USB lub wifi.
Czyli jeśli ktoś nie chce używać Bluetooth, to tylko powinien wiedzieć, że są z nim jakieś problemy, natomiast przejmować nie ma się czym.

Niestety, problemów z bazowaniem ciąg dalszy...
Najpierw kwestia sprzętowa.
Wcześniej w maszynie miałem DLC32 i krańcówki indukcyjne podpięte do wtyczek bazowania (+5V, GND, HOME). Działało to bez zarzutu, więc po prostu wtyczki przełożyłem do TinyBee i zaczęły się dziać cuda. Myślałem że coś jest źle skonfigurowane, ale dzisiaj, zupełnym przypadkiem znalazłem przyczynę. Otóż przetwornica z +12/24V na 5V nie wyrabia. Może trafiłem taki egzemplarz, a może więcej odbiorników musi obsłużyć. W każdym razie krańcówki indukcyjne głupieją z tego właśnie powodu.
Przełączyłem zasilanie krańcówek na +12/24V (są na płytce takie gniazda) i problemy ustąpiły.
Teraz bazować mogę z poprzednimi ustawieniami.
Ale pojawił się drugi problem, tym razem programowy i to na pewno we FluidNC https://github.com/bdring/FluidNC/issues/1182
W skrócie, jeśli komunikacja jest przez Bluetooth, to co ileś razy kontroler zawiesza się w czasie bazowania i robi dzwona o ramę...
Na USB tego efektu nie ma.
Szlag mnie trafia, bo właśnie za dyskusję o błędach komunikacji Bluetooth zostałem tam zbanowany...
Tym razem autor zgłoszenia został potraktowany łagodniej i tylko kazali mu się odpieprzyć, bo nie mają ani czasu, ani ochoty, żeby ten błąd naprawiać...
Podobno wersja 3.7.6 jest wolna od tego problemu, co znaczy że autorzy coś znowu popieprzyli...
Pozostaje komunikacja po kablu, albo znowu cofnięcie się do starszej wersji...

Powrót do firmware 3.7.16
Historia jest długa, ale może być pouczająca...
Otóż wymieniając sterownik we frezarce, postanowiłem też uaktualnić firmware do najnowszej wersji.
Od początku działy się cuda przy włączaniu zasilania lub po resecie - sterownik głupiał, komunikacja się sypała, ale po minucie czy dwóch wszystko się uspokajało i działało prawidłowo.
Miałem za mało danych żeby wyciągnąć jakieś wnioski, więc tematu nie drążyłem.
Ale wczoraj posypał mi się sterownik w laserze CO2.
W ogóle to wstyd się przyznać, że coś takiego miałem kilka lat w maszynie, ale zadziałało znane prawo, że prowizorki trwają tak długo, jak długo działają...

Wczoraj jednak coś zaczęło się sypać, dłuższe programy zawieszały się, całe szczęście że ciąłem drobiazgi potrzebne mi do projektowania enkodera do mojej nowej tokarki-zabawki CNC (tokarka to taki Vevor za 2200 PLN, niby normalna tokarka, tyle że mała i delikatna, ale o tym może będzie w innym wątku), tak więc na jakości mi specjalnie nie zależało, ale to wkurzające kiedy jeden element trzeba ciąć trzy razy, albo po kawałku...
Dlatego zapadła długo odkładana decyzja, o wymianie sterowania.
W sumie to powstrzymywały mnie drobiazgi, tam jest taki przewód-taśma pasujący do trudno dostępnego złącza, a potrzeba to było rozprowadzić na zwykłe kabelki... Jednak niedziałająca maszyna okazała się wystarczającą motywacją...
Na początek chciałem dać MKS DLC V2.0, który wala mi się po kątach bez przydziału.
Laser to wyjątkowo prosta maszyna i naprawdę nie potrzeba nic potężniejszego niż Atmega 328p.
Ale tutaj wyszedł inny problem. Firmware dostarczany przez Makerbase obsługuje trzy osie, a mój laser ma tylko dwie, co skutkuje tym, że nie da się maszyny zbazować, bo sterownik będzie czekał na sygnał nieistniejącej krańcówki nieistniejącej osi Z.
Pomyślałem więc, że zgram firmware z tej swojej prowizorki (ten sam procesor), ale dostałem komunikat, że nie da się odczytać pamięci flash. Cóż, bez powodu tego złomu nie wymieniałem...
Pozostały dwie opcje - skompilować firmware bez osi Z, albo znaleźć swój stary firmware w czeluściach wielu backupów, które też by trzeba było najpierw znaleźć...
Jedno i drugie to jednak za dużo roboty, więc sięgnąłem po MKS DLC32, który właśnie został zwolniony z obsługi frezarki.
Co prawda trzeba było poprawić plik konfiguracyjny, ale konfiguracji to i tak bym nie uniknął, bez względu na to, które rozwiązanie bym wybrał.
Tak więc wgrałem do sterownika FluidNC w najnowszej wersji 3.7.17 i zaczęły dziać się te same cuda co na TinyBee.
No czarów nie ma, jak się krzaczy na dwóch różnych sterownikach, to winny musi być firmware...
Nie wiem jak z wersją wifi, bo nie mam motywacji sprawdzać - dla mnie to wiedza zupełnie bezużyteczna, bo potrzebuję BT...
Wgrałem wersję 3.7.16 i objawy ustąpiły.

ARMed pisze: ↑

04 maja 2024, 11:39

Ale to jest wina tych co robili skrypt/program bo to wszystko można na tym poziomie zrobić. A na linucha można zrobić binarki / appimage. Wtedy to już w ogóle nie trzeba nic nawet instalować tylko ściągnąć i odpalić.

I tutaj na pewno masz rację, ale co z tego...
Kiedyś próbowałem im wytłumaczyć na Githubie, że spieprzyli ważny fragment kodu, to się obrazili, zbanowali mnie, a błąd i tak naprawili, kiedy do nich dotarło...
Nie mam zdrowia żeby z takimi ludźmi rozmawiać.

ARMed pisze: ↑

04 maja 2024, 08:33

Wtedy unikamy różnego rodzaju konfliktów z programami które potrzebują innych wersji interpreterów

Niestety, ale tak pięknie to nie jest.
Ja już miałem takie kwiatki, że Python3 brał moduły z Pythona2, zamiast swoich...
To jest kompletny burdel, nad którym nikt nie jest w stanie zapanować.
Nie powiem, że twoja porada żeby sobie zainstalować siedem Pythonów i pilnować żeby się ze sobą nie pogryzły jest głupia, no bo pewne problemy to faktycznie rozwiąże. Powiem raczej że jest bezużyteczna dla większości użytkowników komputerów, których znajomość informatyki polega na tym, że odróżniają mysz od klawiatury.
W tym wątku sprawa jest dość jasna, to nie jest zabawa dla informatyków, tylko miłośników CNC, którzy dostają niedziałające skrypty, albo poradę żeby sobie zainstalowali przeglądarkę której nie chcą...
Tutaj porada jest prosta - zainstalować esptool, wklepać w terminal podaną wyżej linię kodu i nie pieprzyć się z żadną wirtualizacją.

Dodane 21 minuty 24 sekundy:

pitsa pisze: ↑

04 maja 2024, 08:57

tuxcnc pisze:nie bardzo rozumiem po co się pytasz.

Nie używam grbl tylko gotowych i wygodnych programów, linuxcnc i suby, własnych programów do sterowania silnikami krokowymi w urządzeniach i tylko raz jakieś webgui testowałem ale nie poszło do wdrożenia, bo nie nadawało się do tego, żeby zrobić maszynę i dać ją operatorowi (po krótkiem przeszkoleniu bez konieczności uczenia gkodów i innych zaklęć) żeby mógł tylko wybrać projekt z katalogu, ustawić detal, wpisać dwa lub trzy parametry i kliknąć start.

sorry, za długie zdanie mi wyszło...

Prostota i nie zawracanie mi głowy ze strony operatorów maszyn jest dla mnie priorytetem. Dałbym radę, przez to co opisujesz, przebrnąć ale nie widzę tego całościowo, stąd pytanie.

Ludziom się wydaje, że postawienie małpy przy maszynie jest prostsze i tańsze niż wykwalifikowanego operatora.
Nic bardziej błędnego, bo małpa rozłoży ręce kiedy trzeba będzie zrobić cokolwiek więcej niż wybrać, czy wcisnąć zielony czy czerwony przycisk.
Nie to żeby operator musiał być programistą, ale jednak powinien znać podstawowe g-kody i rozumieć w jaki sposób maszyna je wykonuje.
To tak jak z kierowcą, nie musi wiedzieć jak jest zbudowany silnik, ale powinien wiedzieć dlaczego nie wchodzi się w zakręt przy 200 km/h...
Wracając do twoich potrzeb, to GRBL jest dość prostym sterowaniem i można jego obsługę sprowadzić do kilku klawiszy i wybrania programu z karty SD.
Niestety, GRBL nie obsługuje pętli, warunków i parametrów, więc żadnych subów na nim nie zrobisz.
Dla każdego zestawu parametrów trzeba napisać osobny program.
Wracając do bCNC, to on pracuje z komunikacją przez kabel USB, lub Bluetooth. Ze smartfona można obsługiwać przez Bluetooth aplikacją GRBL Controller.
Wersje wifi mają wbudowany serwer www i można je obsługiwać z dowolnej przeglądarki internetowej na dowolnym sprzęcie (przynajmniej w teorii).
Myślałem, że będąc tyle czasu na tym forum dowiedziałeś się o powyższym, choćby i przypadkiem.
Ale skoro mówisz, że twoja wiedza jest zerowa, no to wybacz, ale nie będę Ci tłumaczył tego, co jest opisane w necie.
Linki do FluidNC znajdziesz gdzieś powyżej, do bCNC masz tutaj https://github.com/vlachoudis/bCNC/wiki
Możesz też poszukać informacji o GRBL, Zasadniczo to jest martwy projekt, bo już dawno wykorzystano wszystkie dostępne zasoby procesora Atmega 328P, na który był pisany, ale FluidNC i grblHAL są ogólnie kompatybilne z GRBL i wiele informacji jest użytecznych także z nowszym i potężniejszym sprzętem.

pitsa pisze: ↑

03 maja 2024, 23:17

Ten bCNC trzeba jakoś skonfigurować aby przekazywał dane do tej płytki?
To jest webgui czy normalne gui po kablu usb?

FluidNC jest w pewnym zakresie kompatybilny z GRBL i zasadniczo pracuje tak samo.
Program sendera wysyła komendę, a sterownik odpowiada "OK" albo kodem błędu.
Komunikacja może się odbywać po kablu USB, przez bluetooth, lub przez wifi.
FluidNC ma osobny firmware dla wifi i osobny dla bluetooth, więc teoretycznie nie można używać ich równocześnie, ale kiedyś zrobiłem taki numer, że wgrałem firmware od wifi, a do układu CH340 przylutowałem kabelki, podłączyłem moduł HC06 i miałem bluetooth i wifi równocześnie, oczywiście nie tak, żeby się wzajemnie zakłócały. Niestety wtedy CH340 głupieje i nie można się połączyć po kablu.
A tak w ogóle, to jest ESP32 i pracuje jak ESP32.
Co do bCNC, to masz zakaz korzystania z Google?
To jest program do komunikacji z GRBL, obsłuży też grblHAL albo FluidNC.
Jak pisałem, komunikacja ze sterownikiem GRBL/grblHAL/FluidNC jest prymitywnie prosta, jak ktoś się uprze, to może wykonać g-kod klepiąc ręcznie kolejne linie w dowolny terminal szeregowy, ale ponieważ jest to męczące i podatne na błędy, to wymyślono sendery, czyli programy które taką komunikację ułatwiają. Kolejnym krokiem było wprowadzenie do senderów dodatkowych funkcji, które rozszerzają możliwości.
Na przykład GRBL nie obsługuje wymiany narzędzi, ale bCNC może przechwycić kod M6 i wykonać własne makro wymiany narzędzia i jego pomiaru, co dla użytkownika jest niewidoczne.
Powinieneś o tym wszystkim wiedzieć, więc nie bardzo rozumiem po co się pytasz...

Jak się można było spodziewać, kondensator 47nF załatwił sprawę zakłóceń od wrzeciona.
Tutaj taka uwaga, że nie można mieć wszystkiego na raz. Kondensator zwiera szybkie przebiegi, dlatego kasuje zakłócenia, ale skasuje też użyteczne sygnały, jeśli te będą zbyt szybkie... Akurat w przypadku krańcówek czy alarmów milisekundy nie czynią różnicy, ale przy innych sygnałach przycięcie pasma do kilkuset herców może uniemożliwić komunikację.
Dowiedziałem się też, czym się różni ESTOP od FAULT. Oba zatrzymują maszynę, oba można wycofać $X, ale po ESTOP nie da się zrobić niczego oprócz bazowania... Sensu to nie ma żadnego, Grzyba można wcisnąć przy stojącej maszynie i nie straci się pozycji, natomiast alarm z silników zawsze jest efektem dzwona i zawsze pozycja jest utracona...
Ale u mnie akurat jest na odwrót, alarm silników jest podłączony do ESTOP, a awaryjne styki czujnika narzędzia do FAULT, czyli wyszło jak potrzeba...
Musiałem zmniejszyć prędkość bazowania. Nie wiem dlaczego, bo do tej pory też był FluidNC, tylko starsza wersja i na DLC32.
Tu też taka dygresja, że silniki nie stają dęba po najechaniu na krańcówkę bazującą, tylko hamują z zadanym przyspieszeniem i mogą spowodować dzwona gdy miejsca będzie za mało.
Tutaj miałem dwa różne efekty, choć przyczyna była ta sama. Raz silnik po dzwonie się wyłączał i zgłaszał alarm, ale też się zdarzało, że alarmu nie było, tylko napęd nie dawał rady zjechać z krańcówki.
Tak więc nie należy przesadzać i z prędkością bazowania (feed_mm_per_min i seek_mm_per_min), ale też nie dawać zbyt małej wartości pulloff.
No i na koniec, nie należy wgrywać nowej konfiguracji przez bluetooth. Niby to też łącze szeregowe, ale nie działa identycznie jak USB i do tuningowania maszyny trzeba używać kabla...
W załączniku ostateczna wersja konfiguracji mojej frezarki.
Zamierzam zakupić takie https://www.aliexpress.com/item/33048275939.html albo podobne płytki z tranzystorami MOSFET mocy i rozwiązać problem braku wyjścia PWM mocy. Do frezarki tego nie potrzebuję, ale przyda się kiedy będę przerabiał ploter termiczny do styroduru. Tam od początku był TinyBee z FluidNC, ale projekt ugrzęzł na takim etapie, że ciąć już było można, więc zabrakło motywacji żeby maszynę dokończyć.. .