W takim razie musisz mieć dwa liczniki. Jeden do enkodera, drugi do zliczania impulsów z macha i liczyć ich różnicę.

Najpierw zliczasz pozycję encodera dekoderem kwadraturowym z licznikiem, potem tą wartość odejmujesz od aktualnej wartości zadanej z interoplatora -wychodzi błąd pozycji. Dalej przepuszczasz to przez P (tak, samo P, nie PID, ponieważ sterujemy pochodną pozycji czyli prędkością) a na końcu przetwornik C/A +/-10V.

W takiej konfiguracji bardzo ważne jest, aby we wszystkich osiach wzmocnienie P miało taką samą wartość.

Tak właśnie działały prawie wszystkie systemy sterowania od lat 50 do końca wieku

Co do możliwości sprzętowych mikrokontrolerów z dekoderem kwadraturowym (sprzętowym) to jest oczywiście najlepsze rozwiązanie. Próba programowego symulowania dekodera kwadraturowego będzie sie sprawdzała tylko przy bardzo niskich częstotliwościach. Poza tym potrzebne jest znacznie więcej instrukcji do wykonania. Najpierw odłożenie rejestrów na stos, skok do procedury przerwania, pobranie stanu portu, decyzja o dekrementacji lub inkrementacji, odczyt zmiennej pozycji, inkrementacja, lub dekrementacja, zapis do zmiennej pozycji, odtworzenie rejestrów, powrót z procedury przerwania. To do najmniej 10 instrukcji, a biorąc pod uwagę kilka cykli na niektóre instrukcje, to co najmniej 30 cykli. Stara 51' pozwoli na obsługę enkodera do częstotliwości ok 50kHz co jest żałośnie niską wartością. Nawet wielokrotnie szybsze procki się spocą przy 300kHz. A gdzie pozostałe obliczenia? Enkoder 2500 ppr generuje 10000 zboczy na obrót, co przy 3000rpm daje 0.5Mhz.

Ale polemika dotyczyła sposobu wyznaczania prędkości a nie pozycji. A takich sprzętowych zasobów standardowo precyzyjnie wyznaczających prędkość z enkodera żaden kontroler nie ma. A co do moich rad to na razie musi wam wystarczyć wskazywanie, która droga jest zła.

Ma kolega jakiś prosty patent na wyznaczanie takiej prędkości w sposób liniowy i ciągły, z rozdzielczością i dokładnością umożliwiającą zastosowanie go w pętli sprzężenia zwrotnego regulatora prędkości serwonapędu? Są metody sprzętowe, ale bardzo skomplikowane. Tak skomplikowane, że wymagają implementacji na fpga z co najmniej 50-cio megahercowym motorkiem. Wszyscy producenci "poważnych" serwonapędów stosują taką metodę.

A ja Ci merytorytorycznie odpowiedziałem, że to nie zadziała. Uznając, że jakieś pojęcie w temacie masz, pozwoliłem sobie na skrót myślowy. Ale się rozpiszę. Prędkość z enkodera można mierzyć badając przebytą drogę (pozycją z enkodera) w czasie -sprawdza się tylko przy dużych prędkościach i mierząc czas pomiędzy zboczami z enkodera (sprawdza się tylko przy małych prędkościach). W pierwszym przypadku mamy informacje o kierunku ruchu, w drugim nie. W drugiej metodzie potrzebne jest dzielenie (kolejny problem). Można połączyć obie metody, ale na bazie samego procka jest to niemożliwe. Potrzebna jest skomplikowana struktura logiczna i niestety też dzielenie, a i tak efekt nie jest w pełni zadowalający.

Co do UHU to jest to projekt pouczający, aczkolwiek zawiera rozwiązania z założenia przaznaczone tylko dla amatorów.

"Obawiam się, że Kolega nie wie jak działa enkoder kwadraturowy" -przestań się popisywać!
I nie pouczaj kolegi korinsj bo wszystko wskazuje na to, że się wiele od niego możesz nauczyć.

A co ma piernik do wiatraka? W częstościomierzu "szybko" to dla serwa oznacza bardzo wolno.

A co do niemożliwości i wyobraźni, to psychologiczne zabawy w pojmowanie rzeczywistości proszę przenieść na inne forum. Jeśli kol Leoo chce polemizować to proszę, może się od kol coś nauczę. Ale proszę merytorycznie, bez dziecinnych popisów.


Ale wytłumaczę: Nie można interpolować (w znaczeniu to nie zadziała w tej aplikacji), nie znaczy że nie jest to niemożliwe (interpolowanie).

"To właśnie aktualne zbocze wyznacza kierunek rotacji"
Super, ale mierząc tylko czas pomiędzy zboczami nie mamy informacji o kierunku.

Następny fragment dotyczył wyznaczania prędkości na podstawie modelu matematycznego silnika i płynącego prądu.


"Jeśli układ będzie źle zestrojony, to się wzbudzi. Fakt ten łatwo sprawdzić porównując impulsy STEP ze stanem enkodera. Algorytm powinien w takim wypadku skorygować odpowiedni parametr, który prawdopodobnie spowolni reakcje. Oczywiście wolniejsza praca serwa spowoduje wzrost błędu pozycji i prawdopodobne zgłoszenie alarmu."

Co ma zadecydować, czy to już wzbudzenie, czy jeszcze tłumienie mechanicznych drgań bramy, czy oscylacje od wchodzących w materiał kolejnych ostrzy? Serwo powinno być zestrojone z pewnym zapasem stabilności.

"Jeśli Kolega ma na myśli oscylacje między wartością 0 a 1 enkodera, to ja "biorę w ciemno" takie serwo."

W pewnych sytuacjach sarwo na postoju drga 01010101... co sygnalizuje buczeniem. Właśnie dlatego stosuje się zmniejszenie nastaw w stanie zatrzymania. A dobre serwo poprawnie sterowane, na postoju ma błąd 0, a w stanach dynamicznych (nawet przy obciążeniu nominalnym) błąd nie powinien przekraczać kilku impulsów. Serwa są różne, do maszyn cnc i do taśmociągów. Problem jest taki, że niektórzy te drugie próbują zastosować do napędu maszyn cnc.

Nie można niczego interpolować, ani nie można tak sobie przełączać pomiędzy różnymi metodami pomiaru prędkości w zależności od zakresu prędkości. Wszystko musi być liniowe. Podczas zmiany kierunku ruchu musimy przy najbliższym zboczu z enkodera to już wykryć, a nie zastanawiać się przez ileś milisekund w którą się stronę porusza. Przecież mogło wystąpić nagłe obciążenie i wszystkie obliczenia poszły w las. A co jak się regulator wzbudzi i będzie oscylował wokół wartości 0?

A na dodatek wszystko sie pochrzani jak się zmieni kierunek obrotów.

Aby sygnał wyjściowy z regulatora nie latał od -max do +max, rozdzielczość sygnałów mierzonych (np prędkości) musi być znacznie większa. Inaczej różniczka głupieje i daje takie sygnały, co z kolei generuje potężne zakłócenia EMC ponieważ powstają silne udary prądowe. Wszystko szumi, trzeszczy i się zakłóca na wzajem. Współczesne serva AC nie używają już tacho tylko estymują prędkość z enkodera, ale robią to sprzętowo. Żaden procesor czy kontroler nie ma zasobów pozwalających na estymowanie sygnału prędkości o zadowalającej dynamice i liniowości. Robi się to za pomocą obserwatora wspomaganego sprzętowo na niemałych fpga. Niestety nie ma gotowych kostek które to robią.

Właśnie dyskretyzacja sygnałów jest największym problemem przy próbach wykorzystania regulatorów cyfrowych korzystających z aperiodycznych sygnałów dyskretnych jakie daje enkoder inkrementalny. Cały układ będzie się wzbudzał z powodu nieliniowości i niskiej rozdzielczości pomiarów. Jak jest odczyt 0 to nie znaczy, że silnik stoi, tylko, że pomiędzy poszczególnymi odczytami nie wystąpiło zbocze sygnału z enkodera. A jak jest 1 to może jest 1.9 a pokazuje 1.

"Kiedy PWM osiąga 100% wypełnienia silnik otrzymuje nominalny moment obrotowy"

Od kiedy to moment silnika jest uzależniony od napięcia? Myślałem, że od prądu. A kiedy pwm osiągnie 100% to znaczy tyle, że do silnika jest doprowadzone napięcie zasilające sterownik, a że napięcie na silniku jest uzależnione od jego prędkości obrotowej i spadku napięcia na rezystancji uzwojeń, to biorąc pod uwagę bardzo niewielką rezystancję, jeśli na zatrzymanym silniku pojawi się pełne napięcie od razu to będziemy mieli zwarcie. Ograniczone tylko rezystancją uzwojeń.

Co do regulatora P_PI to będzie lepiej, ale jak chcecie wyznaczać prędkość aktualną? Macie prądniczkę tacho? Bo programowo z enkodera to nic z tego nie wyjdzie, a sprzętowy estymator jest bardzo skomplikowany.