Kilka sterowników na jednym porcie Ethernet

drzasiek90 pisze: ↑

23 cze 2025, 07:11

Przecież ty się zachowujesz identycznie.
Jak otrzymałeś grzeczną uwagę, że przydałany się trochę lepsza instrukcja

To twoje przypieprzanie się bez sensu zaczyna być coraz bardziej irytujące...
Rozmowa jest o błędzie w programie, a ty wyskakujesz z instrukcją....
Nikt nie ma obowiązku pisać instrukcji, ale jeśli publikuje jakiś kod, to powinien poprawić znalezione w nim błędy, bo inaczej jego publikacja nie ma sensu.
Ja pisałem o takich właśnie sytuacjach, kiedy ktoś publikuje niedziałający kod i oczekuje za to wdzięczności...
Tutaj zasada jest prosta:
Nie musisz tego robić, ale jeśli to robisz, to rób to dobrze.
Z niedziałającego kodu nie ma pożytku, to i dziękować nie ma za co...

Pisałem jakiś czas temu o chińskich płytkach na CH32v307 z interfejsem ethernetowym.
Ten projekt miał dla mnie bardzo niski priorytet, ale stanowił swego rodzaju wyzwanie...
Po pierwsze, to są całkiem zgrabne moduły https://www.aliexpress.com/item/1005009058874432.html w cenie niewiele przekraczającej 20 PLN.
Po drugie, ten układ ma wszystko czego potrzeba do zbudowania przyzwoitego sterownika CNC.
Poza tym są same problemy.
Nie to żebym miał coś do samych płytek, ale ich oprogramowanie to czysty masochizm.
Jest takie z pozoru całkiem zgrabne IDE o nazwie Embeetle, w którym jest od cholery przykładowego kodu, oraz straszny burdel i braki w dokumentacji...
Podam Wam dwa przykłady.
Jest taka płytka wzorowana na STM Nucleo https://www.aliexpress.com/item/1005005137425987.html, z wbudowanym programatorem i złaczami do shieldów Arduino, bardzo fajna sprawa, a 60 PLN to jeszcze nie katastrofa.
Kiedyś kupiłem sobie taką jedną, ale później stwierdziłem rzecz oczywistą, że do testów to i owszem, ale do codziennego użytku to trzeba się nastawić na te tańsze (link na górze postu).
Co prawda w tej płytce z programatorem jest możliwość zdjęcia jumperów i użycia jej do zaprogramowania innej płytki, ale postanowiłem nie dziadować i zakupiłem osobny programator https://www.aliexpress.com/item/1005003693318567.html Powiem Wam tyle, że do dzisiaj nie wiem co to jest i do czego służy, bo nie chce mi to współpracować z żadnym układem i żadnym oprogramowaniem. Zacząłem szukać i w końcu doszedłem do tego, że nie potrzebuję wch-link, tylko wch-linkE. Tak, różnica jest w tej jednej literce i użytym innym układzie... Po zakupieniu takiego https://www.aliexpress.com/item/1005005180653105.html mogę programować nim te tanie płytki z Embeetle...
Drugi przykład już czysto softwarowy. Otóż jak pisałem, jest w Embeetle kupę przykładów, które najzwyczajniej nie działają i kompilator się na nich wywala... To z powodu wspomnianego burdelu i braku dokumentacji. Szukając w necie trafiłem na pomocny opis https://forum.embeetle.com/t/ch32v307v- ... mple/829/4
Szczerze mówiąc, to zapewne nigdy bym na to nie wpadł, że to tak właśnie trzeba, bo i niby skąd...
Po zastosowaniu się do porad kompilator przestał wypluwać setki błędów i zaczął kompilować niedziałający kod...
No najzwyczajniej nie było komunikacji, pecet nawet nie wykrywał połączenia ethernetowego i szukaj wiatru w polu...
Zupełnym przypadkiem zauważyłem, że Embeetle z automatu przypisuje do projektu pliki nagłówkowe o dość podobnych nazwach, kojarzących się z różnym sprzętem... No cóż, nic dziwnego że nie działało, skoro próbowało grać równocześnie na kilku fortepianach...
Po usunięciu z projektu wszystkich tych plików oprócz jednego (nie było wiadomo którego, ale to już była wyłącznie kwestia czasu), interfejs ethernetowy cudownie ożył....
W chwili obecnej CH32v307 odsyła do peceta otrzymane pakiety UDP, więc komunikacja działa jak potrzeba.
Przeglądałem też przykłady i wychodzi na to, że enkoder kwadraturowy jest obsługiwany sprzętowo, zasadniczo tak samo jak w STM. Ponieważ ten układ ma w sumie dziesięć timerów, więc nie tylko wrzeciono tokarki, ale i zamkniętą pętlę na liniałach powinno dać się zrobić...
Potencjał to ten układ ma...

Po co pisałem o tym wszystkim?
Żeby wyjaśnić dlaczego nie da się szybko.
Będę to dłubał w wolnych chwilach, ale na pewno będzie sporo problemów do rozwiązania i efektów nie należy się spodziewać w najbliższym czasie...

Witam

rozkładam na czynniki pierwsze gwintowanie g76 i temat synchronizacji osi Z z wrzecionem
ogólny koncept mniej więcej znam , interesują mnie szczegóły takie jak:

-jak to jest zrobione dokładnie w mesie ?, z tego co wywnioskowałem ale nie jestem pewny :
to linuxcnc wystawia sygnał do mesy (index-enable) żeby ten wyzerował sprzętowy licznik w FPGA
tam licznik się resetuje ,linuxcnc dostaje gotową pozycję po resecie sprzętowym indexem jako już gotowe encoder.0.position
motion synchronizuje oś Z na podstawie tego sygnału , czyli mamy sprzętową synchronizacje po stronie mesy
następuje to przy każdym przejściu gwintowania g76

z kolei na temat remory wyszperałem to
w remorze nie następuje reset licznika sprzętowego tylko zatrzask
i przekazanie wartości licznika w chwili indexu do linuxcnc co 1ms
jako remora.PV.0 ,
następnie po stronie linuxcnc w (remora-eth-3.0.c)
jest korekcja o zatrzaśnięta wartość czyli czyli programowa korekcja synchronizacji
czyli teoretycznie remora też powinna poprawnie gwintować
(nie wiem czy nie są różnice w przekazywaniu indexu w róznych remorach )


i teraz mój przypadek (sprzętowo mam wejścia A,-A,B-B,C,-C do 1MHz to jest enkoder ethercatowy )
w tej chwili mam w halu co 1ms dostępne takie sygnały jak :
s32 raw-count czyli licznik surowy resetowany przy starcie zasilania lub programowo przez pin enc-reset
s32 raw-latch pozycja enkodera w chwili zatrzaśnięcia go przez sprzętowy index c,liczba jest niezmienna do następnego zatrzaśnięcia
float enc.count czyli pozycja po resecie sprzętowym przez index - to samo co position w mesa
enc.0.index-enable
czyli generalnie mam dostępne w hal takie piny jak w remorze aktualny i zatrzasniety i takie jak mesie po resecie

gdybym połączył w halu piny podobnie jak w mesie to wydaje mi się że gwintowanie powinno być poprawne jak mesą
szukam potwierdzenia lub zaprzeczenia lub naprostowania moich domysłów,
-test na żywo to sporo roboty

Nie wiem jak jest w MESA, jeszcze się za to nie zabierałem i do wiosny się nie zabiorę.
W Remora jest to totalnie spieprzone i najzwyczajniej nie działa.
W LinuxCNC nie zeruje się liczników sprzętowych.
Synchronizacja odbywa się w ten sposób, że wystawiany jest sygnał index_enable i czeka się aż zostanie on wyzerowany, przed czym powinna zostać wyzerowana pozycja wrzeciona (nie licznik enkodera).
Głupotą jest wysyłanie sygnału index_enable do zewnętrznego kontrolera (chociaż wszyscy tak robią), bo jak z komunikacją coś pójdzie nie tak, to się wrzeciono nie zsynchronizuje nigdy (i tak właśnie dzieje się w Remora).
W moim SpindleEth zrobiłem to tak, że zewnętrzny kontroler wysyła w każdej ramce bieżącą wartość licznika, ostatnią wartość zatrzaśniętą indeksem enkodera i nic więcej. Obsługa index_enable odbywa się po stronie peceta i działa to bezawaryjnie.
Co do raw_count i raw_latch (czy jakby ich nie nazwać) to muszą być typu double (hal_float to tak naprawdę double), bo inaczej polegniesz przy liczeniu prędkości.

Witam
na razie bawię się czymś innym ale wrócę do remory
nawet gdyby nie działało synchronizowanie indeksem g76 przy toczeniu ale
dało by się zrobić poprawny odczyt 3 liniałów
to mam dla niej zastosowanie

dobra to powiedz dokładnie co testowałeś w remorze
pod które piny podłączałeś enkoder A,B,C
który firmware wgrałeś remora-rt1052-3.1.4.beta.bin ?
które pliki pin próbowałeś np? ec500-rt1052-DMA-ENC.txt ?
nie synchronizowało w ogóle czy przy wyższych obrotach ?
czy widać było zmianę wartości pozycji w hal po obrocie enkodera?
czy numeracja-nazwy pinów IN nie była pozamieniana-przesunięta ?

Dodane 1 godzina 32 minuty 42 sekundy:
Witam
co zauważyłem , nie trzyma się autor numeracji pinów
jako enkoderowe wejścia się zgadzają , numeracja jako io są przesuniete o 4
podłączyłem na stole , co udało mi się uruchomić na szybko
dam rade odczytać pozycje 3 enkoderów ,(dobre i to )
ale na wejscia indeksowe nie reaguje w żaden sposób na żadne