SpindleETH czyli wrzeciono przez Ethernet

Nie daję żadnej gwarancji !!!
Nie mam jak sprawdzić na rzeczywistej maszynie.
Mam nadającą się do tego tokarkę, ale musiałbym zrobić kilka przeróbek, a nie mam na to czasu.
Tak więc sprawdziłem tylko analizatorem stanów logicznych i emulatorem enkodera na STM32-C3...
Wygląda na to, że wszystko działa, ale pewności mieć nie mogę.

Układ jest na STM32F103C8T6 (Blue Pill, na Aliexpress poniżej 10 PLN) i module W5500 na Aliexpress kilkanaście PLN), czyli jak ktoś będzie miał fart, to się zmieści w dwudziestu PLN.

Ważne, żeby kabelki pomiędzy płytkami były jak najkrótsze (max 10 cm), bo są z tym problemy.

W kodzie jest zakomentowana linia #define USE_ALL_PINS, bo piny PA13 i PA14 są używane także do programowania układu.
Jeśli są ustawione jako wejścia, to ST-Link nie potrafi zresetować układu i trzeba to robić ręcznie (nic trudnego, ale upierdliwe). Trzeba wtedy przytrzymać przycisk RESET i puścić go kiedy zacznie się programowanie.
Z zakomentowaną linią ten problem nie występuje, ale wspomnianych pinów nie można używać.
Jeżeli mamy nową płytkę i nie zamierzamy jej później reprogramować, to można odkomentować wspomnianą linię i pierwszy raz programowanie pójdzie normalnie, dopiero przy następnych trzeba kombinować,
Układ trzeba programować przez ST-Link (też kilka PLN na Aliexpress), bo USB musi być wyłączone (inaczej tracimy dwa kolejne piny).

Kilka słów o tym, jak to działa.
Układ jest zaprojektowany do obsługi wrzeciona z enkoderem i regulacją obrotów PWM.
Zapewne będą potrzebne dodatkowe układy (PWM->0/10V, albo mduł MOSFET, ewentualnie jakieś transoptory czy inne konwertery napięć), ale to już są kwestie czysto elektryczne i niczego więcej nie trzeba programować, a tylko połaczyć kabelki... Licznik PWM pracuje z szesnastobitową precyzją (o rząd wielkości lepszą niż potrzeba) i częstotliwością 1 kHz .)
Pin SpindleETH.spindle-pwm przyjmuje wartości 0-1 (czyli np. 0.57 to 57% wypełnienia). W pliku HAL można sobie to dopasować komponentem scale. Zresztą ile by nie zrobić, to i tak wszystkim nie dogodzi...
Enkoder jest obsługiwany licznikiem sprzętowym, więc jakiego by nie dać, to powinien zostać obsłużony. Wejście Z (index) jest obsługiwane przerwaniem na zboczu opadającym, więc też o jego długość nie ma potrzeby się martwić. Przerwanie ustawia flagę, która jest wysyłana najbliższą ramką i kasowana. Wynika z tego, że indeks nie może zostać niezauważony, ale może wystąpić opóźnienie nawet długości okresu wątku do którego komponent jest przypisany. No ale raczej nikt nie gwintuje na maksymalnych obrotach. a na dobrym komputerze powinno się zejść poniżej 0,5 milisekundy okresu...
Piny enable i ready działają zgodnie ze swoimi nazwami. Jeśli enable=0, to PWM i wszystkie wyjścia są ustawiane na zero. Pin index-ena synchronizuje przy gwintowaniu, a enc-reset zeruje pozycję enkodera (ten pin też jest io, czyli zostaje zresetowany kiedy tylko zadziała i nie trzeba tego sygnału zdejmować).

Czyli w sumie jeden enkoder z indeksem, jeden PWM, jedenaście wyjść cyfrowych i trzynaście (lub piętnaście) wejść cyfrowych.

STM32F103C6T6 nie będzie działał, ale to niewielkie zmartwienie, bo STM32F103C8T6 kosztuje prawie tyle samo.
Nie wiem jak się będą spisywać chińskie klony, ale tutaj to już loteria, bo za te same pieniądze można kupić zarówno oryginalny ST, jak i niewiadomy układ z nieudolnie podrobionym oznaczeniem.
Wniosek z tego taki, że zamiast trzech płytek u jednego sprzedawcy lepiej kupić po jednej u trzech...
.
Dodane 53 minuty :
Przedobrzyłem...
Miało być do wyboru, czy Arduino, czy Platformio, ale bibliotekę STM32_QuadEncoder umieściłem tylko w folderze SpindleETH/PlayformIO/SpindleETH/lib
W każdym razie ona jest i jak ktoś woli Arduino IDE, to musi ją sobie skopiować do swojego Arduino/libraries

Trwają prace nad wersją V2,
Sprzęt będzie ten sam.
Rozwiązany będzie problem opóźnienia przy synchronizacji.
Usunę bibliotekę STM32_QuadEncoder, bo co prawda działa, ale jest tak spieprzona, że może obsłużyć tylko jeden licznik. Kod będzie przepisany na bezpośrednie operacje na rejestrach.
Usunę te piny hal, których nie ma potrzeby używać.
Zasadniczo to wszystko już mam i działa, ale nie mam czasu zebrać tego do kupy i wykończyć...

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

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

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

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ę?

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