LinuxCNC na USB lub Ethernet - reaktywacja

tuxcnc pisze: ↑

02 lip 2023, 08:40

Jesteś jak chemik, który robi reakcję w metalowym garnku bo go szkło wkurza, bo mu się tłucze.
Jednak zgodnie ze sztuką, reakcje robi się w naczyniu szklanym, żeby mieć pewność, że przypadkowe czynniki (np. obecność metalu) nie wpływają na przebieg i wynik doświadczenia.

Jaka to sztuka mówi o tym, że LinuxCNC powinien być uruchamiany tylko i wyłącznie na blaszaku?
https://linuxcnc.org/docs/html/getting- ... ments.html
Nie dorabiaj głupoty do swoich ideologii.

Ja wyprodukowałem i sprzedałem kilka maszyn na linuxcnc, wszystkie z laptopami.
Sam także używam maszyn z laptopami. Nie ma żadnych problemów przez kilka lat codziennej pracy.
To, że ty sobie coś ubzdurałeś, nie oznacza, że to jest prawdziwe.

tuxcnc pisze: ↑

02 lip 2023, 08:40

Tak samo deweloper Linuxcnc powinien testy robić na wyselekcjonowanym blaszaku, co do którego jest pewność że sprzęt nie robi lagów (na przykład) w ethernecie.

Ja w przeciwieństwie do ciebie problem rozgryzam od podszewki, bo tworzę rozwiązanie a nie adaptuję czyjeś rozwiązanie.
Przyczynę problemu z ethernetem znalazłem i nie ma to nic wspólnego ze sprzętem lecz z systemem i mechanizmem zarządzania obsługą przerwań. Ten sam system na blaszaku w ten sam sposób będzie działał.

Ty pewnie nawet nie wiesz czy i w jakim czasie ramki dochodzą w swoim colorcnc i dlatego potem piszesz takie głupoty:

tuxcnc pisze: ↑

25 cze 2023, 19:22

Konfiguracja plików hal i ini była drogą przez mękę, nic nie chciało działać i nie było wiadomo dlaczego. Wygląda na to, że kontroler ma swoje ulubione parametry, przy których działa dobrze i stabilnie,

Jeśli coś u mnie nie działa, to wiem gdzie i dlaczego, bo wszystko jest kontrolowane.
Czasami schodzi mi dłużej ze znalezieniem rozwiązania, bo nie jestem informatykiem a linuxem bawię się od niedawna.
A jakie wpisać parametry wiem, bo wiem jak moje urządzenie działa i jakie ma możliwości. Nie muszę zgadywać jak ty, na swoim "wyselekcjonowanym blaszaku".

tuxcnc pisze: ↑

02 lip 2023, 08:40

Tym wszystkim co wypisujesz tylko potwierdzasz, że jesteś ignorantem i partaczem, a twoim klientom należy współczuć...

To nie ja odlutowuję układ SMS nożykiem do tapet i pokazuję to publicznie jako "to właściwe rozwiązanie" więc kto jak kto, ale ty o partactwie w stosunku do innych nie powinieneś nawet wspominać. A jak ci zwrócono uwagę, to się obraziłeś jak kompletny ignorant.

Twój problem polega na tym, że kreujesz się na guru, wmawiając innym swoje przekonania jako te jedyne słuszne.
A ja co chwile obalam twoje mity i głupoty i nie potrafisz się z tym pogodzić.

Małe podsumowanie.
Ostatnie dyskusje z tego wątku:
linuxcnc-na-usb-poszukiwane-chetne-osob ... ml#p843563
będę kontynuował tutaj, ponieważ dotyczą wersji z ethernetem.
Udało się zapanować nad determinizmem czasowym z wykorzystaniem ethernet, "uporządkowując" przerwania.
Pierwsza sprawa to isolcpus które należy zrobić zaraz po instalacji systemu z linuxcnc - o tym już na forum było tutaj:
isolcpus-t103711.html
więc nic więcej dodawać nie trzeba.
W tym przypadku odizolować trzeba 2 rdzenie - jeden dla procesu rt linuxcnc, drugi do obsługi przerwania od ethernetu.
Ja mam 8 rdzeni więc odizolowane mam rdzenie 6 i 7. Tutaj też warto wyłączyć całe rdzenie, jeśli jest to rdzeń HT, czyli jeśli mamy 4 rdzenie po 2 wątki, to trzeba odizolować całe rdzenie. Może nawet warto 2 rdzenie czyli 4 wątki, jeden rdzeń na proces rt, drugi na obsługę przerwania, i tak jeszcze 2 rdzenie zostanie wolne do pozostałych zadań.
Druga sprawa, to wyłączenie/zatrzymanie irqbalance.
irqbalance to narzędzie, które rozdziela przerwania sprzętowe pomiędzy procesory w celu poprawy wydajności systemu. Domyślnie działa jako usługa w tle, ale można go uruchomić także tylko raz, dodając opcję --oneshot.
Ja chcę ręcznie przypisać przerwanie od ethernetu do konkretnego rdzenia, więc irqbalance wyłączam.
Robi się to poleceniem: Następnie trzeba odnaleźć które przerwanie odpowiada karcie ethernet:
Od razu też widać jaką nazwę ma karta (tutaj eno1) oraz do którego rdzenia została przydzielona (CPU3).
Teraz idea jest taka, że albo trzeba odizolować rdzeń do którego została przydzielona, aby miał on czas zajmować się tylko tym przerwaniem, albo na sztywno przypisać do przerwanie (na tym komputerze 28) do rdzenia odizolowanego (CPU6).
CPU7 pozostawiamy wolny do użycia przez proces rt linuxcnc.
Przypisanie odbywa się za pomocą maski bitowej przekazywanej w postaci szesnastkowej.
Czyli rdzeń numer 6 będzie miał maskę 0x40.
Przypisanie rdzenia odbywa się komendą: Działa to w aktualnej sesji systemu, po ponownym uruchomieniu trzeba zrobić to od nowa, dlatego napisałem skrypt, który można dodać do automatycznego uruchamiania przy starcie systemu, tak aby o tym nie myśleć: Oprócz tego przeglądnąłem jeszcze metodę obliczania opóźnienia pomiędzy odczytem wejść a wysterowaniem wyjść.
Na to opóźnienie składa się kilka rzeczy:
-czas buforowania wejść
-czas przesłania bufora wejść
-czas buforowanie wyjść
-czas przesłania bufora wyjść
-opóźnienie wewnętrzne linuxcnc (wynikające z okresu SERVO_PERIOD)
SERVO_PERIOD domyślnie ustawione jest na 1ms i prawdopodobnie nikt tego nie zmienia.
Wartość ta zaokrąglana jest do całkowitej wielokrotności okresu bazowego (BASE_PERIOD).
1 ms to wartość odpowiednia dla większości zastosowań ale...
No właśnie. Tu trzeba zrobić rachunek, czy się opłaca zmieniać i czy warto.
Jeśli mamy ruch synchroniczny, to w najgorszym wypadku przy okresie 1 ms rozpoczynamy ruch z 1 ms opóźnieniem.
Przy odczytu sygnałów (np limity) zatrzymanie nastąpi w najgorszym wypadku po 1 ms. (to akurat nie powinno mieć znaczenia). Ale nie chce mi się nad tym teraz zastanawiać, ten temat jeszcze przemyślę.
Ja u siebie USTAWIŁEM BASE_PERIOD 40us i SERVO_PERIOD 80us i działa prawidłowo.
Po co SERVO_PERIOD tak nisko? No bo w tym przypadku opóźnienie (odczyt wejścia do wysterowania wyjscia) sumuje się z czasem SERVO_PERIOD (w najgorszym wypadku).
Zrobiłem więc przegląd metody obliczania opóźnienia i miałem błąd (nie uwzględniałem do tej pory czasu transmisji wraz z całą otoczką). Zrobiłem zatem pomiar tego opóźnienia (zamiast obliczania) i możliwość wyświetlenia go w linuxcnc. Dodatkowo dorobiłem w linuxcnc wyświetlenie błędu zbyt dużego opóźnienia (gdyby takie zaszło) po przekroczeniu ustawionego w pliku konfiguracyjnym progu. W ten sposób po dobraniu parametrów jest pewność, że opóźnienie nie jest większe niż próg a więc jest zagwarantowana odpowiednia dokładność działania np. ruchów synchronicznych.
Aktualnie udało się uzyskać opóźnienie (całkowite) w przedziale 1.2-1.5 ms.
Da się to także łatwo sprawdzić, wykonując prosty test.
Jedno z wejść skonfigurowane jako wejście limitów, jedno z wyjść jako wyjście włączenia wzmacniaczy.
Obydwie linie podłączyć na 2 kanały oscyloskopu.
Zmieniając stan wejście wyzwalany zostaje pomiar oscyloskopem a czas pomiędzy zmianą stanu wejścia a zmianą stanu wyjścia to całkowity czas opóźnienia.

Jeśli taki sam test zostanie wykonany na fizycznym porcie LPT ale pozostawimy SERVO_PERIOD na 1ms to to opóźnienie zmierzone będzie się wahać pomiędzy 0 a 1ms.

drzasiek90 pisze: ↑

05 lip 2023, 09:15

Udało się zapanować nad determinizmem czasowym

Przypomniało mi się to powiedzenie, jak to w socjalizmie dzielnie zwalczano problemy nieznane w innych systemach...
Blaszak, Ryzen 5, bez dłubania w przerwaniach:

Blaszak nie ma tu nic do tego.
Który rdzeń obsługuje przerwanie Ethernet?
Jeśli na sztywno nie przydzielisz przerwania do rdzenia który nie jest używany przez system, jaka masz pewność, że nie będzie ono obsługiwane przez rdzeń który nagle dostanie coś ważnego do zrobienia? To nie film który się może przyciąć. Tu musi każda ramka dojść na czas, inaczej o kant tyłka można to rozbić.
Poza tym masz tam pewnie rdzeni od groma więc jest w czym przebierać, nie trudno o rdzeń który nic nie robi.
Ale kto taki komputer daje do maszyny?
Uruchom to samo na komputerze 2 lub 4 rdzeniowym, może być blaszak skoro twierdzisz, że obudowa ma znaczenie

Czy 10.10.10.33 to urządzenie zewnętrzne podłączone do komputera kablem?
Robilem kiedyś z kolegą taki test na czas dostarczania pakietów i nie wychodził dużo gorszy niż jemu. Jemu wychodziło po kilka us. Zachodziłem w głowę czemu tak jest a okazało się, że on wysłał i odbierał na tym samym komputerze, miał 2 karty sieciowe. Okazuje się, że gdy podłączył ze sobą 2 komputery to wynik miał już zbliżony do mojego.

Dodane 16 minuty 2 sekundy:
Odnalazłem fotkę która wysyłałem wtedy koledze.
Komunikacja udp między dwoma laptopami, jądra nie rt.


Czasy chyba podobne jak na "blaszaku"

Robisz zupełnie inny test więc nie ma co porównywać.

drzasiek90 pisze: ↑

05 lip 2023, 19:28

Czy 10.10.10.33 to urządzenie zewnętrzne podłączone do komputera kablem?
Robilem kiedyś z kolegą taki test na czas dostarczania pakietów i nie wychodził dużo gorszy niż jemu. Jemu wychodziło po kilka us. Zachodziłem w głowę czemu tak jest a okazało się, że on wysłał i odbierał na tym samym komputerze, miał 2 karty sieciowe. Okazuje się, że gdy podłączył ze sobą 2 komputery to wynik miał już zbliżony do mojego.

Nie jestem oszustem.
10.10.10.33 to karta Colorlight 5A-75B z wgranym firmware Litex-CNC.
Komunikacja kablem skrosowanym.
Wynik zupełnie przypadkowy, pojęcia nie mam czy da się szybciej, zresztą mi na tym szczególnie nie zależy, raczej chodzi o to żeby opóźnienie było stabilne i powtarzalne.
Laptop na AMD A10 ma akceptowalne parametry, choć trochę gorsze (jitter rzędu 30 tysięcy) ale jak się procesor zagrzeje, to robi lagi na prawie milisekundę i nic się z tym zrobić nie da, no chyba że wywalić obudowę i zainstalować wiatrak z blaszaka...
Ale zupełnie nie o to chodzi.
Badasz prototyp, więc powinieneś mieć takiego blaszaka jak ja i na nim testować.
A to czy da się użyć laptopa sprawdzić dopiero później.
Tak czynią naukowcy - eliminują wszelkie czynniki, które choćby potencjalnie mogą mieć wpływ na wynik doświadczenia.

tuxcnc pisze: ↑

05 lip 2023, 20:33

Nie jestem oszustem.
10.10.10.33 to karta Colorlight 5A-75B z wgranym firmware Litex-CNC.
Komunikacja kablem skrosowanym.

Jak ramki lecą i wszystko ci się pcha na konsolę, to możesz nawet nie zauważyć jak czasem wskoczy większy wynik.(jeśli lag jest, bo wcale nie musi ponieważ rdzeni masz tam jak mrówek więc obsługa tego przerwania została przydzielona zapewne do wolnego rdzenia.

Ja sprawdzam maksymalny czas w okresie 2 sekund i go wyświetlam co 2 sekundy tak więc żaden nawet najmniejszy lag nie umknie mojej uwadze.
I rdzeni nie mam tak dużo, jak odizoluję 2 to pozostałe 6 mają cały czas robotę.

I w tym teście nie jest istotny czas pomiędzy ramkami lecz maksymalne odchylenie od okresu wysyłania ramek.

U mnie maksymalna częstotliwość ograniczona jest też sprzętem z jakiego złożone jest to urządzenie i to nie jest w tym momencie parametr do porównania.
To jest mały, tani i prosty mikrokontroler, który dostępny jest niemal w kiosku ruchu i z prostą instrukcją zaprogramować go da rady nawet ktoś, kto nie rozróżnia kondensatora od diody. Do tego prosty i tani moduł ethernet dostępny również niemal w każdym sklepie z elektroniką. Takie było założenie, aby urządzenie składało się z podzespołów prostych, tanich i łatwo dostępnych.
Może kiedyś przyjdzie czas na zmianę sprzętu.

tuxcnc pisze: ↑

05 lip 2023, 20:33

Badasz prototyp, więc powinieneś mieć takiego blaszaka jak ja i na nim testować.
A to czy da się użyć laptopa sprawdzić dopiero później.

Zdecydowanie odwrotnie.
Jeśli laptop ma być tym potencjalnie trudniejszym środowiskiem to właśnie na nim trzeba badać.
Jak przejdzie testy w gorszym środowisku, w lepszym będzie działać na pewno.
Dla tego urządzenia targetem jest laptop.
To tak jakby budować samochód terenowy, ale testować go i modyfikować bazując na testach tylko na asfalcie.
A co jak w teście terenowym okaże się, że nie spełnia założeń i cały projekt w kosz?

Oczywiście blaszak też może być, ale głównym targetem jest laptop więc moja praca byłaby bezsensowna, gdyby działało na blaszaku a na laptopie nie.
Poza tym problemy o których pisałem są istotne i zdarzyć się mogą również na blaszaku.
A jeśli laptop spowodował, że się uwidoczniły już teraz, to tym bardziej uzasadnione jest, że robię to na laptopie, bo pozwoliło to problem wyłapać już teraz i znaleźć rozwiązanie, a nie dopiero u potencjalnego klienta.

tuxcnc pisze: ↑

05 lip 2023, 20:33

Tak czynią naukowcy - eliminują wszelkie czynniki, które choćby potencjalnie mogą mieć wpływ na wynik doświadczenia.

To nie jest doświadczenie a ja nie jestem naukowcem. Nie obrażaj pan.
Ja jestem konstruktorem a to jest prototyp urządzenia w trakcie budowy i testów w warunkach do jakich zostało przewidziane.
To 2 zupełnie inne sytuacje.

Wiem, że starasz się kolejny raz udowodnić, że laptop się nie nadaje do linuxcnc ale kolejny raz pudło.
To nie laptop jest przyczyną opisywanych wcześniej problemów lecz zbyt mała liczba dostępnych rdzeni do zapotrzebowania systemu + procesów rt, co powoduje, że przerwanie od ethernetu przydzielane jest do rdzenia, który oprócz tego wykonuje także inne zadania.
Gdyby mój laptop miał przykładowo 24 rdzenie to zapewne problemu bym nie zauważył.

Jeśli budujesz rozwiązanie które ma działać nie tylko na twoim komputerze i wiesz o tym co wyżej napisałem a mimo to nadal pozostawiasz to jak sam nazwałeś "bez grzebania w przerwaniach", to znaczy, że jesteś ignorantem, bo problem ten prędzej czy później, na tym lub innym komputerze wystąpi.
Zasłanianie się "u mnie działa" nie spowoduje, że u innych też zawsze będzie działać.

Nie chcę robić burdelu w cudzym wątku, więc ograniczę się do informacji, które mogą się przydać autorowi wątku.

U mnie działa.
Na razie wykonałem tylko podstawowe testy i nie zanosi się żebym w najbliższym czasie zrobił dokładniejsze, bo mam urwanie głowy w robocie i ani czasu, ani siły na hobby.
W każdym razie "naciąłem" precyzyjny gwint o skoku 10 mm przy około 240 rpm używając G33.1.
To bardzo istotne, że to jest gwintowanie na sztywno, podkreślam żeby komuś się nie pomyliło ze "zwykłym" G33, do którego i jeden impuls na obrót wystarczy.
Czyli parametry zupełnie użyteczne, choć żadnej rewelacji nie ma.
Szybciej na pewno się da, ale udawane wrzeciono nie wyrabia
Program puszczałem wielokrotnie i za każdym razem pisak trafiał idealnie w poprzedni ślad.

Moje stanowisko wygląda tak:

Nie będę komentował trytytek i kleju na gorąco autora wątku, bo czasem robi się taki badziew i jest on wystarczający do prostych testów. Ja jednak uznałem, że jak chcę mieć wiarygodne wyniki, to powinienem zrobić porządny model.
Na zdjęciu widać:
1. Model tokarki z chińskich miniaturowych modułów liniowych https://www.aliexpress.com/item/1005004275455626.html Moduły są bardzo fajne, tylko mają spory luz na nakrętce pociągowej, co zresztą widać - "gwint" tworzy podwójna linia, ale nie jest to żaden błąd sterownika, tylko właśnie backlash napędu, błąd czysto mechaniczny. Pisak jest z chińskiego plotera (jak ktoś potrzebuje to można kupić jako część zamienną https://www.aliexpress.com/item/10000001190359.html ) Jest to o tyle fajne, że wkład od długopisu jest na sprężynce (ale odwrotnie niż w długopisie) i chowa się jak się go za mocno dociśnie, a dzięki kołnierzowi da się go precyzyjnie i jednoznacznie zamocować (u mnie w wydruku 3d z PLA). Jako wrzeciona użyłem silnika krokowego, ale to z lenistwa, bo kupiłem silniczek 775, moduł PWM i enkoder 1000 ppr. No po prostu napisanie programu na ATtiny 44A było nie tylko dużo łatwiejsze, ale też taki emulator jest mi potrzebny do innych cełów. Na ATtiny bo Uno/Nano nie da się zasilać 3,3 V, a sygnałów o takim poziomie napięcia potrzebuje płyta Colorlight. Program jest wyjątkowo prosty, a obsługuje zarówno sterowanie silnika z rampami, jak i generowanie sygnałów wirtualnego enkodera. Mówiąc inaczej, ATtiny wysyła zsynchronizowane ze sobą impulsy STEP/DIR oraz A/B/Z, a sterowany jest sygnałami FORWARD/REvERSE. Te rampy są bardzo istotne, bo nie tylko zapobiegają gubieniu kroków przez silniczek, ale też (co nie mniej ważne) udają inercję rzeczywistego wrzeciona (po zdjęciu sygnału włączającego wrzeciono kręci się ono jeszcze przez chwilę i generuje impulsy enkoderowe). Niestety mój ulubiony ATtiny 13 ma za mało pinów, choć program mieści się w kilobajcie flasha.
2. CNC-shield - opisywać nie ma sensu, bo jest mnóstwo dokumentacji w necie.
3. Wspomniany ATtiny 44A sterujący wrzecionem i udający fizyczny enkoder.
4. Płyta Colorlight 5A-75B z wgranym firmware Litex-CNC skompilowanym przeze mnie, z moją uniwersalną konfiguracją (dziewięć osi STEP/DIR, dwa enkodery z indeksem, trzy enkodery bez indeksu, sześć PWM, osiem uniwersalnych wyjść i dwanaście uniwersalnych wejść - dla użytkownika portu LPT to musi być szok...). Płyty dokładnie nie testowałem, bo nie mam takiego potwora o dziewięciu osiach, ale dla trzyosiowego plotera (CNC3018) i opisywanego modelu tokarki napisałem konfiguracje i wszystko działa bez zarzutu.
5. ST-Link przerobiony na DirtyJtag (był niedawno używany i tak został...)

Filmów nie będzie (przynajmniej na razie), bo nie mam na to ani siły, ani ochoty.
W planach jest rzeczywiste wrzeciono (silnik 775 ze sterowaniem PWM i fizyczny enkoder 1000 lub 2000 ppr), ale raczej na jesieni lub zimą, bo teraz nie mam czasu, za to mam ważniejsze projekty.

Ciesze się, że mój model tokarki zainspirował cię do zrobienia swojego - jeszcze niedawno narzekałeś że nie możesz dalej sprawdzić bo nie masz odpowiedniego sprzętu.
Przytyki o trytkach i kleju na gorąco są zupełnie niepotrzebne i trochę dziecinne. Chyba, że oczekiwałes pochwały noto proszę - twoja prowizorka jest mniej prowizoryczna od mojej.
Ja nie należę do osób, które się o takie rzeczy obrażają. A wręcz sam się przyznałem, że model ukleilem. A wygląda jak wygląda, bo zrobiłem z tego co miałem pod ręką w jeden wieczór.
A mimo, że był ulepiony to nie wykazywał luzu nawrotnego jak u ciebie. Tak więc klei i trytki wcale nie muszą oznaczać kiepskiego stanowiska pomiarowego. Dlatego to mnie trochę dziwi:

tuxcnc pisze: ↑

18 lip 2023, 20:41

uznałem, że jak chcę mieć wiarygodne wyniki, to powinienem zrobić porządny model.

Bo twój "porządny model" zepsuł wynik już na starcie przez ten luz.

Ciesze się również, że na Colorcnc podobnie jak na linumeric-lpt da się zrobić gwintowanie na sztywno. Czy rozwiązałes problem z ograniczeniami tego rozwiązania, jak np. niska prędkość posuwu?


Szkoda tylko, a może nie szkoda, że uruchomienie Colorcnc jest poza zasięgiem przeciętnego konstruktora maszyn. Śledziłem trochę wątek na forum linuxcnc i dało się zauważyć, że kto się za to nie zabrał to napotykał inne problemy.
Myślę, że nawet gdyby dziś powstała instrukcja krok po kroku, to i tak pojawiałyby się masa nowych problemów nie wykrytych wcześniej - a to jakaś inna wersja pakietu, a to ktoś coś już miał zainstalowane a nie wspomniał, a co coś się zmieniło i już się nie kompiluje.
Jeśli to faktycznie jako tako działa, to trzeba teraz czekać aż to ktoś przygarnie pod swoje skrzydła i uczyni przyjazne dla ludzi.

drzasiek90 pisze: ↑

19 lip 2023, 20:42

Bo twój "porządny model" zepsuł wynik już na starcie przez ten luz.

Każdy mechanizm ma jakiś luz, w szczególności amatorskie konstrukcje na chińskich podzespołach.
Na rzeczywistej tokarce też mam luzy na nakrętkach kulowych i sam doskonale wiesz, że się tego nie da uniknąć, bo jak w jednym miejscu skasujesz, to się w drugim będzie zacinać...
Cóż, po prostu trzeba będzie zrobić programowe kasowanie backlasha.

drzasiek90 pisze: ↑

19 lip 2023, 20:42

Czy rozwiązałes problem z ograniczeniami tego rozwiązania, jak np. niska prędkość posuwu?

Dzisiaj zamówiłem takie cudo: https://www.aliexpress.com/item/1005004421098423.html
Założę enkoder, dodam PWM i będę testował dalej.

drzasiek90 pisze: ↑

19 lip 2023, 20:42

Szkoda tylko, a może nie szkoda, że uruchomienie Colorcnc jest poza zasięgiem przeciętnego konstruktora maszyn. Śledziłem trochę wątek na forum linuxcnc i dało się zauważyć, że kto się za to nie zabrał to napotykał inne problemy.
Myślę, że nawet gdyby dziś powstała instrukcja krok po kroku, to i tak pojawiałyby się masa nowych problemów nie wykrytych wcześniej - a to jakaś inna wersja pakietu, a to ktoś coś już miał zainstalowane a nie wspomniał, a co coś się zmieniło i już się nie kompiluje.

Tutaj niestety masz rację.
Jak napisałem autorowi Litex-CNC, że jego projekt jest bezużyteczny z powodu braku dokumentacji i przykładowych konfiguracji, to mi odpisał że on robi to za darmo, ma pracę, dom i inne obowiązki, a potem zbanował mnie na swoim Githubie. No niestety, z takim urażonym narcyzem to się do niczego nie dojdzie...
Na szczęście zdobyłem potrzebne mi informacje i mogę skompilować działający firmware, ale nie ukrywam że mam do tego celu specjalną instalację Linuksa, na której absolutnie niczego innego nie robię, właśnie z obawy żeby nic mi się nie popieprzyło.
No i ta zegarmistrzowska robota z obudowami SSOT, z którą większość chętnych zapewne sobie nie poradzi nigdy...

tuxcnc pisze:po prostu trzeba będzie zrobić programowe kasowanie backlasha

i to jest najlepsze rozwiązanie nawet przy zastosowaniu śrub kulowych gdy pojawia się luz w granicy 0,02mm.