drzasiek90 pisze: ↑

15 gru 2025, 19:45

Dedykowanego rozwiązania pod jedną osobę robił nie będę, bo gra nie warta świeczki.

Zupełnie nie o tym myślałem.
CH32V307 ma dziesięć timerów, da się na tym zrobić kilka enkoderów, kilka PWM i jeszcze sporo prostych I/O, czyli naprawdę uniwersalne urządzenie. 60 PLN to kosztuje taka płytka w stylu Nucleo, natomiast taka zwykła (trzeba kupić osobny programator) tylko 25 PLN.
Ja to doprowadziłem do jednego działającego enkodera z indeksem i stwierdziłem, że w tej chwili więcej nie potrzebuję.
Fajnie by było, gdyby się znalazł ktoś, komu by się chciało dokończyć projekt.
Ale oczywiście namawiać nie będę.

drzasiek90 pisze: ↑

15 gru 2025, 17:10

Podaj trochę więcej szczegółów tego co chcesz osiągnąć, będzie łatwiej pomóc.

Jak chcesz pomóc, to mogę podrzucić Ci na PW mój rozbabrany projekt na CH32V307 (to ta płytka z Ethernetem za 60 PLN albo i taniej).
To jest wersja mojego SpindleEth, doprowadzona do stanu obsługi jednego enkodera i współpracy z LinuxCNC.
Żeby to przepisać na cztery enkodery wystarczy trochę kodu paste/copy i zmienić nazwy rejestrów.
Mi się nie chce, bo mam co innego do roboty.

marekms pisze: ↑

15 gru 2025, 15:57

Chcę zbudować coś w rodzaju ramienia pomiarowego a nie dokładnie ramię pomiarowe. Przyjmując ramię 2000mm, enkoder 400 p/r daje rozdzielczość na poziomie 80mm, ale przy 1000p/r rozdzielczość wynosi 32mm a to jest wielkość akceptowalna dla tego projektu.

Marek

Po raz ostatni:
Stan enkodera musi być odczytywany częściej niż się zmienia, więc liczy się prędkość chwilowa. Jeśli szarpniesz dwumetrowym ramieniem, to na pewno zgubisz pozycję (bezwładność, ugięcie, oscylacje).
Potrzebujesz szybkiego mikroprocesora z licznikami w trybie sprzętowej obsługi enkodera kwadraturowego, najlepiej coś z rodziny STM32, bo są tanie i produkowane od lat, więc mają dobrą dokumentację i dobre wsparcie.
Ale wtedy też nie zrobisz cudów, bo ograniczy Cię pasmo użytych enkoderów.
Przerabiałem ten temat bardzo dokładnie, kiedy robiłem szybki odczyt enkodera wrzeciona tokarki.
To wszystko co mam do powiedzenia w tym temacie, a Ty rób sobie co chcesz.

marekms pisze: ↑

15 gru 2025, 13:47

Raczej myślałem o enkoderach 400-1000p/r i sprzęgnięcie 1:1 , dodatkowo prędkość to 20-30st/s więc chyba się zmieści w zakresie pomiarowym.

Marek

400 p/r przy odczycie kwadraturowym i ramieniu 100 mm to rozdzielczość 0,4 mm.
Ty najwyraźniej nie masz bladego pojęcia co chcesz zbudować...

marekms pisze: ↑

15 gru 2025, 12:15

Będę używał sporadycznie i raczej prędkości będą żadne (ramię pomiarowe).

Naprawdę myślisz, że jak będziesz używał sporadycznie, to będzie działało inaczej?
Chodzi o prędkości chwilowe, a te potrafią być duże, nawet kiedy ich nie widać (np, drgania).
RPi będzie miał jitter rzędu 50 µs, co się przełoży na częstotliwość odczytów enkodera poniżej 20 kHz.
Jeśli chcesz coś mierzyć, to zapewne użyjesz enkoderów o największej rozdzielczości w rozsądnych pieniądzach (5000 p/r ?) co da najwyżej jeden obrót na sekundę (i to musi być płynny ruch).
Takie urządzenie czasem zmierzy dobrze, czasem źle, czyli ogólnie będzie do du**.

marekms pisze: ↑

15 gru 2025, 08:34

Projekt ma być nisko budżetowy.Czy na jakimś jednopłytkowym komputerku (raspberry i podobne) da się odczytywać dane z 4 enkoderów i odczytywać pozycję na wyświetlaczu w Linuxcnc?

Budżetowo to będzie na jakimś STM32 (ma sprzętową obsługę enkoderów kwadraturowych).
Jeśli tylko chcesz czytać wynik na wyświetlaczu, to nie ma sensu zaprzęgać do tego LinuxCNC.
Ale jeśli się uprzesz na RPi, to da się skonfigurować na PIO, tyle że będzie działać tak tragicznie, że nie da się tego używać.
RPi plus MESA to już nie będzie budżetowo.