Sterownik serwa DC - szczegóły działania PIDa

[kwarc]

ech kiedys waluta byly zlote monety teraz papier albo nawet wirtualne konto.jest takie prawo ,jakis madry czlowoek to wymyslil ze towar gorszy wypiera towar leprzy.

[korinsj]

> ...aktualna predkosc (obroty) pobierana z tachometru lub czujnikow przyspieszenia...

To oczywiście u mnie odpada. Mam silniki tylko z enkoderami.

>...enkoder potrzebuje czasu na analize i jest zawsze spuzniony...

Tu nie problemem jest czas reakcji enkodera, ale jego rozdzielczość. Przy małej ilości imp/obrót różnica pomiędzy kolejnymi odczytami enkodera jest mocno skokowa. I jest tym gorzej im większa jest częstotliwość pracy PID a obroty silnika wolniejsze.

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

Dokładnie tak.

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

Właśnie testuję P-PI, całkowanie narazie wyłączone, czyli mam P-P - działa super, ale fakt - silnik wydaje odgłosy jakby był zarzynany - drugie P (a więc różniczka) daje mu popalić. Na symulacji doszedłem nawet do regulacji 3-stanowej: -Uwymax, 0 +Uwymax i też działa

>...Współczesne serva AC nie używają już tacho tylko estymują prędkość z enkodera...

Też o tym myślałem. Silnik sterowany napięciowo to całkowanie z inercją, czyli k/s(1+sT). Więc kombinowałem aby zrobić jego symulację w procku tak jak robię pod windowsem. Obliczenie odpowiedzi przyrostowej dla położenia enkodera silnika wygląda tak:

ObjSum := ObjSum + ObjWe * (ObjK * Tp);
ObjWy := ObjWy + (ObjSum - ObjWyl) * (Tp / ObjT);

ObjK*Tp i Tp/ObjT to stałe, więc nie mam nigdzie dzielenia - jest do zrobienia w procku.

Czyli znam prędkość aktualną, wyjście PWM i mogę obliczyć prędkość jaka powinna być w następnym cyklu PIDa. Nie wiem czy akurat będzie to właściwe podejście do sprawy.

Mogę też symulować odpowiedź prędkościową (jeszcze prościej) bo to inercja k/(1+sT).

Narazie zrobię jeszcze parę kombinacji:
- ograniczenie i uruchomienie całkowania w P-PI,
- strukturę PI-P
- przeróbkę regulatora z pozycyjnego na prędkościowy
- zwiększenie rozdzielczości pomiaru prędkości obrotowej - nie jako różnica kolejnych odczytów enkodera, ale pomiar długości trwania impulsu poprzez sprzętowy timer procka.

Zegar będzie bramkowany przez jeden z kanałów enkodera i zliczany w liczniku. Licznik 16bit, "f" zegara do wyboru: 20MHz, 5MHz, 1250kHz, 312.5kHz.

Mogę w ten sposób zwiększyć dokładność (rozdzielczość) pomiaru prędkości obrotowej silnika, ale dopiero od szybkości przy której wystąpią oba zbocza na kanale enkodera w czasie jednego cyklu PID - nie mogę mierzyć długości impulsu który trwa dłużej niż kolejne obliczenie PIDa.

PIDa obliczam co 2kHz (okres 500us) dopiero od takiej częstotliwości impulsów z enkodera mogę mierzyć dokładnie ich czas trwania.

Zrobiłem trochę pomiarów:

Silnik 24V 140W
Enkoder 500 imp/obr
f PID 2kHz (500us)
f CLK 5MHz (0.2us)

PWM - wartość wyjścia PWM od 0(0%) do 2000(100%)
T - czas trwania poziomu wysokiego na kanale enkodera
K - prędkość wyliczona jako różnica kolejnych odczytów enkodera ("tradycyjnie")
N - prędkość zmierzona przez szybki licznik sprzętowy (sprzętowo)

1. PWM=0 T=oo K=0 N=65535
2. PWM=100 T=oo K=0 N=65535
3. PWM=200 T=oo K=0 N=65535
4. PWM=300 T=2ms K=0 N=10000
5. PWM=350 T=376us K=3 N=1880
6. PWM=400 T=216us K=5 N=1080
7. PWM=450 T=140us K=7 N=700
8. PWM=500 T=120us K=8 N=600
9. PWM=550 T=98us K=10 N=490
10. PWM=600 T=90us K=11 N=450
11. PWM=700 T=76us K=13 N=380
12. PWM=800 T=72us K=14 N=360
13. PWM=900 T=67us K=15 N=335
14. PWM=1000 T=64us K=16 N=320
15. PWM=1100 T=62us K=16 N=310
16. PWM=1200 T=61us K=16 N=305
17. PWM=1300 T=60us K=17 N=300
18. PWM=1400 T=59us K=17 N=295
19. PWM=1500 T=58us K=17 N=290
20. PWM=1600 T=57us K=18 N=285
21. PWM=1700 T=57us K=18 N=285
22. PWM=1800 T=56us K=18 N=280
23. PWM=1900 T=55us K=18 N=275
24. PWM=2000 T=54us K=19 N=270

Dokładność i dynamika sprzętowego pomiaru prędkości wydaje się być obiecująca.

[cnc3d]

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

[korinsj]

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

Dokładnie. Przy zmianie kierunku mogę mieć dwa przypadki:

1. Jeżeli początek pomiaru robię na zboczu narastającym na kanale A a koniec pomiaru na zboczu opadającym kanału A to mogę mieć fałszywą dużą prędkość.
2. Jeżeli początek pomiaru robię przy dowolnym zboczu na kanale A a koniec przy dowolnym zboczu na kanale B to mogę mieć fałszywą mała prędkość.

Ale wydaje mi się że to kwestia obróbki programowej. W końcu znak szybkości (kierunek obrotów) i tak będę ustalał na podstawie różnicy położeń enkodera, więc mogę to jakoś ze sobą powiązać.

[ Dodano: 2008-12-05, 18:43 ]
W sumie to zmiana kierunku nie jest problemem. Sprawdziłem PDF do procka jakiego używam (ARM Atmela) i jeśli wystarczy mi wolnych komórek w CPLD to mogę tak mu wygenerować sygnały że "sam" odpowiedni pomierzy czas trwania impulsów niezależnie od zmiany kierunku.

[ Dodano: 2008-12-05, 19:36 ]
No to już wiem. Musiałbym jedną funkcję wyrzucić z CPLD i wrzucić ją do procka (tylko dwie instrukcje więcej w programie). Wtedy zyskam brakujące komórki w CPLD aby mierzyć precyzyjnie czas trwania impulsów. Ale wiąże się tą z przeróbką całej PCB i montaż nowego prototypu.

Narazie uruchomię całkowanie i zobaczę jak będzie silnik pracować z pełnym P-PI i programowym liczeniem szybkości.

[Leoo]

Dokładnie. Przy zmianie kierunku mogę mieć dwa przypadki:

Nie można zmienić kierunku obrotów w czasie 0.
Zanim to nastąpi, najpierw silnik będzie zwalniał i będzie to widać podczas odczytu enkodera. O tym, że silnik osiągnął prędkość 0 poinformuje sam enkoder, po czym nastąpi przyśpieszanie w przeciwnym kierunku. Jeśli po zatrzymaniu i rozpoczęciu ruchu "obrotomierz" wykaże dużą wartość, będzie to ewidentny błąd, który łatwo zdefiniować i wyłapać programowo.
O ile mnie pamięć nie zawodzi, sterownik kolegi Piotrjub rozpędzał silnik w ciągu 60ms, tak więc zmiana kierunku nie mogła odobyć się krócej niż w 120ms a dla procesora to lata świetlne. Wokół prędkości 0 można zbudować rozszerzone mechanizmy pomiaru czasu interwałów z enkodera, czy wręcz zmienić okres PID. Podczas przyspieszania można interpolować wyniki pomiarów i wyliczyć prędkości mniejsze od umownej 1.

[cnc3d]

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?

[Leoo]

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.

Niemożliwe są tylko takie rzeczy, których nie możemy sobie wyobrazić.
Dla przykładu - częstościomierz na bazie procesora wykonuje bardzo szybki pomiar małych częstotliwości i podobnie szybko mierzy duże.

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.

To właśnie aktualne zbocze wyznacza kierunek rotacji.

Przecież mogło wystąpić nagłe obciążenie i wszystkie obliczenia poszły w las.

Obliczenia nie pójdą w las w czasie 0, w układzie z inercją nic nie dzieje się nagle. Nastąpi zmiana prędkości (kierunku), która będzie symptomem zjawisk "nieprzewidzianych" w pętli sterowania.

A co jak się regulator wzbudzi i będzie oscylował wokół wartości 0?

Jeśli układ będzie źle zestrojony, to się wzbudzi. Fakt ten łatwo sprawidzić 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.
Jeśli Kolega ma na myśli oscylacje między wartością 0 a 1 enkodera, to ja "biorę w ciemno" takie serwo.

[cnc3d]

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.

[Leoo]

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.

Merytorycznie zaproponowałem zmianę techniki pomiaru małych prędkości obrotowych porównując ją do istniejących rozwiązań częstościomierzy/czasomierzy na bazie uCPU. Może faktycznie to dziecinada.

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

Obawiam się, że Kolega nie wie jak działa enkoder kwadraturowy. Jeśli nie będzie dziecinadą, to proszę zerknąć na schemat UHU gdzie obydwa wyjścia enkodera wchodzą na dwa odrębne timery. Analizowane są i zbocza sygnałów i czas ich trwania.

Może teraz koleżanka kwarc napisze coś znacznie bardziej pouczającego.

[cnc3d]

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