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

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

kszumek pisze: ↑

22 cze 2025, 10:48

Witam
nie jestem specjalistą ani nie mam czasu na dogłębną analizę
ale pobieżnie chyba remora przesyła też informacje pozycji w chwili wykrycia indeksu sprzętowego na ec 500
czyli po poprawnym podłączeniu indeksu wpływ opóźnienia pakietów nie powinien mieć wpływu na gwintowanie

Może i wysyła,, ale nic nie odbiera.
W kodzie dla EC500 jest przerwanie łapiące bieżącą pozycję i wpisywana jest ona do bufora transmisji, ale na tym sprawa się kończy. Ani komponent remora-eth-3.0, ani tym bardziej PRUencoder nie używają tej zmiennej do niczego.
Wygląda to tak, jakby autor kiedyś miał świadomość że tak trzeba zrobić, ale kod rozbabrał, porzucił, a o sprawie zapomniał i nie potrafi sobie przypomnieć. Dobrze, że w ogóle chce rozmawiać, bo inni uczestnicy dyskusji ewidentnie chcą mnie spławić...

Na https://forum.linuxcnc.org/18-computer/ ... 290#330518 niektórzy dają już do zrozumienia, że zamierzają się obrazić...
Mnie po prostu szlag trafia, kiedy komuś grzecznie zwracam uwagę, że jego program mógłby działać lepiej, gdyby poprawił pewien błąd, a w odpowiedzi dostaje litanię, że on to robi za darmo, w swoim wolnym czasie, powinienem być mu wdzięczny, a jak mi się coś nie podoba, to mogę napisać sobie własny program...
Ale tutaj trafiła kosa na kamień, bo właśnie zamierzam napisać własny i nie użerać się z kretynami.

A tak merytorycznie, to wczoraj opowiedziałem o tym znajomemu, który nie ma bladego pojęcia o tokarkach, toczeniu i pisaniu programów.
Zrozumiał od razu...
Autorzy skomplikowanego programu nie potrafią zrozumieć, że przez milisekundę wrzeciono 3000 rpm obróci się o 1/20 obrotu...

Tak ogólnie, to nie chodzi o to, żeby gwintować przy 3000 obr/min, tylko o to żeby nikt nie został zaskoczony tym, że przy 100 było ok, a przy 200 wyszedł brak...
Po prostu gwintowanie musi działać prawidłowo w pełnym zakresie obrotów, nawet jeśli komuś nie jest to potrzebne.

Zaczynam mieć dość rozmowy z autorami Remora, bo na razie jest jakbym zadzwonił do serwisu Microsoftu ("Nie rozumiemy o co ci chodzi, ale u nas to działa").

Chyba doprowadziłem do stanu używalności spindleeth-czyli-wrzeciono-przez-ethern ... ml#p879466
W każdym razie testy wypadły pomyślnie.

Zaczynam się poważnie zastanawiać, czy nie dopisać do tego obsługi step/dir i przestać liczyć na cudzą łaskę.
Przetestowałem już mnóstwo projektów dostępnych w necie i nawet jeśli działają, to czegoś w nich brakuje, albo coś jest ewidentnie spieprzone.
Niestety, ale zwracając uwagę autorowi, prędzej można się doczekać bana (co już przerabiałem), niż poprawienia kodu...

kszumek pisze: ↑

20 cze 2025, 08:18

czyli generalnie chyba trzeba wysłać w pakiecie informację ostanie
licznika enkodera w momencie indeksu i dopiero na tej podstawie synchronizować gwintowanie

Nie mam pojęcia jak jest w MESA, ale u mnie właśnie tak to rozwiązałem i wygląda na to, że działa.
Wczoraj napisałem o tym na forum LinuxCNC https://forum.linuxcnc.org/18-computer/ ... 290#330518
Odezwał się autor Remory, ale na razie nie wiem czy załapał w czym problem.
Cóż, jest mnóstwo ludzi, którzy potrafią pisać skomplikowane programy, ale trudno im wytłumaczyć rzeczy proste.
Miałem już takie hece, że po wskazaniu oczywistych błędów, autor zamiast je poprawić, to mnie zbanował na Githubie, a program jak był spieprzony, tak jest do dzisiaj...

kszumek pisze: ↑

12 cze 2025, 08:09

generalnie problem synchronizacji może nie wynika z samego sprzętu
tylko komunikacji w wątku servo_thread, ( standardowy jest za wolny do przesyłania sygnału indeks )

No tak, przesyłanie sygnału indeksu to czysta głupota.
A w EC500 jest to dodatkowo tak spieprzone, że czasem zadziała, ale zwykle nie...
Przejrzałem kod dla EC500 i napisałem o tym na forum LinuxCNC.
Zobaczymy czy autor to naprawi, czy się obrazi...
W moim SpindleETH wymyśliłem jak ominąć przesyłanie indeksu i wygląda na to, że to działa.

---------------

Tak przy okazji, to zakupiłem taką kartę https://www.aliexpress.com/item/1005008691220284.html
(Teraz jest w promocji, normalnie kosztuje około 110 PLN)
Doszedłem do wniosku, że jeśli tylko jest gdzie ją wetknąć, to lepiej zapłacić więcej i nie bujać się ze switchami.
Na razie mogę powiedzieć tylko tyle, że działa.
Przy pięciu interfejsach LAN (piąty na płycie głównej), to chyba tylko o wydajność procesora będzie można się martwić...

Myślę też o interfejsie diagnostycznym, czyli kartach odpytywanych np. dziesięć razy na sekundę. No na przykład do odczytu termometrów DS18B20. Taki czujnik i tak ma sporą bezwładność, ale do stwierdzenia że coś się przegrzewa powinien wystarczyć.
Podobnie z pomiarem napięć zasilaczy czy ciśnień w pneumatyce czy hydraulice, też wystarczy czas zadziałania porównywalny z czasem zatrzymania maszyny, bo szybciej i tak nie ma sensu...

kszumek pisze: ↑

12 cze 2025, 08:09

do czego można wykorzystać sygnały opisane na płycie jako FHA, FHB, SRO ,SJR , WHA, WHB,

To są zwykłe wejścia, tylko mają takie głupie nazwy.

kszumek pisze: ↑

12 cze 2025, 08:09

na złączu mpg też mamy dostępne z 6 wejść tylko
przez co one idą do uC na pcb ?

Z tego co pamiętam, to nie mają żadnych zabezpieczeń i pracują z poziomami 0-5V. Nigdy ich do niczego nie używałem, bo nie chciałem czegoś spalić. Gdzieś w necie jest dokładny opis, ale teraz sobie nie przypomnę gdzie.

kszumek pisze: ↑

12 cze 2025, 08:09

i pytanie czy da się bezpowrotnie uwalić uC poprzez błędne programowanie ?

Na początku tak myślałem, ale wygląda na to, że bootloader jest na to odporny. Opisywałem procedurę programowania na forum i z tego co pamiętam czytałeś to.
Oczywiście zawsze można spalić układ źle podłączając programator.
ST-Link służy zasadniczo do programowania układów 3,3V, ale ma 5V wyprowadzone na złącze...
Po prostu trzeba uważać.
Chińczycy bardzo tanio sprzedają klony programatora J-link firmy Segger. Mam taki programator, ale nie miałem jeszcze okazji go wypróbować. W każdym razie oprogramowanie wygląda imponująco https://www.segger.com/downloads/jlink/
Może z J-link nie będzie takich jajec jak z innymi programatorami obsługiwanymi przez openocd..

kszumek pisze: ↑

11 cze 2025, 16:48

odnośnie pytania o częstotliwość odczytu enokderów

Nie mierzyłem, bo mi się nie chciało, ale tak ogólnie, to EC500 nie nadaje się do tokarki.
Co prawda autorzy zaimplementowali sprzętową obsługę enkoderów, ale niewielki z tego pożytek.
Otóż na wejściach są transoptory, które i tak przycięły by pasmo do kilkudziesięciu kiloherców, ale jakby tego było mało, to jeszcze są tam filtry RC do tłumienia zakłóceń, które jeszcze bardziej psują parametry czasowe.
Dodatkowo, albo czegoś nie wiem, albo obsługa indeksu nie działa (może rozbabrane i niedokończone), w każdym razie mi się nie udało z niej skorzystać.
Ja w swojej tokarce mam EC500, ale tam jest taki enkoder-samoróbka z trzydziestoma szczelinami.
Sygnały A i B idą na enkoder w EC500 i mają na tyle małą częstotliwość, że opisane powyżej problemy nie mają znaczenia, natomiast sygnał Z enkodera idzie też na EC500, ale jako zwykłe wejście.
Ponieważ servo_thread mam ustawione na 0,6 ms, to łatwo policzyć, że jeden obrót wrzeciona nie może trwać mniej niż 36 ms, bo inaczej można zgubić impuls indeksu. To tak teoretycznie, bo jak LinuxCNC złapie synchronizację na drugim czy trzecim impulsie, to też nic wielkiego się nie stanie. W praktyce gwintowanie do jakichś 2000 obr/min powinno działać i faktycznie działa.
No ale to nie jest żadna rewelacja, bo jak dasz gotowy enkoder 50 pr, to już możesz mieć problem.
Jest jeszcze taka opcja, żeby sygnału indeksu nie brać z enkodera, tylko z innego czujnika dającego jeden impuls na obrót wrzeciona, wtedy będzie łatwiej poradzić sobie z zależnościami czasowymi.
Tak, czy inaczej, to czym większe obroty, tym większy błąd indeksu i coraz trudniej trafić we wcześniej naciętą nitkę.

kszumek pisze: ↑

11 cze 2025, 08:46

płyta

Która płyta?

kszumek pisze: ↑

11 cze 2025, 08:46

i może durne pytanie ale czy da się teoretycznie 2 płyty ec 500 pod jeden linuxcnc?

Pytanie absolutnie nie jest durne.
Oczywiście da się, ale trzeba pokombinować.
Remora ma na stałe przypisany IP (10.10.10.10) i porty (27181).
Oczywiście nic nie stoi na przeszkodzie, żeby pracowała z innym IP i na innym porcie, ale trzeba znaleźć odpowiednie deklaracje w kodzie źródłowym i samemu wszystko skompilować. Także komponentowi remora-eth-3.0 trzeba nadać inną nazwę, żeby LinuxCNC wiedział do którego urządzenia się odwołuje.
Jak najbardziej jest to do zrobienia, ale trzeba trochę podłubać.
Czy ma to jakiś głębszy sens?
Niekoniecznie.
LinuxCNC obsługuje dziewięć osi, a EC500 sześć, więc 2xEC500 nie obsłuży 12 tylko 9. Oczywiście można sobie wyobrazić maszynę z dziewięcioma osiami, ale zwykle sześć wystarcza do wszystkiego.
Jeśli nie potrzeba więcej niż sześć osi, to większy sens może mieć dodanie innego (tańszego i prostszego) sterownika.
Zauważ, że EC500 nie obsługuje PWM, ma tylko jedno wyjście 0-10V. W konkretnym przypadku może to stanowić problem.