Sterownik pięcioosiówki za 80 PLN

Co prawda jeszcze nie podłączyłem sterownika do fizycznej maszyny, ale mam trochę czasu, więc opiszę wykonaną konfigurację.
Jakby coś, to będzie errata.
Sterownik to Makerbase TinyBee dostępny na Aliexpress za całe 80 PLN z wliczoną wysyłką https://www.aliexpress.com/item/1005006607128915.html
Ten sterownik jest dedykowany do drukarki 3d, co skutkuje pewnymi rozwiązaniami niekoniecznie pasującymi do sterowania frezarką, a jako firmware wgrany jest jakiś Marlin, który do tego celu nie nadaje się w ogóle.
Ale formalnie rzecz biorąc, jest to procesor ESP32 obudowany układami I/O typowymi dla CNC.
Tak więc pierwszą czynnością jest usunięcie Marlina i wgranie firmware dedykowanego do frezarki.
Wybór padł na FluidNC, którego od dawna używam i specjalnie nie narzekam.
Tutaj jest pewien problem, bo o ile firmware jest dobrze przetestowane i działa dość dobrze, to sama instalacja może być drogą przez mękę.
O "FluidNC Web Installer" nie napiszę nic, bo jedyne co dostałem, to komunikat "Browser not supported Please use Chrome, Edge or Opera instead".
Cóż, używam Firefoksa i to w wersji 106.0.5, bo to ostatnia która zaspokaja moje potrzeby i nie narzuca mi rozwiązań, których nigdy nie zaakceptuję. Tak więc instalacja innej przeglądarki, u mnie przynajmniej, nie wchodzi w rachubę.
Pozostaje ściągnięcie z https://github.com/bdring/FluidNC/releases/tag/v3.7.17
Tylko tutaj jest zupełnie inny problem.
Otóż skrypty instalacyjne są oparte na języku Python, chyba najbardziej popieprzonym i kapryśnym, jaki kiedykolwiek wymyślono. Z wersji na wersję są tam wprowadzane tak rewolucyjne zmiany, że w konsekwencji programy Pythona działają poprawnie tylko u ich autora i tylko na jego komputerze...
Tak właśnie miałem, u mnie nie chce działać prawie nic, na szczęście oprócz tego co najważniejsze.
A najważniejszym jest Fluidterm, który pozwala na upload plików konfiguracyjnych.
Otóż skrypt fluidterm.sh nie działa, natomiast w folderze common jest plik fluidterm.py, który daje się uruchomić (trzeba mu nadać atrybut wykonywalności), a jeżeli mu czegoś brakuje, to wyświetla jasny komunikat co trzeba doinstalować z użyciem pip3 install.
Ogólnie, należy pamiętać że to skrypt Python3 i w starszych Linuksach mogą dziać się cuda, jeśli zainstalowany jest Python zarówno w wersji 2 jak i 3...
Opisywać tego dokładniej nie będę, ale najważniejsze jest to, że skrypt fluidterm.py (nie sh) powinien dać się uruchomić.
Pozostaje kwestia zaprogramowania ESP32.
Otóż ściągnięty razem z firmware esptool działa tylko ze skryptami FluidNC i nie jest instalowany w systemie, więc jeśli te skrypty nie działają, to trzeba esptool zainstalować inaczej, czyli przez pip3 install esptool
Samo zaprogramowanie procesora nie powinno stanowić problemu.
Ja potrzebuję wersję Bluetooth, więc tylko o niej napiszę. Dla wersji WiFi trzeba jeszcze wgrać index.html.gz do lokalnego systemu plików, co powinien załatwić upload we Fluidterm (CTRL+U), ale tego nie sprawdzałem.
Aby wgrać firmware bez użycia dostarczonych przez autorów skryptów Pythona, trzeba wejść do folderu z firmware i wydać polecenie Linia jest dość długa i trzeba przewinąć żeby zobaczyć/skopiować ją w całości.
Teraz trzeba uruchomić Fuidterm i kombinacją CTRL+U zrobić upload pliku config.yaml.
Plik może się nazywać inaczej, ale wtedy trzeba ustawić parametr $Config/Filename co jest opisane w dokumentacji i nie będę tego rozwijał. Jest to jednak o tyle ważne, że jeden fizyczny sterownik może mieć kilka różnych konfiguracji, pomiędzy którymi można się dość komfortowo przełączać.
Plik konfiguracji wygląda następująco: Ustawień bezpośrednio zależnych od sprzętu opisywać nie będę, tak po prostu musi być, bo inaczej działać nie będzie. Dotyczy to przede wszystkim osi X,Y,Z i częściowo A i B. Po prostu określone sygnały są doprowadzone do podstawek stepsticków i zmienić się tego nie da.
Tutaj ważna uwaga.
Otóż sterowniki osi (także sygnały STEP/DIR/ENA dostępne na goldpinach, oraz kilka innych sygnałów) są sterowane z układu rozszerzenia wyjść zbudowanego na rejestrze przesuwającym. Po pierwsze, to są wyłącznie wyjścia, po drugie pewnych funkcji nie obsłużą, na przykład wyjścia PWM.
Jak pisałem, osie X.Y i Z są "hardwired" i niczego tam się zmienić nie da, albo przynajmniej nie ma sensu.
Natomiast dwa pozostałe stepsticki są przeznaczone do obsługi ekstruderów, które z zasady nie wymagają bazowania. W naszym przypadku nie ma to znaczenia, bo silnik to silnik i nie ważne czym będzie poruszał, natomiast możemy potrzebować bazowania tych dwóch osi, co da się zrobić wykorzystując dostępne piny procesora.
Żeby było elegancko, wypadałoby użyć łatwo rozpoznawalnych złącz dostępnych na płytce.
Wybór padł na TB i TH1.
Złącza TH2 użyć się nie da, o czym później.
Ja mam oś obrotową, ale nie jest ona przypisana do żadnej maszyny, założę ją tam, gdzie akurat będzie potrzebna, a dodatkowo nie ma tam czujnika bazującego, który dopiero jest w planach.
Dlatego osie A i B mają wpisy w sekcji homing: cycle: -1 co znaczy że nie ma tam czujników bazujących i sterownik nie będzie sprawdzał ich stanu. Jest to opisane w dokumentacji.
Teraz kolej na czujnik długości narzędzia. Ja ostatnio zakupiłem takie https://www.aliexpress.com/item/1005006163585832.html
One mają dwie pary styków NC, jedna para do pomiaru narzędzia, druga na wszelki wypadek, żeby wywołać alarm gdy pierwsza nie zadziała i narzędzie będzie chciało wbić się w stół...
To się łączy ze sprawą drugą, mam w maszynie zintegrowane serwokrokowce, które wystawiają alarm gdy błąd pozycji przekroczy zaprogramowaną wartość, ale one są NO i z NC nie da się ich połączyć razem.
FluidNC ma dwa sygnały, estop i fault, które różnią się chyba tylko tym, że wyświetlają inny komunikat, natomiast działają tak samo i awaryjnie zatrzymują maszynę.
Dlatego sygnały aktywne stanem niskim i sygnały aktywne stanem wysokim, są podpięte albo tu, albo tam.
Sam pomiar narzędzia jest na złączu MT_DET.
Teraz czas na złącze TH2, które prosi się, żeby go użyć.
Otóż pin procesora gpio.34 może być przełączony zworką albo na złącze TH2, albo na gniazdo karty SD, gdzie służy do sprawdzenia czy karta jest fizycznie obecna w gnieździe. Ponieważ nie ma żadnego sensu rezygnowanie z obsługi karty SD, więc zworkę należy ustawić w pozycji SDDET, co z kolei powoduje że sygnał z gniazda TH2 dociera tylko do wolnego pinu tego złącza, ale nikt nam przecież nie broni poprowadzić go kabelkiem gdzieś dalej. Ja kawałkiem zworki wysłałem go na trzeci pin gniazda EXT2 i takim cudem pin gpio.14 i sygnał estop znalazły się na gnieździe TH2,
Teraz kwestia PWM.
Jak pisałem, niektóre sygnały przechodzą przez rozszerzający rejestr przesuwny i nie mogą być wykorzystane do obsługi sygnału PWM (przynajmniej we FluidNC nie da rady).
Niestety, dotyczy to wszystkich sygnałów sterujących tranzystorami wyjściowymi, zarówno tymi malutkimi (FAN1, FAN2), tymi średnimi (HEATER0, HEATER1), jak i prawdziwym potworem (HOTBED). One wszystkie mogą być tylko sterowane włącz/wyłącz, co oczywiście też się przyda.
Ale do PWM potrzeba wyjścia bezpośrednio z procesora.
No i tutaj byłem naprawdę zaskoczony, bo sygnał na złączu 3d_TOUCH okazał się sygnałem wyjściowym, a nie wejściowym, jak się spodziewałem...
Nie, nic w tym złego, po prostu nie znam konstrukcji tego czujnika więc sądząc po nazwie, zakładałem że powinien on dawać sygnał gdy czegoś dotknie, a nie dostawać sygnał gdy to się stanie... Najwyraźniej jest inaczej.
Gniazdo 3d_TOUCH może obsługiwać sygnał PWM wrzeciona i tak jest w konfiguracji.
Oprócz sygnału PWM potrzebujemy też sygnału SPINDLE_ENABLE, czyli prostego włącz/wyłącz.
No i tutaj jest kilka możliwości.
Oczywiście każdy tranzystor wyjściowy może obsłużyć ten sygnał, ale pasować może nam bardzo różnie.
Ja mam wrzeciono sterowane falownikiem i chłodzone powietrzem. PWM zasadniczo nie potrzebuję, bo takie wrzeciono ma sprawność chłodzenia silnie zależną od obrotów. Najlepiej zawsze pracować na maksymalnych obrotach, a nigdy nie wolno zejść poniżej połowy. Sygnał SPINDLE_ENABLE dałem na "średni" tranzystor, bo boję się zakłóceń z falownika, ale spróbuję też dać go na "mały", może będzie dobrze. Najsilniejszy tranzystor zostawiłem na chłodziwo, bo on da radę bezpośrednio sterować małą pompką.
Ale jeśli ktoś chce bezpośrednio wysterować wrzeciono 12/24V (na przykład takie tanie na silniczku 775) to musi konfigurację wyedytować i pozamieniać piny.
Gdyby ktoś nie wiedział, to ten sterownik ma gniazda na stepsticki, co wystarcza do malutkich maszynek, ale też sygnały sterujące wyprowadzone na goldpiny i da się podłączyć duże sterowniki dużych silników.
FluidNc jest w sporej części kompatybilny z GRBL i można używać programów "sender" kompatybilnych z GRBL.
Ja używam bCNC, który polecam.
Oprócz podstawowych funkcji ma on prosty CAM i rozszerzenia, na przykład wymianę narzędzia z jego pomiarem, którego sam GRBL nie obsługuje.
Na koniec linki:
http://wiki.fluidnc.com/
https://github.com/makerbase-mks/MKS-Ti ... 20V1.0_003

Jakoś nie mogłem tego znaleźć, a okazało się że jest http://wiki.fluidnc.com/en/config/user_outputs
To są wyjścia, których stan można zmieniać odpowiednimi komendami M, co jest opisane w dokumentacji.
Tak więc po dodaniu poniższej sekcji dostaniemy dwa dodatkowe wyjścia cyfrowe na złączach FAN_1 i FAN_2.
Pojęcia nie mam ile te małe tranzystorki są w stanie dać prądu, ale jakiś mały przekaźnik powinny uciągnąć (tradycyjny musi mieć diodę zabezpieczającą przed przepięciami, SSR nie musi). Jak widać, wyjść cyfrowych może być więcej, ale i dla tych dwóch nie wiem czy znajdę zastosowanie...
Natomiast z wyjściami analogowymi jest już problem, bo jak pisałem, sygnał PWM można dostać tylko na pinach bezpośrednio połączonych z ESP32 i to nie wszystkich. Ja tego nie potrzebuję, więc się bawić z tym nie będę, ale teoretycznie taka możliwość jest.

Wczoraj podłączyłem kontroler do frezarki.
Wyszło kilka kwiatków, ale większość specyficznych dla mojej maszyny.
Musiałem odwrócić sygnał DIR dla dwóch osi.
Trudno to nazwać błędem, bo to zależy od tego na którym końcu śruby jest silnik.
Musiałem odwrócić sygnał enable wrzeciona.
To raczej należy zakwalifikować jako błąd, bo tranzystor wyjściowy powinien przewodzić po M3, a nie po M5, ale w jakiejś specyficznej konfiguracji może być potrzebne na odwrót.
Odwrócenie pinu wykonuje się w ten sposób, że na końcu linii dodaje się dwukropek i słowo low. Teoretycznie istnieje też zapis high, ale to jest przyjmowane domyślnie, czyli dopisanie :high ani nie jest błędem, ani nie jest potrzebne.
Wyszedł natomiast kwiatek dość poważny i specyficzny dla wszelkich "zielonych" procesorów.
Po prostu w walce o jak najmniejsze zużycie prądu i co za tym idzie mniejsze wydzielanie ciepła, poległa odporność na zakłócenia.
Przy napięciu zasilania 3,3 V oraz oporności wewnętrznego rezystora pullup rzędu 50 kΩ wystarczy 0,06 mW mocy zakłóceń, żeby zmienić stan wejścia (pół napięcia zasilania i 35 µA prądu).
W płytkach Makerbase są stosowane układy zabezpieczające wejścia przed przepięciami i zakłóceniami, ale na pinach GPIO.12 i GPIO.14 akurat nie, bo one służą do szybkiej komunikacji z wyświetlaczem, co użycie układu przeciwzakłóceniowego wyklucza.
Tak więc po włączeniu wrzeciona sterowanie głupieje.
Nic nadzwyczajnego, zakłócenia od falownika już niejednego konstruktora doprowadziły do szału...
Co ciekawe, na pinie GPIO.14 nie dzieje się nic złego, a pin GPIO.12 szaleje, choć konstrukcję mają identyczną.
Wytłumaczenie jest proste, jeden pin jest sterowany NC, a drugi NO, czyli do jednego jest podłączony przewód którego drugi koniec wisi w powietrzu, a do drugiego pętla trzech metrów przewodu którego drugi koniec jest podłączony do masy - inny układ, inne zachowanie.
Wczoraj już nie chciało mi się z tym walczyć, ale problem jest na pewno prawidłowo zdiagnozowany - po odłączeniu czujnika narzędzia i wpięciu krótkiej zworki objawy ustąpiły.
Problem powinien rozwiązać kondensator kilkadziesiąt nF włączony równolegle do wejścia, w ostateczności transoptor.
Jak sobie z tym poradzę, to napiszę.

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

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

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

Jedyną wadą pythona według mnie jest to że jest wolny. Konkretny interpreter i moduły powinny być instalowane w wirtualizacji a nie globalnie (albo globalnie interpreter a wirtualnie moduły), pod konkretny skrypt/program. Wtedy unikamy różnego rodzaju konfliktów z programami które potrzebują innych wersji interpreterów (możemy dodać ścieżkę do danego interpretera) czy modułów. Można do tego wykorzystać natywny venv, virtualenv.

https://docs.python.org/3/library/venv.html

https://virtualenv.pypa.io/en/latest/

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.

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.

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