SpindleETH czyli wrzeciono przez Ethernet

[tuxcnc]

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

SpindleETH.tar

(310 KiB) Pobrany 43 razy

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

[tuxcnc]

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

[tuxcnc]

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

SpindleETHv4.tar

(50 KiB) Pobrany 39 razy

[tuxcnc]

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

SpindleETHv4-firmware.tar

(80 KiB) Pobrany 31 razy

[tuxcnc]

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

SpindleETHv6.tar

(120 KiB) Pobrany 46 razy

[forestgril]

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

[tuxcnc]

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

[tuxcnc]

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

[tuxcnc]

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

[tuxcnc]

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

SpindleETHv7.tar

(120 KiB) Pobrany 32 razy