LinuxCNC na USB lub Ethernet - reaktywacja

Dyskusja na temat Linumeric-LPT

Dyskusje dotyczące działania obsługi programu LinuxCNC
Awatar użytkownika

tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 34
Posty: 7884
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: LinuxCNC na USB lub Ethernet - reaktywacja

#141

Post napisał: tuxcnc » 22 lut 2024, 15:49

forestgril pisze:
22 lut 2024, 15:32
założę, że chodziło o
Nie.
Serwo nie jest od tego żeby cokolwiek uniemożliwiać, a już na pewno nie uniemożliwiać nieprzewidywalne.
To jest po prostu bełkot i nic więcej.




forestgril
Specjalista poziom 1 (min. 100)
Specjalista poziom 1 (min. 100)
Posty w temacie: 15
Posty: 124
Rejestracja: 09 paź 2023, 10:20

Re: LinuxCNC na USB lub Ethernet - reaktywacja

#142

Post napisał: forestgril » 22 lut 2024, 16:04

tuxcnc pisze:żeby cokolwiek uniemożliwiać, a już na pewno nie uniemożliwiać nieprzewidywalne


Zgodzę się, że niemożliwe jest uniemożliwienie nieprzewidywalnego :D
Natomiast serwo z przeznaczenia swego jest po to, by osiągać to, co przewidywalne - w miarę możliwości. Ponieważ jednak nie wszystkie stany układu są przewidywalne, trzeba reagować na pojawiającą się odchyłkę od stanu zadanego - czyli na błąd (do tego służy korekcja PID). Przy użyciu funkcji wyższego rzędu, znanych zależności fizycznych itp, można również zareagować na przewidywany błąd w przyszłości. Na przykład po wyjściu z materiału nagle puszcza naciąg śruby i następuje (nieprzewidziane, a może nawet nieprzewidywalne) przyspieszenie a w wyniku jej - nadmierna prędkość. Utrzymanie tego przyspieszenia i prędkości oznaczałyby błąd pozycji w następnych milisekundach. I to należy skontrować siłą hamującą albo zmniejszeniem siły pchalnej :). Ewentualnie można starać się przewidzieć wszystkie takie wyjścia - ale to pewnie trudniejsze niż kontrowanie.

Stąd określenie "kontrowania nieprzewidywalnego" można - zakładając dobrą wolę i świadomość, że druga strona jest tak samo rozumna jak my - nie tylko usprawiedliwić, ale także uzasadnić. Chyba nie warto kruszyć o to kopii... Ja widzę że Obaj Panowie dobrze wiecie, o czym mówicie, a nieścisłości to drobiagi, które warto doprecyzować, bez eskalowania atmosfery :)


Autor tematu
drzasiek90
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 72
Posty: 1769
Rejestracja: 25 kwie 2016, 11:58
Lokalizacja: Jodlowa
Kontakt:

Re: LinuxCNC na USB lub Ethernet - reaktywacja

#143

Post napisał: drzasiek90 » 22 lut 2024, 16:48

tuxcnc pisze:
22 lut 2024, 15:22
Przeczytaj własne słowa tyle razy, aż zrozumiesz jakie głupoty wypisujesz...
Gdy brakuje argumentów, zaczynasz czepiać się za słówka?

Są siły które można przewidzieć, że wystąpią a są takie, których sterownik nie przewidzi, ale musi zareagować (oczywiście nie przed, ale dopiero po wystąpieniu uchybu). Sęk w tym, aby zareagował jak najszybciej, to przesunięcie wtedy jest mniejsze.
forestgril pisze:
22 lut 2024, 15:32
Ej przestańcie się Panowie kłócić, na pewno obaj rozumiecie.
Wytłumaczę ci na czym polega złośliwość tego gościa w stosunku do mnie.
Kilka lat temu podjąłem się budowy sterownika dla LinuxCNC - a w zasadzie przejściówki z USB na LPT.
tux oczywiscie złorzeczył, wróżył że to się nie uda, nie będzie działać itd.
Na jego nieszczęście projekt doprowadziłem do końca i działa zgodnie z założeniami. Na tym sterowniku pracuje wiele maszyn nie tylko w Polsce ale i poza granicą.
Następnie podjąłem temat takiej samej przejściówki ale na Ethernet - znowu tux złowróżył, to nie będzie działać, będzie do niczego, nie da się to, nie da się tamto. Noi na jego nieszczęście znowu doprowadziłem projekt do końca i działa zgodnie z oczekiwaniami.
A tux w międzyczasie podjął temat colorcnc, obrażał się przy tym i wykłócał, potem trzymał w tajemnicy, zarzekał że skończy i na koniec poległ.
Potem miał podejście do Linuxcnc-RIO i znowu poległ.
Ogarnia go zatem frustracja i wchodzi do tego tematu raz na jakiś czas, nabluzga, nawyzywa i odchodzi.
A do tego ma pewne braki w wiedzy ale niestety nie jest w stanie się z tym pogodzić, że to co sobie wymyśli z automatu nie staje się jedyną słuszną racją.

A teraz jeszcze raz wyjaśnienie o co chodzi z tą częstotliwością i błędem do odpracowania.
Po pierwsze, jeśli cała zetka waży 700 kg to nie znaczy, że każda oś ma 700 kg obciążenia.
Na zetce wisi oś Y a potem jeszcze X która jest najlżejsza.

Ale rozważmy takie zadanie - tux pewnie nie zrozumie bo jest zafiksowany ale może innym się przyda.

Założenia:
Dla uproszczenia obliczeń pomijamy opory ruchu.
Masa supportu + detal 100kg.
Luz napędu (na śrubie i łożyskach 0.05mm)
Regulator PID potrzebuje 10 iteracji aby odpracować moment obrotowy potrzebny do przeciwdziałania sile 100N na śrubie.
Na detal podczas obróbki zadziałała siła 100N której wektor jest równoległy do osi śruby.

Obliczenia:
a = 100N/100kg = 1m/s2

Regulator 1 (częstotliwosć 1 kHz)
Regulator potrzebuje 10 iteracji a więc 10 ms aby wypracować moment 100N na śrubie który przeciwdziała dalszemu przesunięciu supportu w granicach luzu śruby.
Po 10 ms z przyspieszeniem 1m/s2 support wykona :
s=ut+1/2​at2
s = 0 + 1/2 * 1[m/s2] * 0.012
s = 0,00005 m = 0.05mm

Regulator 1 (częstotliwosć 20 kHz)
Regulator potrzebuje 10 iteracji a więc 500 us aby wypracować moment 100N na śrubie który przeciwdziała dalszemu przesunięciu supportu w granicach luzu śruby.
Po 500us z przyspieszeniem 1m/s2 support wykona :
s=ut+1/2​at2
s = 0 + 1/2 * 1[m/s2] * 0.00052
s = 0,000000125 m = 0.000125mm

Te obliczenia także zostały nieco uproszczone, ale pokazują istotę problemu.

Dlatego stwierdzenie:
tuxcnc pisze:
22 lut 2024, 13:28
1 kHz wystarczy wszędzie, bo i tak żadna mechanika za nim nie nadąży
Jest JEDNĄ WIELKĄ BZDURĄ!

Ruszenie dużej masy jest niemożliwe z tak dużą częstotliwością (możliwe, ale potrzeba ogromnych mocy), ale ruszenie śruby (gdzie trzeba pokonać tylko bezwładność śruby i opory ruchu śruby) w zakresie luzu jest jak najbardziej możliwe - co można np. zaobserwować, jak taki układ zacznie "grać" gdy się go wzbudzi.


Avalyah
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 3
Posty: 2364
Rejestracja: 29 lis 2015, 00:38
Lokalizacja: Bielsko-Biała

Re: LinuxCNC na USB lub Ethernet - reaktywacja

#144

Post napisał: Avalyah » 22 lut 2024, 17:08

drzasiek90 pisze:e obliczenia także zostały nieco uproszczone, ale pokazują istotę problemu.

Teraz tux zniknie, by powrócić przy kolejnej okazji :wink:


forestgril
Specjalista poziom 1 (min. 100)
Specjalista poziom 1 (min. 100)
Posty w temacie: 15
Posty: 124
Rejestracja: 09 paź 2023, 10:20

Re: LinuxCNC na USB lub Ethernet - reaktywacja

#145

Post napisał: forestgril » 22 lut 2024, 18:17

drzasiek90 pisze:Regulator potrzebuje 10 iteracji a więc 10 ms aby wypracować moment 100N na śrubie

Skąd to wiadomo? Skąd wiadomo ile iteracji i jak ilość iteracji zależy od zadanego momentu?

Poza tym jeśli na śrubach mamy nakrętki kontrujące luz, to problem da się zniwelować, prawda?


cawboy
Specjalista poziom 2 (min. 300)
Specjalista poziom 2 (min. 300)
Posty w temacie: 4
Posty: 426
Rejestracja: 13 mar 2021, 18:23
Lokalizacja: Bydgoszcz

Re: LinuxCNC na USB lub Ethernet - reaktywacja

#146

Post napisał: cawboy » 22 lut 2024, 18:53

Nie wiem czy dobrze zrozumiałem, ale chcesz 5 osiową maszynę na serwach wraz z enkoderami, liniałami, wrzecionem, pewnie też czujnikiem narzędzi, krańcówkami itp "drobiazgami" wysterować za pomocą LPT?
Krak.


Autor tematu
drzasiek90
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 72
Posty: 1769
Rejestracja: 25 kwie 2016, 11:58
Lokalizacja: Jodlowa
Kontakt:

Re: LinuxCNC na USB lub Ethernet - reaktywacja

#147

Post napisał: drzasiek90 » 22 lut 2024, 18:55

forestgril pisze:
22 lut 2024, 18:17
Skąd to wiadomo? Skąd wiadomo ile iteracji i jak ilość iteracji zależy od zadanego momentu?
To było założenie.
Tak naprawdę nie da się tego jednoznacznie określić dla regulatora PID. Zależy to w dużej mierze od nastaw, od rozdzielczości sprzężenia zwrotnego, od całego układu kaskadowego (o ile jest), od warunków początkowych, od obciążenia, aktualnego stanu pracy. Coś trzeba przyjąć do obliczeń. Przy regulacjach przyzerowego uchybu głównym członem który wypracowuje poprawkę jest człon całkujący a on potrzebuje kilku iteracji (gdyby potrzebował jednej, stałby się członem proporcjonalnym)

forestgril pisze:
22 lut 2024, 18:17
Poza tym jeśli na śrubach mamy nakrętki kontrujące luz, to problem da się zniwelować, prawda?
Część problemu tak. Oczywiście najlepiej jest gdy tego luzu nie będzie - lub będzie mniejszy niż oczekiwana dokładność.
Ale jeszcze luz na łożyskach, naciąg śruby (jak sam wcześniej zauważyłeś), o ile występuje.
Poza tym nakrętki kontrujące nie zawsze są dobre - na pewno nie mogą być na sztywno. Natomiast dociskając powodują znacznie zwiększenie oporów ruchu śruby, więc wzrasta zapotrzebowanie na moc napędu.
Jeśli masz maszynę to możesz zmierzyć ten luz.
cawboy pisze:
22 lut 2024, 18:53
Nie wiem czy dobrze zrozumiałem, ale chcesz 5 osiową maszynę na serwach wraz z enkoderami, liniałami, wrzecionem, pewnie też czujnikiem narzędzi, krańcówkami itp "drobiazgami" wysterować za pomocą LPT?
Myślę, że on już wie, że nie.

Awatar użytkownika

tuxcnc
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 34
Posty: 7884
Rejestracja: 26 lut 2011, 23:24
Lokalizacja: mazowieckie

Re: LinuxCNC na USB lub Ethernet - reaktywacja

#148

Post napisał: tuxcnc » 22 lut 2024, 19:05

forestgril pisze:
22 lut 2024, 18:17
drzasiek90 pisze:Regulator potrzebuje 10 iteracji a więc 10 ms aby wypracować moment 100N na śrubie

Skąd to wiadomo? Skąd wiadomo ile iteracji i jak ilość iteracji zależy od zadanego momentu?

Poza tym jeśli na śrubach mamy nakrętki kontrujące luz, to problem da się zniwelować, prawda?
Dokładnie tak.
Jedno z podstawowych praw informatyki mówi, że przetwarzanie błędnych danych daje błędne wyniki.
Dlatego podane obliczenia nie mają sensu.
Serwo działa zupełnie inaczej.
Podam przykład, który powinien szczególnie Cię zainteresować.

Wyobraźmy sobie tokarkę.
Tokarkę bo na tym przykładzie lepiej widać.
Materiał działa na nóż siłą odpychającą suport, śruba kulowa nie jest samohamowna, więc powstaje błąd położenia suportu.
Serwo działa na śrubę siłą proporcjonalną do błędu położenia.
Do tej pory wszystko jasne?
No to powtórzmy jeszcze raz - Serwo działa na śrubę siłą proporcjonalną do błędu położenia.
Można powiedzieć to inaczej - nie ma błędu, nie ma siły.
Czyli nie jest możliwe skompensowanie stałej siły bez błędu położenia.
No po prostu się nie da.

Dlatego wszelkie rozważania o liczbie iteracji, częstotliwości próbkowania, uczeniu napędu, uniemożliwianiu przesunięcia i przewidywaniu nieprzewidywalnego, są pozbawione sensu, bo oparte na błędnych założeniach.

Owszem, serwo się stroi, ale dla jednych, ściśle określonych warunków pracy.
Jeśli zaistnieją takie warunki, to serwo będzie działało optymalnie (ale też nie cudownie).
Czym dalej od tych warunków, tym gorzej...


Autor tematu
drzasiek90
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 72
Posty: 1769
Rejestracja: 25 kwie 2016, 11:58
Lokalizacja: Jodlowa
Kontakt:

Re: LinuxCNC na USB lub Ethernet - reaktywacja

#149

Post napisał: drzasiek90 » 22 lut 2024, 19:27

Coś Ci dzwoni ale nadal jeszcze nie wiadomo w którym kościele.
W głowie się nie mieści, że nie wiesz jak działa regulator PID :shock:

Oczywiście, że serwo odpracowuje błąd.
Ale W regulatorze PID masz także człon całkujący który tak na chłopski rozum (może tak zrozumiesz) służy do utrzymania zerowego uchybu.
Czyli wróćmy do przykładu tokarki, który podałeś.
tuxcnc pisze:
22 lut 2024, 19:05
Materiał działa na nóż siłą odpychającą suport, śruba kulowa nie jest samohamowna, więc powstaje błąd położenia suportu.
W tym momencie Człon proporcjonalny wypracowuje wartość proporcjonalną do błędu, człon całkujący całkuje (sumuje) a więc dodaje (w przypadku regulatora dyskretnego) aktualny uchyb i wypracowuje wartość proporcjonalną do całki (sumy) a człon różniczkujący w tym momencie wykrywa różnicę uchybu (wcześniej był zerowy, teraz jest np. 10) więc wypracowuje wartość proporcjonalną do różnicy uchybu.

Kolejna iteracja, człon całkujący znowu całkuje (więc moment silnika wzrasta), wartość z członu proporcjonalnego spada (bo uchyb spada a wartość z członu różniczkującego jest ujemna (bo uchyb spada).

I kolejna iteracja aż do momentu, gdy uchyb wynosi 0 (bo taki wypracował człon całkujący) i w tym momencie jeśli mamy stałe obciążenie to człon całkujący ma cały czas nacałkowaną wartość (która to stanowi główną wartość aktualnego sterowania). W momencie gdy nagle obciążenie zaniknie, okaże się, że napęd się obróci (przez ułamek sekundy) dopóki człon całkujący się nie wyzeruje (a zacznie się zerować dopiero, gdy uchyb zmieni znak) a więc znowu na chwilę powstanie przeregulowanie (w drugą stronę) aż do momentu, gdy człon całkujący znowu doprowadzi do uchybu 0.

Każda zmiana obciążenia lub zmiana wartości zadanej powoduje powstanie błędu, ale po kilku iteracjach regulator doprowadza do uchybu równego ZERO. Im regulator działa z wyższą częstotliwością a feedback jest większej rozdzielczości, potrzeba krótszego czasu na to, aby uchyb doprowadzić do zera a zarazem maksymalny uchyb również spada.
To się nazywa dynamiczny błąd i jest to bardzo istotny parametr.

Prościej już nie umiem ci tego wytłumaczyć. Poczytaj podstawy,


forestgril
Specjalista poziom 1 (min. 100)
Specjalista poziom 1 (min. 100)
Posty w temacie: 15
Posty: 124
Rejestracja: 09 paź 2023, 10:20

Re: LinuxCNC na USB lub Ethernet - reaktywacja

#150

Post napisał: forestgril » 22 lut 2024, 19:34

cawboy pisze:Nie wiem czy dobrze zrozumiałem, ale chcesz 5 osiową maszynę na serwach wraz z enkoderami, liniałami, wrzecionem, pewnie też czujnikiem narzędzi, krańcówkami itp "drobiazgami" wysterować za pomocą LPT?

Myślałem o karcie MESA, tam można dać więcej rozszerzeń.

No ale na początek chciałbym trzy osie i wrzeciono (falownik).

A jeszcze wcześniej ploter plazmowy na krokowcach, a do tego LPT pewnie wystarczy z nadmiarem.

ODPOWIEDZ Poprzedni tematNastępny temat

Wróć do „LinuxCNC (dawniej EMC2)”