forestgril pisze: ↑

30 lip 2025, 23:37

Czy to jest przebieg czasowy? Ile czasu trwa przejście między prędkościami?

W ogóle muszę tu wrócić bo też mam „tani chiński enkoder” i też 2500 albo 2000 i to mało jest. Dopytam Kolegę, jak tego użyć, jak będzie uprzejmy pomóc

Ile trwa przejście, to nie mam pojęcia, bo to nie ma związku z działaniem enkodera i Spindle ETH, więc nie wnikałem.
Tak licząc podziałkę, to około 0,1 sekundy.
Wynika to z tego, że wrzeciono jest napędzane serwem AC 750 W i potrafi startować i zatrzymywać się z takimi przyspieszeniami.
Zwykły silnik z falownikiem takiego numeru nie zrobi (zaraz zlecą się tu "specjaliści" i zaczną przekonywać, że nieprawda, bo Lenze za 10 tys. PLN potrafi....)

Natomiast co do enkodera, to ograniczeniem jest pasmo.
Jeśli chodzi o ten model, którego użyłem, to Chińczyk obiecuje co najmniej 100 kHz (to jest parametr na jeden kanał, a nie kwadraturowo), co znaczy że 2500 P/R powinien pracować do jakichś 3000 obr/min.
Ale są enkodery o paśmie kilku kiloherców i z takim wiele nie zdziałasz.

Tani chiński enkoder magnetyczny E6B2CWZ6C, 2500 P/R (10000 kwadraturowo), prędkość wrzeciona ~ 1400 obr./min po lewej i ~ 60 obr./min po prawej. Halscope pokazuje prędkość w obrotach na sekundę.

Poszło w świat...
https://github.com/tuxcnc/SpindleETH
https://forum.linuxcnc.org/27-driver-bo ... spindleeth

Testy nowej wersji wyszły pomyślnie, czego zresztą należało się spodziewać.

Niestety, muszę ten projekt zawiesić, a może i nawet zamknąć na amen.
Powody są dwa.
Pierwszy, to jest lato, ciepło, długi dzień, a ja mam od cholery innych rzeczy do zrobienia. Siedzenie przy komputerze powinienem sobie zostawić na długie i chłodne wieczory, za kilka miesięcy.
Drugi i poważniejszy, to STM32F103 + W5500 okazały się parą nieperspektywiczną. Po prostu ten STM nie ma wbudowanego ethernetu, a W5500 to tylko konwerter serial<->ethernet i choć SPI to bardzo szybki serial, to jednak mowy nie ma o konkurowaniu z mikroprocesorami, które mają kontroler ethernetu wbudowany w swoją strukturę.
Dlatego nie będę już niczego do tego układu dodawał, niech zostanie tak jak jest...

W każdym razie działa i nadaje się do użytku.
(Zarówno firmware, jak i komponent są niekompatybilne ze starszymi wersjami, które należy usunąć bez żalu, żeby się nie plątały i nie były przyczyną irytujących pomyłek...)

Tutaj mała dygresja. Internet jest pełny rozbabranych i porzuconych projektów, które albo nie działają wcale, albo działają w jakimś tylko zakresie, a autorzy są z siebie dumni i oczekują wdzięczności...
Ten projekt jest doskonałym przykładem, że tylko upór i poświęcenie wielu godzin, na z pozoru bezsensowne testy, daje szansę na osiągnięcie zadowalającego efektu.
Niby działało od pierwszej wersji, dawało się naciąć gwint, a zobaczcie sami, ile jeszcze było do poprawienia...
.

Człowiek się uczy przez całe życie...

typedef ... hal_float_t;
A volatile floating-point type, which typically has the same precision and range as the C type double.

Czyli to, co w LinuxCNC HAL nazywa się float jest w istocie double (zmienna zmiennoprzecinkowa zapisywana na ośmiu bajtach, a nie na czterech). Zmienna double ma wystarczającą precyzję, a komponent LinuxCNC łyka ją bez szemrania.
Czyli wystarczy w deklaracji pinów HAL zastawić "float", a w reszcie kodu ustawić typ "double", bo się okazuje, że to jest w istocie to samo...

Im dalej w las, tym więcej drzew...
Testując z enkoderem dużej rozdzielczości natrafiłem na kolejny problem.
Otóż LinuxCNC HAL chce zmiennych typu float, więc takich właśnie użyłem.
Niestety, zmienna float ma duży zakres, ale małą precyzję.
Nie wdając się w matematyczne szczegóły, jest ona zapisana na 24 bitach, które można sobie pomnożyć przez dziesięć do którejś (8 bitów) potęgi, czyli na przykład przechodząc z milionów na miliardy tracimy kolejno jednostki, dziesiątki, setki...
A jak się liczy dziesiątki czy setki tysięcy na sekundę, to nietrudno do tych miliardów dojść...
Ponieważ enkoder zlicza w liczbach całkowitych, to dużo lepiej byłoby użyć zmiennej int64_t, która ma mniejszy zakres, ale na tyle duży że trudno ją przepełnić, a precyzję co do jednostki.
Ale jak pisałem, HAL chce float i nic go nie przekona.
No i tutaj jest problem, bo konwersja pomiędzy zmiennymi różnych typów potrafi dać nieoczekiwane rezultaty...
Dlatego musi to potrwać, bo trzeba wpaść na właściwy pomysł i go dobrze przetestować.
Na razie są obiecujące postępy, ale na wersję V7 trzeba będzie trochę poczekać.

forestgril pisze: ↑

03 lip 2025, 12:37

Dzięki!

To są kody źródłowe, jak rozumiem. A można by to dać na Gitlab?

Co to w ogóle robi? - ja rozumiem, że pozwala z poziomu LinuxCNC, przez pośrednika w postaci STM kontrolować wrzeciono z enkoderem (jakiego typu? nie znam się). Czy pozwala jedynie ustalać prędkość wrzeciona, czy pozycję z dokładnością do enkodera? Parę słów wstępu dla lamera?..

Docelowo chciałbym sobie wysterować - zsynchronizować silnik serwo/krokowy z kątem obrotu wrzeciona tokarki (np dla gwintowania, wiercenia w toczonym przedmiocie z wiertarki na supporcie itp). Ten soft pewnie nie do tego, ale może znajdę inspirację?

Kod jest na licencji GPL i możesz go umieścić gdzie zechcesz, użyć do czego zechcesz, a także dostosować do swoich potrzeb, zasadniczo tylko pod takim warunkiem, że nie zmienisz jego licencji.
Natomiast to co konkretnie opublikowałem współpracuje wyłącznie z LinuxCNC i w takiej wersji nie nadaje się do niczego innego.
Zasadniczo używanie LInuxCNC do jakichś "półmanualnych" maszyn uważam za głupotę, bo zwykle kończy się to tym, że dostajesz 10% możliwości za 90% ceny pełnego CNC...

Wygląda na to, że projekt osiągnął etap zdatności do instalacji na rzeczywistej maszynie.
Po stronie STM32 różnica jest taka, że wstyd się przyznać, ale zapomniałem dać pullupów na wejściach enkodera, co powodowało oczywiste problemy z podłączeniem rzeczywistego enkodera NPN OC. Teraz jest to poprawione.
Po stronie LinuxCNC jest poprawiona procedura obliczania prędkości, co wymaga dłuższego komentarza.
Otóż komponent wystawia dla LinuxCNC dwa piny typu float - pos i vel (pozycja i prędkość).
Z pozycją nie ma żadnego problemu, jak przychodzi kolejny impuls z enkodera, to się go dodaje albo odejmuje (w rzeczywistości działa to trochę inaczej, ale zasada jest taka sama).
Natomiast z prędkością jest poważny problem, bo to zmiana pozycji podzielona przez zmianę czasu. Jeśli spróbujemy liczyć prędkość co jedną milisekundę, a enkoder ma małą rozdzielczość, to będziemy mieli co chwilę sytuacje, że czas minął a pozycja się nie zmieniła... Zero dzielone przez cokolwiek daje zero, a jak już kolejny impuls przyjdzie, to prędkość skoczy nagle do takiej wartości, że średnio będzie prawidłowo, ale LinuxCNC będzie dostawał na zmianę absurdalne wartości (np. 0,0,3... zamiast 1,1,1...). Rozwiązaniem jest oczywiście uśrednienie wartości z kilku kolejnych pomiarów, ale to oczywiście musi trwać określony czas, a czasu nie ma zbyt wiele, bo LinuxCNC musi reagować na zmianę prędkości wystarczająco szybko. Dlatego przede wszystkim trzeba użyć enkodera o dużej rozdzielczości, żeby było jak najwięcej impulsów i żeby po prostu było z czego liczyć.
Ja użyłem enkodera 1000 "kresek" (czyli kwadraturowo 4000 pozycji na obrót) i uśredniania z ośmiu kolejnych pomiarów. Co do enkodera, to niewiele da się poprawić (może 2000 p/r wyrobi, ale dopiero zamówiłem i czekam), natomiast z uśrednianiem to nie wiem czy osiem to optymalna wartość, ale nie jestem w stanie tego sprawdzić, bo po prostu wszystko mi działa...

Tak więc można testować na rzeczywistej maszynie i na razie nie należy się spodziewać kolejnej wersji.
.

Jakby ktoś nie miał ochoty kompilować, to jest gotowy firmware. Działa na F103C8 lub F103CB.
Na inne STM-y trzeba jednak wprowadzić poprawki i kompilować, bo choć to układy podobne, to jednak nie identyczne...
.

Znalazłem trochę czasu.
To naprawdę nie jest takie proste. Co innego napisać coś dla siebie, a co innego publikować dla innych.
Nawet taka głupia sprawa jak testy. Nie miałem żadnej nadającej się konfiguracji, aż wczoraj wpadłem na pomysł, żeby użyć konfiguracji dla LPT, ale bez LPT, żeby LinuxCNC nie krzyczał że nie może znaleźć sprzętu. No i dzikim fartem trafiłem w przykładowych konfiguracjach na to, czego potrzebowałem. Taki symulator, który zamiast kręcić silnikami brzęczy pecetowym głośniczkiem. Normalnie rewelacja. No i skąd miałem wiedzieć, że coś takiego istnieje i jest pod ręką?
Co do samego archiwum, to wersja V4, bo lubię mieć porządek i nie usuwam wersji pośrednich, bo nie wiadomo co się jutro może przydać. Tak więc wersje 2 i 3 istnieją, ale nie nadają się do publikacji i nie będą dostępne.
Tym razem dla Arduino. Można użyć Platformio, ale trzeba by pobrać poprzednią wersję i podmienić pliki na nowsze.
Po prostu nie mam już ani siły, ani czasu żeby się w takie pierdoły bawić.
Kod przetestowany w symulatorze z udawanym wrzecionem na ESP32C3 (lubię te płytki, bo są bardzo małe, bardzo dobre i bardzo tanie, choć kiepsko się nadają do większych projektów).
Nie pisałem żadnej instrukcji, bo jak ktoś sam nie dojdzie co jest do czego, to i tak sobie nie poradzi. Ogólnie to standard, skompilować firmware i wgrać do procka, skompilować komponent LinuxCNC i uruchomić załączoną konfigurację, lub na jej podstawie wprowadzić zmiany do swojej.
Komponent SpindleETH.comp nie jest kompatybilny z poprzednią wersją i jak ktoś już ma zainstalowany, to musi go zaktualizować.
.