Wydaliśmy niedawno Firmware 4.4.0 BETA2 dla Original Prusa MINI/MINI+ na naszym GitHubie, a jego najważniejszą nową funkcją jest obsługa połączenia Wi-Fi. I nie da się tego inaczej ująć: dużo czasu zajęło nam zrealizowanie tego, co zostało obiecane. To była długa, wyboista droga. Trafiliśmy w kilka ślepych zaułków, musieliśmy znaleźć obejścia dla ograniczeń sprzętowych, a to jeszcze nie koniec. Jednak wsparcie dla bezprzewodowego przesyłania plików G-code i zdalnego zarządzania MINI już działa i możemy wreszcie mówić o tym, co musieliśmy zrobić, aby dojść do tego etapu.

Dodanie Wi-Fi do MINI+

Original Prusa MINI+ to niedroga, ale bardzo wszechstronna maszyna. Gdy zespół sprzętowy ją projektował, kluczem było znalezienie równowagi między ilością funkcji a ceną. Ponadto obsługa wszystkich modeli szyfrowania współczesnych punktów dostępowych byłaby niemożliwa na obecnym procesorze MINI. Dlatego też układ Wi-Fi nie został wbudowany w płytę główną.

Zamiast tego wpadliśmy na pomysł, aby dodać proste złącze do płyty głównej, które umożliwiłoby podłączenie taniej płytki ESP-01, zamieniając zewnętrzny mikrokontroler w most pomiędzy siecią bezprzewodową a dyskiem USB. Przeprowadziliśmy badania i znaleźliśmy kilka projektów open-source zajmujących się możliwościami sieciowymi ESP-01, więc projekt dostał zielone światło.

Co to jest ESP-01? Jest to przystępny moduł Wi-fi składający się ze stosu TCP/IP wraz z wbudowanym mikrokontrolerem. Jego podstawową funkcją jest wprowadzenie komunikacji bezprzewodowej do zintegrowanych projektów. Działa jako samodzielny mikrokontroler, więc nie wymaga żadnego innego mikrokontrolera (jak Arduino lub Atmel), aby użyć jego pinów wejścia/wyjścia. Zasadniczo jest to mostek bezprzewodowo-szeregowy z 1MB pamięci flash, 32-bitowym procesorem małej mocy i obsługą sieci Wi-Fi 802.11 b/g/n. Jest to niezwykle popularne i niedrogie rozwiązanie istniejące od 2014 roku. Original Prusa MINI/MINI+ obsługuje zarówno ESP-01, jak i nieco zmodyfikowaną wersję ESP-01S – więcej informacji znajdziesz na liście zmian.

Rozpoczęliśmy prace nad obsługą Wi-Fi w MINI pod koniec 2020 roku z zamiarem porządnego wykonania części programistycznej od początku, zamiast po prostu klepania kodu i wypuszczania go w pośpiechu, ponieważ oznaczałoby to, że prędzej czy później i tak musielibyśmy napisać wszystko od nowa. Zebraliśmy dedykowany zespół, którego zadaniem było przeprowadzenie właściwej analizy całego projektu i stworzenie prototypu rozwiązania bezprzewodowego.

Zróbmy to dobrze

Od początku szukaliśmy kompleksowego rozwiązania, które obsługiwałoby nie tylko proste przesyłanie plików G-code przez sieć lokalną, ale byłoby również kompatybilne z naszym (wtedy dopiero powstającym) PrusaLink i oprogramowaniem do zarządzania farmą Prusa Connect. Plan zakładał stworzenie stabilnego stosu TCP/IP dla Ethernetu i Wi-Fi, możliwość korzystania z gniazd BSD oraz wykorzystanie warstwy aplikacyjnej – strony internetowej z możliwością zdalnego sterowania serwerem HTTP uruchomionym bezpośrednio na drukarce. Zespół dostał zadanie i przystąpił do pracy.

Jednym z kluczowych pomysłów było utrzymanie obecnego firmware’u ESP-01 w stanie nienaruszonym. Istnieje wiele różnych odmian ESP-01, a my założyliśmy, że programowanie (i utrzymywanie) własnego firmware’u dla tych mikrokontrolerów jest zbyteczne. Dla ESP-01 istnieje już stos LwIP, który zajmuje się SLIP (Serial Line IP via UARTs), NTP i statycznym przekierowaniem. Najpierw spróbowaliśmy dodać równoległy stos IP i LwESP, który jest lekką biblioteką parsera poleceń ESP AT. Użycie rozwiązania open-source wydawało się właściwą drogą.

Jednak w tym miejscu zaczęliśmy trafiać w ślepe zaułki. Istnieją różne wersje firmware dla ESP-01, każda z nich ma nieco inny zestaw funkcji i różne poziomy jakości/niezawodności. Oznaczało to również, że musieliśmy dodać ogromną ilość kodu do firmware płyty Buddy (płyty głównej MINI) z powodu biblioteki LwESP. W końcu oznaczałoby to posiadanie dwóch równoległych stosów IP (jeden LwIP dla Ethernetu i drugi podzielony między Buddy i ESP) i przełączanie się między nimi w razie potrzeby.

A problemów było więcej – tylko 5 połączeń, brak wsparcia dla serwera UDP i różne inne sytuacje. Teoretycznie dałoby się to jakoś uruchomić, ale testowanie i debugowanie tego byłoby koszmarem. Jednak nasz kolega z zespołu SLA znalazł dość pomysłowe rozwiązanie – złożył specjalny, lekki firmware na zamówienie dla ESP-01.

Eureka!

Tak więc w końcu mieliśmy prototyp małego specjalnego firmware’u, który zmieniał ESP-01 w interfejs sieciowy, coś podobnego do układu Ethernet na płycie głównej Buddy. To było coś, czego naprawdę potrzebowaliśmy: krok we właściwym kierunku.

I wtedy nasz zespół dostał ogromne wsparcie. Cytując klasyczny film: osoba, która zapomniała o sieci więcej niż my wszyscy kiedykolwiek będziemy wiedzieć. A także wysoce wykwalifikowany architekt C++! Zaczął tam, gdzie skończyły się poprzednie próby od zupełnie nowej analizy. Zaledwie miesiąc zajęło mu zaimplementowanie elastycznego i efektywnego serwera HTTP, który jest w stanie strumieniować odpowiedzi na żądania (tzn. mieści się w ograniczonej pamięci RAM bez względu na to, jak długo zajmuje odpowiedź).

Jego kolega wziął niestandardowe firmware i zaczął rozwijać prototyp ESP zachowującego się jak karta sieciowa. Najpierw zaczął od połączenia bezprzewodowego i podłączył ESP przez UART (interfejs szeregowy) do standardowego laptopa. W ten sposób uzyskaliśmy prędkości do 9/6 Mbit (download/upload). W końcu mieliśmy niezawodne połączenie bezprzewodowe z prędkością przewyższającą maksymalną przepustowość interfejsu UART MINI, która wynosi 4,6 Mbaud.

Podłączenie ESP do interfejsu warstwy fizycznej w stosie LwIP firmware’u Buddy przyniosło nie tylko oszczędność kodu, ale także wyeliminowało wspomnianą schizofrenię mieszanych stosów IP dla dwóch różnych interfejsów. Sprawy zaczęły wyglądać naprawdę dobrze.

Przeklęte pamięci USB

Robiliśmy duże postępy. Serwer HTTP ładnie się rozwijał i zaczęliśmy dodawać więcej funkcji – jak wysyłanie plików G-code z PrusaSlicera i pobieranie ich z drukarki. Dodaliśmy nową przeglądarkę plików z miniaturami w interfejsie internetowym i zaimplementowaliśmy funkcje startu/zatrzymania drukowania (i kilka innych).

W kwietniu 2022 roku mieliśmy stabilne połączenie bezprzewodowe, a firmware był prawie gotowy do wydania. Pozostawała tylko jedna rzecz do rozwiązania. Był to, niestety, poważny problem: zapewnienie stabilności i kompatybilności różnych pamięci USB – od najtańszych chińskich modeli no-name po markowe nośniki. Mała ciekawostka: wiele z tanich chińskich dysków no-name w praktyce działało bardziej niezawodnie niż droższe modele. 🙂 Tak czy inaczej, musieliśmy najpierw rozwiązać problem nieprawidłowych limitów czasu w sterowniku USB. Udało nam się to zrobić we współpracy z STM. Ale potem pojawiła się inna rzecz, coś naprawdę strasznego. Podczas gdy karty SD mają bardzo wyraźnie określone czasy reakcji, pamięci USB wręcz przeciwnie. Potrafią „zamilknąć” nawet na kilkadziesiąt sekund, do tego dochodzi jeszcze jedna rzecz zwana „porządkowaniem”.

Mówiąc najprościej: pamięci USB są stworzone do pracy głównie ze standardowymi komputerami – takimi jak laptopy, odtwarzacze multimedialne i konsole do gier wideo. Te maszyny mają ogromne ilości pamięci RAM (większe niż 1 MB 🙂 ), więc kiedy zaczynasz kopiować pliki na pamięć USB i przestaje ona reagować na kilka sekund, wciąż istnieje duży bufor, który pomaga przezwyciężyć to opóźnienie. „Porządkowanie” to coś, co nośnik USB robi automatycznie – jest to procedura odpowiedzialna za wewnętrzne kopiowanie bloków danych w celu rozłożenia poziomu zużycia mniej więcej równomiernie w całej pamięci flash, aby przedłużyć żywotność kości. Jednak to „sortowanie” zajmuje trochę czasu.

Niektóre dyski USB są tak źle zaprojektowane, że mogą wstrzymywać odpowiedź nawet na 10 sekund. Przydzieliliśmy 10 kB pamięci RAM na płycie głównej Buddy, aby służyła jako bufor i w ten sposób wyeliminowaliśmy ten problem. Chociaż teoretycznie możliwe jest przesyłanie plików G-code nawet podczas aktywnych zadań drukowania, nie zalecamy korzystania z tej funkcji ze względu na problemy z wydajnością.

Na końcu musieliśmy rozwiązać problem z biblioteką FATfs. Biblioteka ta jest używana głównie w urządzeniach wbudowanych i stara się utrzymać system plików w maksymalnej spójności. Oznacza to, że za każdym razem, gdy zapisywany jest fragment pliku, układ pamięci zaczyna aktualizować główną i zapasową tablicę FAT. Jest to kolejny zabójca wydajności, który ostatecznie obniży żywotność dysku USB. Na szczęście znaleźliśmy rozwiązanie: po rozpoczęciu wgrywania pliku G-code znamy już jego całkowity rozmiar, więc po prostu każemy systemowi plików zarezerwować najpierw miejsce dla całego pliku, a tabela jest aktualizowana dopiero po zakończeniu wgrywania.

Droga przed nami

Obecna wersja firmware 4.4.0 BETA oferuje już zaawansowaną funkcjonalność sieciową i niezawodne przesyłanie plików G-code. Mamy jednak jeszcze trochę pracy do wykonania. Sprawdzamy, czy możemy niezawodnie przesyłać strumieniowo pliki G-code, gdy MINI/MINI+ drukuje. Jak wyjaśniliśmy powyżej, jesteśmy ograniczeni technologią napędów USB i chociaż strumieniowanie jest teoretycznie możliwe, nadal istnieje wiele potencjalnych problemów.

Wciąż poprawiamy kod, więc obecne prędkości to nieco ponad 100 kB/s w zależności od jakości połączenia bezprzewodowego i 300 kB/s na ethernecie. Zostało jeszcze trochę przestrzeni do rozwoju. W teorii powinniśmy być w stanie osiągnąć około 460 kB/s surowej prędkości na UART/ESP. Spodziewamy się, że ostateczna prędkość ulokuje się gdzieś pomiędzy 250-350 kB/s, gdy zostanie odpowiednio zoptymalizowana.

Chcielibyśmy również skupić się na uczynieniu całości bardziej przyjazną dla użytkownika. W tej chwili musisz skopiować specjalny plik INI na dysk USB, co jest rozwiązaniem nieco ograniczonym. Działa, ale zdecydowanie możemy to poprawić. Chcemy też wprowadzić więcej ulepszeń dotyczących jakości użytkowania – na przykład rzeczywisty wskaźnik siły sygnału. Daj nam znać, co jeszcze chcesz zobaczyć!

Istnieje wiele różnych napędów USB i różnych modeli modułu ESP-01, które mogą wpływać na prędkość w ten czy inny sposób. Będziemy bardzo wdzięczni, jeśli zdecydujesz się przetestować nowy firmware dla MINI i dasz nam znać, jakich urządzeń (ESP i USB) używasz i jakie są Twoje doświadczenia z nimi!

Oczywiście cały firmware, w tym technologia Wi-Fi ESP jest całkowicie open-source, a kody źródłowe są dostępne bez ograniczeń na GitHubie. Jeśli więc chcesz pobawić się ESP, nie krępuj się i pobierz kod źródłowy stąd!

Obecne wydanie firmware możesz pobrać z naszego GitHuba.