Enkoder w LinuxCNC, toczenie gwintu, parametry

To przyznaj że piszesz głupoty.
Bo coś napiszesz, a jak Ci wytknę błąd to się zasłaniasz że nie gmerasz w LinuxCNC.
To po co piszesz?

atom1477 pisze:To przyznaj że piszesz głupoty

skoro piszę że tokarka działa prawidłowo bez sygnału B to nie są głupoty tylko fakt .A ty skaczesz po forum jak żaba z pęcherzem i nie wiadomo o co ci chodzi czy pies ci zdechł czy szukasz przyjaciela

Nie napisałeś "tokarka działa bez sygnału B" tylko "LinuxCnc wykrywa kierunek obrotów bez sygnału B".
Gdybyś napisał "tokarka działa, ale nie wiem dlaczego bo nie znam LinuxCnc od środka" to by to było co innego.
Ty natomiast wyjaśniasz wewnętrzne mechanizmy działania LinuxaCnc, choć ich nie znasz. Przez co wprowadzasz w błąd.

proponuje wrócić do strony 3 co napisałem o braku sygnału z enkodera B ,jak masz problem z odszukaniem to cytuje
"pinów mam jeszcze kilka wolnych ale nie zauważyłem żeby mi brakowało sygnału B , toczy i gwintuje więcej w tokarce raczej mi nie potrzeba ,jak dla mnie to możecie sobie jeszcze podłączyć dwa piny z enkodera A -/A i B-/B tak dla kompletu żeby wszyscy byli zadowoleni "

tuxcnc pisze: ↑

13 kwie 2023, 14:28

drzasiek90 pisze: ↑

13 kwie 2023, 11:23

Jaka rozdzielczość? 100 imp/obrót? Więcej, mniej?

100 cpr to absolutne maksimum dla portu LPT.
Ja mam u siebie 40 cpr i nigdy nie narzekałem.

Jaki masz BASE_PERIOD i SERVO_PERIOD?
Ciekawostka (pewnie wiesz, ale może nie wszyscy wiedzą), obliczanie wartości z enkodera (między innymi) odbywa się w wątku wywoływanym z okresem SERVO_PERIOD, czyli nie w najszybszym wątku w maszynie. SERVO_PERIOD zaokrąglany jest do całkowitej wielokrotności BASE_PERIOD, a więc jest co najmniej 2 razy wolniejszy od wątku próbkującego wejście na LPT.
Warto o tym wiedzieć, jeśli konfigurację utworzyło się z kreatora Stepconf Wizard, bo on tworzy (a przynajmniej u mnie) wartość SERVO_PERIOD dużo wyższą (10 razy większą) od BASE_PERIOD.
Dlatego korzystając z enkodera na LPT, od razu warto zmienić wartość SERVO_PERIOD na 2 krotność BASE_PERIOD, jeśli komputer to uciągnie.

Tak zacząłem rozkminiać te maksymalne rozdzielczości z enkodera na LPT.
Nikt nie napisał, jaka jest maksymalna użytkowa prędkość obrotowa do toczenia gwintów.
No ale, jeśli weźmiemy enkoder w trybie kwadraturowym, to aby system prawidłowo rozpoznał każdy stan, czas pomiędzy kolejnymi próbkami powinien być krótszy, niż 1/4 okresu impulsu - bo tyle wynosi przesunięcie między sygnałami A i B.
No więc weźmy na warsztat wspomniany enkoder 100 cpr (czyli 25 ppr - impulsów na obrót).
Dla okresu bazowego 100us (narazie pominiemy jitter), to nam daje, że okres jednego impulsu musi być większy niż 400us, a więc czas obrotu enkodera dłuższy niż 400us x 25 = 10000us = 0.01s
Daje nam to prędkość obrotową do 100 obrotów/s czyli 6000 obrotów na minutę.
W praktyce mniej, bo dochodzi do tego jitter, noi musi być jakiś zapas.
No ale nawet jak wyjdzie 5000 rpm to chyba jednak nadal spora wartość i spory zapas, można by się pokusić o 200cpr i 2500rpm?
No chyba, że te 5000rpm jest wartością potrzebną, niezbędną (do czego???)
Wiem, że prędkość wyższa jest używana, ale chyba nie w cyklach synchronicznych?
No chyba, że się chce uzyskać stałą prędkość skrawania, przejazd wykańczający, wysokie obroty.
No ale to tego potrzebna informacja o tym zakresie użytecznych obrotów, gdzie enkoder jest wykorzystywany.
A może walnąłem się w obliczeniach, jest piątek, późna godzina...

drzasiek90 pisze: ↑

12 maja 2023, 22:47

warto zmienić wartość SERVO_PERIOD na 2 krotność BASE_PERIOD, jeśli komputer to uciągnie.

Bzdura.
Ani nie ma powodu żeby to robić, ani w niczym to nie pomoże, natomiast prawie na pewno będą z tego problemy.
Standardowo stosuje się SERVO_PERIOD 1 ms, czyli tysiąc razy na sekundę. Nie znam maszyny dla której byłoby to zbyt wolno.

drzasiek90 pisze: ↑

12 maja 2023, 22:47

No więc weźmy na warsztat wspomniany enkoder 100 cpr (czyli 25 ppr - impulsów na obrót).

Przetwarzanie błędnych danych daje błędne wyniki.
100 cpr oznacza 100 kresek na tarczy, tak oznaczają enkodery wszyscy producenci, czyli przy odczycie kwadraturowym 400 próbek na obrót.
Policz jeszcze raz, to zrozumiesz dlaczego 100 cpr to maksimum.

tuxcnc pisze: ↑

13 maja 2023, 05:19

Ani nie ma powodu żeby to robić, ani w niczym to nie pomoże, natomiast prawie na pewno będą z tego problemy.
Standardowo stosuje się SERVO_PERIOD 1 ms, czyli tysiąc razy na sekundę. Nie znam maszyny dla której byłoby to zbyt wolno.

Ja ustawiłem SERVO_PERIOD na 200us i nie ma kłopotów. Dlaczego miałyby być?
Jeśli można liczyć 5 razy szybciej, oznacza to, że 5 razy częściej kontroler ma obliczoną pozycję i prędkość wrzeciona.
O ile prędkość się tak nie zmienia, to pozycja owszem.

drzasiek90 pisze: ↑

12 maja 2023, 22:47

No więc weźmy na warsztat wspomniany enkoder 100 cpr (czyli 25 ppr - impulsów na obrót).

Przetwarzanie błędnych danych daje błędne wyniki.

tuxcnc pisze: ↑

13 maja 2023, 05:19

100 cpr oznacza 100 kresek na tarczy, tak oznaczają enkodery wszyscy producenci, czyli przy odczycie kwadraturowym 400 próbek na obrót.

Pozwól, że cię zacytuję, w odpowiedzi na twoje pytanie.

tuxcnc pisze: ↑

13 maja 2023, 05:19

Bzdura.

CPR to liczba stanów na obrót (stanów kwadraturowych), PPR to liczba kresek na tarczy.
https://www.rls.si/eng/faq/index/show/c ... dgQAvD_BwE

tuxcnc pisze: ↑

13 maja 2023, 05:19

Policz jeszcze raz, to zrozumiesz dlaczego 100 cpr to maksimum.

Nie trzeba jeszcze raz liczyć. Wystarczy, że już wiemy, że błędnie napisałeś i twoje stwierdzenie

drzasiek90 pisze: ↑

12 maja 2023, 22:47

100 cpr to absolutne maksimum dla portu LPT.

poprawimy na:
100 ppr to absolutne maksimum dla portu LPT
lub
400 cpr to absolutne maksimum dla portu LPT.

I wtedy się zgadza.

drzasiek90 pisze: ↑

13 maja 2023, 09:34

CPR to liczba stanów na obrót (stanów kwadraturowych), PPR to liczba kresek na tarczy.

Nie będę się kłócił, bo formalnie masz rację.
Tyle tylko że producenci na enkoderach podają liczbę kresek na tarczy.
Czyli jeśli enkoder ma 100 kresek to w oznaczeniu występuje liczba 100.
Sprawdziłem u Omrona, tam literalnie piszą P/R, czyli jeszcze inaczej, ale chodzi o liczbę kresek.
Krótko mówiąc, jeśli zamówisz enkoder 100 P/R, to przy odczycie kwadraturowym masz 400 rozróżnialnych stanów.
Podobnie z enkoderami liniowymi, gdzie w nazwie jest podana liczba kresek na cal.
Ale niech Ci będzie, na przyszłość będę pisał "kresek na obrót", żebyś się nie przypieprzał do jednej literki w zdaniu, które jest absolutnie jednoznaczne...

Dodane 33 minuty 53 sekundy:

drzasiek90 pisze: ↑

13 maja 2023, 09:34

Ja ustawiłem SERVO_PERIOD na 200us i nie ma kłopotów. Dlaczego miałyby być?
Jeśli można liczyć 5 razy szybciej, oznacza to, że 5 razy częściej kontroler ma obliczoną pozycję i prędkość wrzeciona.
O ile prędkość się tak nie zmienia, to pozycja owszem.

Wątek servo jest float, a base jest int.
Różnicy chyba nie muszę Ci tłumaczyć.
Natomiast co do prędkości obliczeń, to powyżej pewnej wartości szybciej nie jest lepiej, bo obciążasz procesor, a mechanika i tak nie nadąży.
Planer opiera się na przewidywaniu i korygowaniu błędu, czyli zakłada się pewną prędkość i co jakiś czas sprawdza czy jesteśmy tam gdzie być powinniśmy. Załóżmy że jesteś w Warszawie i chcesz być za dwie godziny w Łodzi (136 km). Ruszasz z prędkością 68 km na godzinę. Co jakiś czas sprawdzasz ile Ci zostało kilometrów, ile minut i korygujesz prędkość tak, żeby podróż trwała dokładnie dwie godziny. Jeśli będziesz to robił co kilometr lub co minutę, to będziesz jechał dość płynnie i precyzyjnie. Jeśli będziesz liczył co sekundę, to niczego nie polepszysz...

Dodane 40 minuty 35 sekundy:

drzasiek90 pisze: ↑

13 maja 2023, 09:34

https://www.rls.si/eng/faq/index/show/cat_id/2/faq/59/

Tak sobie na spokojnie to przemyślałem i doszedłem do wniosku, że tam też piszą głupoty.
Raczej prawda jest taka, że błędem jest użycie pojęcia cpr do enkodera, bo "c" jest faktycznie od "counts", ale przecież enkoder niczego nie liczy, on tylko wystawia stany na wyjściach...
A pisanie o "elektronicznym mnożeniu przez cztery", to już kompletny debilizm.

tuxcnc pisze:Jeśli będziesz to robił co kilometr lub co minutę, to będziesz jechał dość płynnie i precyzyjnie. Jeśli będziesz liczył co sekundę, to niczego nie polepszysz...

Ale jak będziesz miał duże opóżnienie na ostatnim kilometrze to nie zdążysz go nadrobić na końcowych 100 metrach.
To samo jest z enkoderami. Jęśli robisz małe skoki to ok, ale spróbuj zrobić duży skok, wtedy będzie ząbkowanie na gwincie. Przy skoku 50mm jest to u mnie odczuwalne pomimo że mam enkoder 100.

tuxcnc pisze: ↑

13 maja 2023, 15:26

Nie będę się kłócił, bo formalnie masz rację.
Tyle tylko że producenci na enkoderach podają liczbę kresek na tarczy.

Ale nie nazywają tego "cpr", tak jak zrobiłeś to Ty:

tuxcnc pisze: ↑

13 maja 2023, 15:26

100 cpr oznacza 100 kresek na tarczy

tuxcnc pisze: ↑

13 maja 2023, 15:26

Ale niech Ci będzie, na przyszłość będę pisał "kresek na obrót", żebyś się nie przypieprzał do jednej literki w zdaniu, które jest absolutnie jednoznaczne...

Więc nie żadne "niech Ci będzie", tylko drzasiek90 od początku miał pełną rację. A Ty się myliłeś, tylko nie umiesz się przyznać do pomyłki.
W sumie to dalej jesteś w błędzie. Bo nie o zamianę "tarczy" na "obroty" tu chodzi (bo to nic nie zmienia).
Chodzi o zamianę "kresek" na "zliczenia" (to już różnica, bo kresek będzie 100 a zliczeń 400).

PS. CPR oznacza counts per revolution. Czyli "zliczeń na obrót". Zliczeń dla licznika kwadraturowego, czyli liczącego 4 razy szybciej niż wynosi ilość kresek.