bogus105 pisze:Napisałeś, że często jest problem z opto. Jakie są więc częste rozwiązania?

Na zbyt niską częstotliwość graniczną to oczywiście nic się nie da poradzić i trzeba poszukać lepszego zamiennika.
Ale problemem może być też CTR, to taki współczynnik "wzmocnienia", jak jest równy 100%, to znaczy w przybliżeniu że taki sam prąd diody wymusi taki sam prąd fototranzystora.
Miałem z tym właśnie problem w "niebieskim chińczyku" na TB6560.
Złożyłem sobie prosty miernik CTR i selekcjonowałem transoptory.
Z posiadanej partii tego samego typu i grupy, połowa się nadawała, a połowa nie.
I nie ma się specjalnie co dziwić, skoro producent dzieli na grupy np. 50-100%, 100-200%, 200-300% itd. ...

.

bogus105 pisze:Problem zniknął!

No to fajnie, ale teraz chyba sam widzisz jak nierealne zadanie nam postawiłeś.
Okazało się że nikt z wypowiadających się w tym temacie na jasnowidza się nie nadaje.
Co prawda transoptory są częstą przyczyną problemów, ale jakoś inne pomysły wygrały.
To się dosyć często zdarza, że ktoś robi aferę na forum, bo złożył i nie działa, a potem albo napisze że przyczyną był kabelek, zimny lut, czy inna duperela, albo obciach mu się przyznać i temat umiera w milczeniu ...
Są takie problemy, których nie da się rozwiązać przez Internet, trzeba usiąść nad płytką i pokombinować.

.

hecza pisze:Ja mam sygnał z enkodera podpięty do drivera, który z niego korzysta, a następnie do komputera.
LinuxCNC ma teoretycznie bezpośredni jego odczyt, ale nie jest tak do końca, bo jeżeli serwo nie jest prawidłowo dostrojone to odczyt jest zakłócany i pozycja „płynie” - dlatego podejrzenie o analogię.

Błąd zasadniczy.
Dwa niezależne regulatory sterujące jeden obiekt korzystają z jednego urządzenia pomiarowego i ich wzajemny wpływ na siebie jest nieprzewidywalny.
Nie dość że się ze sobą siłują, to jeszcze jeden drugiemu przeszkadza, cud że to w ogóle działa.

.

ezbig pisze:

tuxcnc pisze:Takie serwo może wariować, ale gubić pozycji nie ma prawa.

Jak jest przesterowanie, a z programu mamy szybkie ruchy to może przecież nie wyrabiać z pozycją. Będzie to wyglądać jak gubienie kroków.

Jak się zada specjalny program, to będzie wyglądało jakby ....
To jest dopasowywanie faktów do teorii.
Przestańcie wszyscy pisać od rzeczy i nie na temat.

W pierwszym poście tego wątku jest napisane wyraźnie :

bogus105 pisze:Puściłem standardowy program z napisem LinuxCNC i zaczęło frezować... Jednak podczas frezowania kolejnych literek frez coraz mniej wchodził w materiał - po prostu stopniowo się przesuwał do góry w miarę jak pracowała oś Z.

To ewidentnie nie jest rozregulowane serwo, ono pracuje prawidłowo i stabilnie, tylko po każdej podróży w górę i w dół gubi informację o swoim położeniu.
Teoretycznie taka sytuacja nie ma prawa mieć miejsca przy prawidłowym zliczaniu impulsów enkodera.
Wszelkie błędy ustawień i mechaniki za każdym razem powinny być takie same, bo za każdym razem wykonywany jest absolutnie identyczny fragment programu !

.

ezbig pisze:praca niedostrojonego serwa jest bez sensu.

Takie serwo może wariować, ale gubić pozycji nie ma prawa.
Jest enkoder, jest jakiś rejestr pozycji, jeśli nie ma błędu w programie, to mogą się przy złym zestrojeniu dziać cuda, ale zawsze w tym samym miejscu.
Jeśli pozycja sobie płynie, to musi być błąd odczytu enkodera.

.

bogus105 pisze:tuxcnc jakiś drażliwy - może zmień na szerszeń?

Po prostu szlag mnie trafia jak czytam nowy wątek "Złożyłem niedziałający sterownik - co mogłem spieprzyć ?"
Zanim zadasz komuś pytanie, to się zastanów czy on ma w ogóle prawo znać odpowiedź ...

Jeśli już mam się zabawić w jasnowidza, to stawiam na użycie uproszczonego algorytmu odczytu enkodera.
Takie uproszczone algorytmy są proste, ale gubią się na nawrotach.

.

Program tylko wysyła sygnały STEP i DIR i nie ma absolutnie nic do tego co się dzieje z osią.
Po prostu to nie program mierzy położenie, tylko sterownik.
Sam nie pamiętasz/nie możesz niczego sprawdzić, to po cholerę ludziom dupę zawracasz ?
Liczysz że ktoś jest jasnowidzem ?

.