W jednej ze swoich frezarek mam sterowanie na płytce MKS DLC32 z wgranym FluidNC.
Ogólnie to rozwiązanie zaspokajało potrzeby, ale jest tam wgrana dość stara wersja i chciałem ją uaktualnić, ale bez ingerowania w używany sterownik (zamontować nowy, a stary na razie do szuflady).
Niestety, a może stety, okazało się, że nie mam wolnej płytki DLC32, za to mam wolną TinyBee...
Ponieważ nie chciało mi się pisać nowego pliku konfiguracyjnego, a płytki sporo się różnią, choć obie są na ESP32, postanowiłem wypróbować wspominany niedawno w innym wątku grblHAL.
Pierwsze wrażenia nie są najlepsze.
Na stronie http://svn.io-engineering.com:8080/?dri ... bee%20V1.0 jest generator firmware.
Niestety, jak ktoś nie jest w temacie, to za cholerę nie poradzi sobie z konfiguracją...
Ja potrzebowałem co najmniej cztery osie, więc wybrałem konfigurację z pięcioma osiami, bo nie ma co sobie żałować.
Trochę szkoda, że się nie da ustawić sześciu osi (tyle obsługuje GRBL z którym grblHAL jest w dużym stopniu, ale nie całkowicie kompatybilny). Oczywiście sterownik ma tylko pięć gniazdek na stepsticki. ale jaki problem wyprowadzić sygnały do zewnętrznego drajwera?
Przez konfigurację przebrnąłem i zażyczyłem sobie "Generate and download"... Generatorowi ślimaki się rozbiegły, ale po jakimś czasie dostałem plik z firmware.
Tutaj pojawił się problem jak go wgrać w płytkę TinyBee...
Niby wiadomo, że do tego służy esptool.py, dostarczany za darmo przez producenta ESP32.
Instalacja narzędzia na Linuksie jest banalnie prosta, miłośnicy najlepszego systemu operacyjnego jaki kiedykolwiek wymyślono będą mieli pod górkę. Nie to że się nie da, ale na Windows z zasady są problemy i nawet jak się uda zainstalować, to działa to tak sobie...
Ale wróćmy do pingwina, ja używam do codziennej pracy Ubuntu 22.04.2. Instalacja esptool.py sprowadza się do:
Kod: Zaznacz cały
pip install esptoolTo jest program działający w terminalu i wymaga długiego ciągu parametrów. Nie żeby było w tym coś złego, tylko po prostu dla ludzi przyzwyczajonych do klikania we wszystko, będzie to horror...
Żeby było gorzej, to w archiwum otrzymanym z generatora są nie tylko pliki firmware, bootloadera i partycji (ESP32 tak jest skonstruowany, że wymaga wgrania tego wszystkiego), ale też plik ReadMe.txt.
Plików readme zwykle nikt nie czyta, ale ten jest wyjątkowo ważny, bo zawiera adresy, pod które trzeba wgrać otrzymane pliki.
Oczywiście wgranie pod inne adresy ESP32 nie zepsuje, ale spowoduje, że płytka działać nie będzie...
U mnie ten plik zawiera następującą treść:
Kod: Zaznacz cały
Flash adresses:
bootloader.bin 0x1000
partitions.bin 0x8000
firmware.bin 0x10000
Kod: Zaznacz cały
#!/bin/bash
esptool.py -p /dev/ttyUSB0 -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_size detect --flash_freq 40m 0x1000 bootloader.bin 0x8000 partitions.bin 0x10000 firmware.binZaprogramowanie przebiegło bez żadnych problemów.
Trzeba tylko po pobraniu nowego firmware sprawdzić, czy nie zmieniły się adresy, no i oczywiście czy nasz TinyBee jest na porcie ttyUSB0, bo może być na innym.
No i tutaj zdarzyło się najgorsze.
Sterownik podłączyłem i uruchomiłem program bCNC, który polubiłem i z którego jestem zadowolony.
Udało się zainicjować połączenie, po czym okazało się, że sterownik jest martwy...
To jest naprawdę paskudna sytuacja, kiedy użytkownika wysadza się w lesie i niech sam szuka drogi...
Udało mi się jednak zdobyć potrzebne informacje.
Otóż od razu wiedziałem gdzie jest problem, bo program wyświetlał alarm, że krańcówki i inne sygnały wejściowe są w stanie aktywnym, a być nie powinny. W GRBL, a także w grblHAL sygnały wejściowe neguje się wpisując odpowiednią maskę w odpowiedni parametr $, tylko nie da się tego zrobić kiedy kontroler nie reaguje na komunikację...
Rozwiązanie narzuca się samo, ale ponieważ nie miałem pewności czy nie chodzi o coś innego poszukałem w dokumentacji grblHAL. Okazało się że tak ma być i sterownik nie ruszy dopóki mu się wszystkich wejść nie zewrze do masy, czyli używa czujników NPN NC.
Dlaczego nikt nie pomyślał, żeby domyślnie zanegować wejścia?
Przecież lepiej by było żeby goła płytka działała i można było sobie ją dowolnie skonfigurować, niż żeby nie działała dopóki nie pozwiera się wejść...
Tak czy inaczej wejścia musiałem wcześniej czy później znaleźć, no to wyszło że jednak wcześniej.
Znowu droga przez mękę, bo trzeba porównywać trzy pliki https://github.com/makerbase-mks/MKS-Ti ... %20SCH.pdf https://github.com/makerbase-mks/MKS-Ti ... %20PIN.pdf https://github.com/grblHAL/ESP32/blob/m ... _1_0_map.h
No i znowu, jak ktoś jest zielony, to za cholerę sobie nie poradzi, bo podstawowe wejścia łatwo znaleźć, ale tych dodatkowych dla 4 i 5 osi już nie, bo są na złączach formalnie przeznaczonych do innego celu.
Może z konfiguracją trzech osi nie jest tak tragicznie, ale jak się ma pięcioosiową płytkę, to fajnie by było wykorzystać wszystkie jej możliwości...
Na razie więcej testów robić nie będę, bo się zmęczyłem...
A teraz dobre wieści.
1. TinyBee ma potężne mosfety mocy, ale sterowane przez układ zwiększający ilość wejść zbudowany na rejestrach przesuwających. Praktycznie wyklucza to użycie tych mosfetów do sterowania wrzeciona PWM (teoretycznie dałoby się to zrobić, ale efekt mógłby być niezadowalający). W grblHAL jest jednak możliwość wysłania sygnału PWM na inne wyjście. jest to co prawda sygnał o napięciu 3,3V i wymaga wzmocnienia w dodatkowej płytce, ale nie jest to ani specjalnie drogie, ani specjalnie trudne. Tak więc wrzeciono z PWM da się skonfigurować bez grzebania w kodzie źródłowym i samodzielnej kompilacji firmware.
2. grblHAL obsługuje tokarkę z enkoderem wrzeciona. Oczywiście tego nie sprawdzałem, ale tak wynika z dokumentacji. To świetna wiadomość, bo prawie wszyscy autorzy sterowników CNC mają jakąś niechęć do tokarek. Nie chodzi tylko o rozwiązania amatorskie, ale też komercyjne - jak chcesz gwintować, to bez wydania kilku tysięcy nie da rady...
Jeżeli będzie to przyzwoicie działało w sterowniku za 80 PLN, to będzie to rewelacja...
