Wiem już z forum LinuxCNC, że moje podejście jest rozsądne i jest już "out of the box" w oprogramowaniu.

Tzn ktoś tam mi tak powiedział, ale nie weryfikowałem jeszcze.

kszumek pisze: ↑

20 gru 2023, 19:39

podobne wzrosty można uzyskać dobierając np zasilacz w punkt
tzn zamiast popularnego zasilacza 60 V testować i ustawić na przykład 71V

Bardzo dziękuję za konkretną poradę, nie wiedziałem, a pewnie się przyda!

Dodane 9 minuty 15 sekundy:

jasiekk7 pisze: ↑

20 gru 2023, 19:40

Profesjonalne kontrolery CNC porównują pozycję z liniału z enkoderem serwa - przy określonej różnicy wskazań zgłaszają błąd. A napęd zadaje serwu docelową pozycję i odczytuje ją z enkodera na wale a nie z odczytu z liniału - aż do przekroczenia dozwolonej wartości przeciążenia.

Dzięki, przemyślę to.

jasiekk7 pisze: ↑

20 gru 2023, 19:40

Nie sądzę jednak aby korekta odbywała się przez dodawanie kroków, gdyby tak można to po co dbać o brak luzów jak napędy to skorygują...

Myślę, żę programowo da się wiele zrobić, ale to trochę skomplikowane. Dziś można to robić dynamicznie, ale 20-30 lat temu było to jeszcze chyba niemożliwe albo bardziej kosztowne. Zgaduję, że łatwiej było i w sposób pewnie mniej zawodny, jak ktoś chciał po prostu wykonywać robotę i zarabiać pieniądze, zlikwidować luzy do minimum sprzętowo. Luzy zawsze są złe i w profesjonalnej robocie stosuje się zapewne oba podejścia. Ja chciałbym spróbować swoich sił w wysterowaniu takiego systemu, który będzie dynamicznie te luzy mierzył i brał pod uwagę. Jeśli jeszcze tego nie ma w LinuxCNX? Może @tuxcnc wie?

Gdyby nie było, to jest pole do popisu i napisania takich opensourcowych sterowników, co mogłoby obudzić do (drugiego? trzeciego? ) życia wiele starych maszyn na śrubach trapezowych. Nowe kule śrubowe do nich często są droższe niż sama maszyna.

Dodane 6 minuty 33 sekundy:
BTW wiem już od Maszynotwora (@adam Fx) z jego ostatniego lajwu, że w LinuxCNC nagrywa się mapy zjechania śrub, na które sytem bierze poprawki przy pozycjonowaniu (z tego, co rozumiem). Więc pewnie luzy w LinuxCNC też już są.

Co jednak ważne, luzy liczą się zawsze całkowite (czyli suma luzów wszystkich systemów i to jest funkcja wielowymiarowa), czyli ile muszę jałowo obrócić silnikiem, zanim zacznie się posuw. Ja myślę, że to nawet na bieżąco można by liczyć i uwzględniać w sterowaniu, zwłaszcza gdyby był enkoder silnika zainstalowany. Jestem ciekaw, ile się da uzyskać precyzji przy takim podejściu. Bardziej interesuje mnie precyzja niż szybkość, bo szybkość to przy seriach, a precyzja nawet przy jednostkach się liczy.

jasiekk7 pisze: ↑

20 gru 2023, 17:13

Jest na youotubie film maszynotwora

Dzięki, chyba widziałem, ale się upewnię/przypomnę sobie!

jasiekk7 pisze: ↑

20 gru 2023, 17:13

Poza tym kontroler raczej porównuje pozycję rzeczywistą (z liniału) z zadaną (enkoder albo nawet bez niego) i przy ustalonej różnicy zgłasza błąd a nie "dodaje kroków".

Mówimy o kontrolerze programowym, czy sterowniku elektronicznym? Ja rozumiem to tak, że sterownik serwokrokowca czyta z enkodera i liczy sygnały, które przychodzą na step/dir. Jak mu się nie zgadza, to PWMuje mu odpowiednio (czyli efektywnie dodaje kroki), żeby mu się zgadzało. (Jak mu się nie uda ileś tam razy pod rząd to wchodzi w tryb awaryjny.) Ale to jest zapewnienie (w ramach możliwości momentu obrotowego) tylko dla osi samego silnika.

Kontrola programowa (program C++, LinuxCNC, "whatever"), natomiast może czytać z różnych aktuatorów, w tym - bezpośrednio z liniału. I z mojego rozumienia może zrobić dokładnie to samo co sterownik z enkoderem, tylko dla mnie lepiej. No bo sterownik zapewni nam w końcu kąt silnika. Ale jeśli będą luzy (na przykład na nakrętce przy zmianie kierunku na trapezówce), to kąt będzie zadany i spełniony, ale posuwu na stole nie będzie. A z liniału czytam posuw na stole. Więc jak nie będzie posuwu na stole, to programowo uzupełnię kroki, aż mi się zgodzi.

Stąd przy kontroli programowej nie widzę przewagi serwo-krokowca. Ale zerknę na YT Adama, bo może tam jest jakiś sekret - choć podejrzewam, że przy dużych obrotach, a ja chce pewnie dojść do 600rpm i dość będzie na początek.

Dodane 48 minuty 33 sekundy:

jasiekk7 pisze: ↑

20 gru 2023, 17:13

Jest na youotubie film maszynotwora porównujący takie same silniki z tym, że jeden jest ze sprzężeniem i wypada znacznie lepiej (prędkość, przyspieszenie).

Oto ten filmik.

U Adama maksymalne obroty na krokowcu to 2750, a na serwokroku 3400, różnica około 20%. Dużo? I tak nikt przy frezowaniu stali nie kręci śruby 5mm z takimi obrotami Zresztą moment mocno spada przy tych obrotach, więc to już nie tak istotne. Przy 700 rpm mamy jeszcze około połowy momentu dla obu silników (o ile pamiętam w dokumentacji), dalej będzie tylko gorzej. I to daje przy śrubie 5mm (AŻ!) 3500mm/min, 6cm/sek. To zawrotna prędkość! Mnie na początek przygody wystarczy pewnie 1/3 tego (wiem, że będzie trudno z takim ciężkim stołem jak mój).

Panowie Koledzy... żadna ze mnie konkurencja Chcę tylko założyć te krokowce na 4-tonową frezarkę Heckert, pamiętającą chyba jeszcze lata 70-te Taki eksperyment.

Wstępne obliczenia sugerują możliwość sukcesu, ale z posuwami poziomym raczej poniżej 1000mm/min. Nawet od jednego Kolegi tu kupiłem te krokowce, a od drugiego przekładnię kątową 1:20 (na oś Z, bo sam stół pewnie 500kg waży).

Będę sobie powolutku frezował w stali, jak Bóg pozwoli.

Nie chodzi tylko o cenę, ale w zasadzie o sensowność serwo-krokowca (względnie enkodera własnej roboty, który prawie na pewno byłby droższy - czasowo - niż serwo-krokowiec fabryczny).

Chodzi o to, że ostateczna odpowiedź, o tym gdzie jest frez względem materiału, znajduje się w odczytach z liniałów (no chyba, że frez już leży na podłodze ). Jeśli nie ma pomiaru z liniału, to serwo-krokowiec powinien teoretycznie zapewnić z grubsza pozycjonowanie - ALE TYLKO KĄTA Śruby pociągowej ! To nie uwzględnia luzów między śrubą a nakrętką, na ew. przekładniach zębatych, naciągu pasków między osią silnika i osią śruby itp.

Natomiast jak liniał mówi 756.000, to wiem, że stół jest na 756 +/- 0.005 (albo 0.001) i o to mi przecież chodzi - a nie o zapewnienie konkretnego kąta na silniku.

Jak chcę 756, a jest mniej lub więcej niż 756, to pcham kroki lewo/prawo do skorygowanie pozycji na liniale.

Dodane 2 godziny 5 minuty 33 sekundy:
Tak mi się wydaje na pierwszy i drugi rzut oka... ale diabeł często siedzi w szczegółach, więc czekam na korektę od jakiegoś eksperta skrawania CNC

Dziękuje Koledze (i to Liderowi Forum!) za odpowiedź!

Drugie pytanie łączy się z pierwszym, jeśli taka jest ta pierwsza odpowiedź. A mianowicie - nawet jak filtr jest słaby, to oznacza to po prostu zakłócenia. Czyli nam zgubi mikro-krok albo doda jakiś niechciany mikro-krok - ćwierć biedy na amatorskim retroficie z oczekiwaniem setki dokładności pozycjonowania (bo nam się ten mirokrok (np 1/16) przekłada na 1/200*1/16*10mm na przykład czyli 3 mikrony).

Ale idąc dalej - jeśli mamy informację z liniału pomiarowego, to czego nam więcej potrza? Jak jakiś krok zgubimy, nawet nie musimy o tym wiedzieć, bo nas interesuje pozycja na stole, a nie oszczędność energii. Jak doda nam się mikrokrok, to se skorygujemy programowo (cofniemy troszkę, bo nam liniał powie, że za daleko zajechalim, teoretycznie). Oczywiście, jakby gubił co 1/100 albo więcej, to już niedopuszczalne, ale tego się nie spodziewam.

W skrócie: wydaje mi się, że ostatecznie rządzi liniał (tudzież enkoder osi obrotowej, czy stołu obrotowego). Więc po co przepłacać za zamkniętą pętlę krokowca? (nie mówię o prawdziwym serwo, to już zupełnie inna bajka i wiadomo, że serwo jest królem)

Nikt mnie nie lubi

Czy mógłbym prosić o wytłumaczenie mi jeszcze jednej rzeczy? To pewnie podstawa, ale nie widzę błędu w swoim rozumowaniu.

Załóżmy, że mam liniał pomiarowy i program (np LinuxCNC) skalibrowany, tak że wie, jakich luzów maksymalnie się spodziewać (np przy zmianie kierunku na wymęczonej starej śrubie). I teraz zmieniam kierunek obrotu prostego krokowca (bez pętli sprzężenia). Jak zapodam krok, oczekuję jakiejś odpowiedzi na liniale. Jeśli nie ma odpowiedzi liniału przez N kroków silnika odpowiadających luzowi + ugięcie freza i materiału (czyli może 0.02mm), oznacza to dzwon albo jakiś inny błąd itp.

Czyli wydaje mi się, że mam komplet informacji i mogę zatrzymać program, albo pchać sensowną ilość kroków do sensownej odpowiedzi. Pytanie - skoro mam sprzężenie (informację zwrotną na liniale/enkoderze osi itp), to jakie znaczenie ma pętla sprzężenia z enkodera zamontowanego fabrycznie na silniku? Czy to nie jest informacja redundantna? Czy nie da się sensownie (do setki powiedzmy) wysterować silnika krokowego z liniałem pomiarowym 1mikro?

Cześć Dobry (Człowieku)

Chcę się pobawić w wysterowanie silników krokowych Nema34, 8.5Nm. Is=6.1A, Vs=35V. Zobaczyłem, że robi się to tytułowymi sterownikami DM860 albo/i +jakaś końcówka (H, A, E).
Czym różnią się te stery w zależności od końcówki, czy i kiedy warto dopłacać? Poniżej na przykład Wielki Chiński Brat proponuje końcówkę A w śmiesznie niskiej cenie. Czy należy się bać?

https://pl.aliexpress.com/item/10050059 ... 0UO1ZufJUA

Następne pytanie dotyczy pętli sprzężenia. Czy warto bawić się w dorobienie enkodera i wykrywanie położenia i gubienia kroków z poziomu programu?