Elm-Chan servo - problem z krokami. Linuxcnc

Ja przez kilka lat walczyłem z zakłóceniami w tych sterownikach. Niby na stole wszystko było ok a potem test w rzeczywistych warunkach i osie szaleją. Po wejściu w materiał prądy rosną i na wejściach step zaczynają się pojawiać śmieci co daje efekt gubienia pozycji. Robiłem ekranowane kable, kondensatory, cewki, rozdzielania zasilania, i nic to kompletnie nie dało. W końcu przeprojektowałem kompletnie płytkę, oddzieliłem część wykonawczą od logiki przez transoptory, i to z grubsza zaczęło działać. Ale to chyba i tak jest tylko doraźne rozwiązanie.

Może u ciebie jest inny problem bo pewnie z 50 innych osób te sterowniki zrobiło i im działa bezbłędnie ale ja ich zmontowałem łącznie z 15 i w każdym było to samo.

tuxcnc pisze:To jest dopasowywanie faktów do teorii..

Kolego na teorii słabo się znam i dlatego faktów do niej nie dopasowuję, a jakie są fakty napisałem wyżej i podobno z nimi się nie dyskutuje.
Tak się ma sprawa przy sterowaniu serw za pomocą sygnału analogowego.
W tym przypadku mamy STEP/DIR – tego nie przerabiałem i dlatego tutaj na żaden temat nie będę się spierał i więcej pisał.
Zdziwiło mnie tylko ostatnio, że wszyscy lub prawie wszyscy używający serw step/dir sygnał z enkoderów mają podpięty tylko do drivera, a z niego do programu sterującego/komputera tylko alarm, który wyłącza maszynę, gdy strajkuje.
Sumując - cały układ jest sterowany, jak krokowiec i jedyna korzyść to alarm ( i zalety samego serwa).
Przy okazji targów w Sosnowcu zapytałem kolegę Marka o skuteczność takiego sterowania i ewentualne niebezpieczeństwa co do utraty pozycji, ale z uwagi na mało komfortowe warunki i może moją ograniczoną zdolność do przyswajania teorii wątpliwości pozostały.
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ę.
Odczyt pozycji bezpośrednio z drivera zawsze jest prawidłowy, dlatego łatwo mogę wyłapać najmniejsze odchyłki pomimo których maszyna pracuje, ale sumując się mogą spowodować, że frezując wieżę Eiffla na koniec pracy trzeba by ją przemianować wieże w Pizie.
W moim przypadku strojenie serwa to podstawowa czynność i nie wystarczy ustawić tylko tak by uszy miały jakiś komfort, ale trzeba to zrobić porządnie za pomocą wbudowanego w LinuxCNC oscyloskopu – wówczas po całym dniu pracy, gdy użyje się G28 maszyna wróci idealnie tam skąd wystartowała.

Pozdrawiam

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.

.

tuxcnc pisze:Nie dość że się ze sobą siłują, to jeszcze jeden drugiemu przeszkadza, cud że to w ogóle działa..

Sam tego nie rozumiem, jak wcześniej wspominałem – może to wpływ tego, gdzie mieszkam i sił wyższych.
Może po dostrojeniu nie siłują się ze sobą, tylko prawidłowo współpracują.
Fakty i praktykę przekazałem – maszyny (3) po całym dniu pracy nie gubią ani jednego impulsu z pozycji, a do dalszych teoretycznych dyskusji nie jestem odpowiednim partnerem.
Dodam tylko, że dokładne strojenie wykryje wszelkie nieprawidłowości sprzętowe (kable, ekrany, uziemienia, jakość drivera, itp.), bo po prostu nie da się dokładnie układu dostroić – może chodzić, ale jak ???

Mój driver (Siemens Masterdrives) jeśli nie wykryje enkodera, nie uruchomi się prawidłowo (warunek konieczny - chyba nie ma innej opcji / kiedyś sprawdzę).

Pozdrawiam

tuxcnc - przychylam się do Twojej wersji, że serwo nie jest źle ustawione (choć na pewno mozna je ustwić lepiej). Poniżej film, na którym widać jak serwo jest podłączone do kompa przez RS232 i terminal zadaje pozycję najpierw o zmianie położenia o jeden obrót (pozycja licznika zmieniana o 400) a potem o 10 obrotów (pozycja zmieniana o 4 000). Widać, że działa to sprawnie. Część PID więc jest ok. Sprawdzałem na dwóch różnych silnikach. Obydwa mają enkodery 100cpr, ale widać nie ma problemu z takimi enkoderami. W programie Servo-controller setup jak włączę tryb 'velocity' to suwakiem mogę przyspiszyć do maksymalnej prędkości wręcz natychmiastowo i nie ma błędu.
Mam pół kabla LPT więc spróbuję luźny koniec podłączyć bezpośrednio do sterownika i... dam znać.


[youtube][/youtube]

W datasheecie od CSMIO jest adnotacja, ze zboczem sterującym sygnalu step jest zbocze opadające. Przy konfiguracji, że zbocze narastające jest sterujące sterownik moze gubic 1 krok przy nawrotach. Nie wiem jak to sie ma do tego przypadku, ale moze warto przetestować

tuxcnc pisze:

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.

Dlaczego specjalny, może to określiłem niejednoznacznie, ale nie miałem na myśli specjalnego programu.

dzięki Dudi1203 za sugestię. Przypomniało mi to pewne ustwienia w linuxcnc: direction setup i direction hold. Być może to łącznie z wartością base period może wpływać na zachowanie się tego sterownika.

Poza tym zrobiłem na szybko 'wzmacniacz' sygnału z enkodera w razie co na 4093:


Następnie wypiąłem optoizolator z płytki, który przyjmuje impulssy step i dir i wpiąłem się przewodami bezpośrednio w podstawkę, czyli bezpośrednio do nóżek uC (tak, wiem, że nie ma teraz izolacji i że niebezpieczne):)


Problem zniknął! Mimo, że zastosowałem 1.5 kabel ze starej myszki (znaznie dłuższy niż pierwotnie, gdy były problemy z gubieniem kroków). Zapuściłem kilka razy standarwody g-kod i silnik zawsze wraca do dokładnie tej samej pozycji.

Czyli zakłócenia - może źle dobrane rezystory w obwodzie diody optocouplera i jestza czuły?

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ć.

.

miałem się założyć, że to skomentujesz:D
ale tak na serio - ktoś będzie miał problem i trafi na wątek i będzie miał trop. Po to jest min. forum. Sam wiele raz właśnie tak znalazłem odpowiedzi. Nie tylko z rejonu cnc, ale i komputerów, oprogramowania, usterek samochodowych. Po prostu ktoś już kiedyś się natknął na dany problem i nie miał oporów przed 'fochami', żeby opisać swój przypadek. Mógłbym to zrobić na blogu, tylko kto by to przeczytał?:)

A tak na prawdę problem został namierzony, ale nie zniknął - przecież tak nie mogę zostawić. Kontunuuję więc temat, bo może się to komuś przydać. Tak jakby się przydało mi, gdyby ktoś wcześniej na to trafił, albo opisał...

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