WYKORZYSTANIE INTERFEJSU ETHERNETOWEGO DO STEROWANIA SILNIKIEM ASYNCHRONICZNYM W CZASIE

mgr inż. Daniel Lewandowski mgr inż. Grzegorz Lisowski Instytut Automatyki PŁ

ul. Stefanowskiego 18/22, 90-924 Łódź

daniel.lewandowski@p.lodz.pl, grzeslis@p.lodz.pl

WYKORZYSTANIE INTERFEJSU ETHERNETOWEGO DO STEROWANIA SILNIKIEM ASYNCHRONICZNYM W CZASIE

RZECZYWISTYM

Streszczenie: Artykuł przedstawia stworzone w In- stytucie Automatyki Politechniki Łódzkiej stano- wisko do badań nad algorytmami sterowania silni- kiem asynchronicznym z wykorzystaniem interfej- su ethernetowego. Prace były prowadzone w ra- mach grantu nr 1265/T10/2005/28 “Sterowanie wybranymi układami elektromechanicznymi przy wykorzystaniu sieci komputerowych”.

1. WPROWADZENIE

W dzisiejszych czasach coraz większe znaczenie ma zdalne sterowanie procesami przemysłowymi. W sieciach przemysłowych istnieje wiele rozwiązań pro- tokołów przesyłu danych opartych na sprzętowych li- niach RS-485 lub CAN takich jak:

• Modbus

• Profibus

• CANopen

• DeviceNet

Mają one swoje zalety jak np. łatwość imple- mentacji w istniejących sterownikach (Modbus) lub pewność przesyłania danych (CANopen, DeviceNet).

Żadne z tych rozwiązań nie jest w stanie przesyłać dane z prędkością większą niż 500 kbit/s. Dlatego co- raz częściej producenci sterowników przemysłowych zwracają się w kierunku protokołów opartych na sie- ciach ethernetowych. W związku z tym powstała myśl zbudowania stanowiska badawczego realizującego ste- rowanie silnikiem asynchronicznym w czasie rzeczy- wistym z wykorzystaniem protokołu TCP/IP. Zada- niem tego stanowiska jest nie tylko nadrzędne ste- rowanie, ale również rejestrowanie (wizualizacja) roz- maitych sygnałów związanych z tym procesem, takich jak:

• prąd i napięcie obwodu pośredniczącego

• prądy i napięcia fazowe silnika

• stany regulatorów procesu sterowania

• realizowany moment napędowy

Koncepcja wykorzystania interfejsu etherneto- wego została zrealizowana przy okazji budowania sta- nowiska laboratoryjnego służącego do badania stanów przejściowych w sterowniku silnika asynchronicznego przeznaczonego do napędów trakcyjnych.

2. OPIS STANOWISKA

Elementem wykonawczym jest sterownik napę- du, w którym wykorzystano procesor DSP firmy Te- xas Instruments TMS320F240 wraz z falownikiem na- pięciowym (3 kW) oraz silnikiem (0.55 kW) wyposa- żonym w przetwornik impulsowy do pomiaru pręd- kości obrotowej wału. Ponieważ wyżej wymieniony procesor jest przeznaczony przede wszystkim do re- alizacji funkcji napędowych, trudno za jego pomo- cą jednocześnie sterować napędem oraz obsługiwać interfejs ethernetowy. Dlatego drugie zadanie zosta- ło zrealizowane przez osobny moduł mikroprocesoro- wym MMnet01. Do transmisji danych między proce- sorem DSP, a modułem ethernetowym postanowiono wykorzystać interfejs szeregowy SPI.

Rysunek 1: Schemat blokowy stanowiska laboratoryj- nego

Sterowanie nadrzędne jest realizowane za pomo- cą komputera PC przy pomocy programu “Satyna”

2006

Poznańskie Warsztaty Telekomunikacyjne

Poznań 7 - 8 grudnia 2006

napisanego przez autorów, który umożliwia sterowa- nie momentem oraz archiwizację danych przesyłanych w czasie rzeczywistym ze sterownika. Schemat bloko- wy stanowiska przedstawiono na rysunku nr (1).

3. STEROWNIK NAPĘDU

Sterowanie trójfazowego silnika indukcyjnego oparte jest na algorytmie wektorowym o tak zwa- nej orientacji wektora prądu stojana - rysunek (2) (wszystkie zmienne silnika - napięcie i strumień ma- gnetyczny wirnika odniesione są do układu współ- rzędnych wirującego synchronicznie z wektorem prą- du). Sygnałami wyjściowymi układu sterowania są chwilowe wartości napięć U

, U

, U

realizowane przez falownik napięciowy w postaci fal PWM. Algo- rytm wektorowy realizowany jest na podstawie war- tości zadanej momentu mieszczącej się w przedziale (–0.99, 0.99) momentu znamionowego.

Rysunek 2: Reprezentacja wektorowa zmiennych prą- du i strumienia w układzie wirującym

Program wykorzystuje ideę stymulatora stanu opisanego w szerzej w [1], [2] opartego na równaniach opisujących silnik indukcyjny w układzie biegunowym (wzory (1) i (2)). Na wyjściu stymulatora otrzymuje- my zmienne w postaci pulsacji poślizgu oraz modułu wektora prądu wykorzystywane do realizacji zadane- go momentu.

T

d

dt Ψ

= −Ψ

+ L

I

cos ϕ

(1) d

dt ϕ

= − 1 T

L

I

1

Ψ

sin ϕ

+ Ω

(2) Realizacja fali PWM o częstotliwości 2.5 kHz de- terminuje wykonywanie algorytmu sterowania wekto- rowego dokładnie co 400 µs. Działanie algorytmu zo- staje zapoczątkowane dokładnie w chwili gdy realizo- wany jest zerowy wektor napięcia. Jest to związane z minimalizacją zakłóceń w analogowym torze pomia- rowym prądu.

Algorytm wygląda następująco:

1. Pomiar wielkości analogowych.

2. Pomiar prędkości obrotowej oraz wyznaczenie kąta położenia wału.

3. Przekształcenie zmierzonych wielkości fazowych prądu na ich reprezentację wektorową.

4. Wyznaczenie, na podstawie sygnału zadanego (moment), nowego stanu elektromagnetycznego silnika (moduł wektora prądu oraz jego położe- nie).

5. Przekształcenie pomierzonego wektora prądu z układu stacjonarnego do układu wirującego syn- chronicznie z zadanym wektorem prądu.

6. Wyznaczenie wektora napięcia na podstawie re- gulatora kompensującego błąd wektora pomie- rzonego prądu i wektora wyznaczonego w punk- cie 4.

7. Przekształcenie wektora napięcia do układu sta- cjonarnego.

8. Przekształcenie wektora napięcia na wartości chwilowe PWM w poszczególnych fazach (reali- zacja tzw. SVPWM ).

9. Realizacja algorytmu stanów magnetycznych sil- nika takich jak: wyłączenie, praca, wzbudzenie, odwzbudzenie, opisanych w [3].

10. Przygotowanie do komunikacji z modułem ether- netowym.

Na wykonanie wszystkich kroków algorytmu proce- sor DSP potrzebuje ok. 100 µs. Pozostały czas mo- że zostać przeznaczony na komunikację szeregową z modułem ethernetowym. Ze względu na wspomniane reżimy czasowe sterownik napędu narzuca przedział czasowy, w trakcie którego można wykonać transmisję danych. Zezwolenie na transmisję jest sygnalizowane opadającym zboczem sygnału przerwania zewnętrz- nego.

4. MODUŁ ETHERNETOWY

Do stworzenia modułu ethernetowego, pośredni- czącego między aplikacją sterującą uruchomioną na komputerze PC a falownikiem, wykorzystano układ MMnet01. Moduł ten jest odmianą Ethernut’a [4]

- projektu otwartego oprogramowania mającego na celu stworzenie referencyjnej platformy sprzętowej i programowej dla systemów wbudowanych. Wraz z projektem fizycznego układu dostępny jest również system operacyjny Nut/OS. System jest dostarczany w postaci biblioteki i plików nagłówkowych, które są wykorzystywane w kodzie źródłowym programu użyt- kownika. W wyniku kompilacji otrzymuje się gotowy plik, który można wgrać do pamięci flash mikrokon- trolera. Programowanie mikroprocesora może się rów- nież odbywać z wykorzystaniem interfejsu etherneto- wego.

System Nut/OS zawiera implementację stosu

TCP/IP pozwalającą na komunikację za pośrednic-

twem protokołu TCP, UDP lub z wykorzystaniem

dowolnych ramek ethernetowych. Ostatnia możli- wość nie jest jednak zalecana, ze względu na trud- ne do przewidzenia zachowanie innych elementów sie- ci ethernetowej (inteligentnych przełączników i rute- rów). Użycie z kolei protokołu TCP lub UDP pozwala na łatwą integrację z aplikacjami użytkownika uru- chamianymi na zwykłym komputerze.

Sercem modułu MMnet01 jest 8-bitowy mikro- kontroler ATmega128 firmy Atmel. Za komunikację ethernetową odpowiada układ RTL8019AS, który zo- stał przyłączony do mikroprocesora poprzez szynę adresową i szynę danych. Ponieważ aplikacje korzy- stające ze stosu TCP/IP wymagają znacznie więcej pamięci RAM niż posiada mikrokontroler, w module umieszczono dodatkowe 64 kB zewnętrznej pamięci RAM.

Pewnym utrudnieniem jest umieszczenie reje- strów układu ethernetowego w innym obszarze pa- mięci, niż ma to miejsce w referencyjnej platformie.

Wymaga to modyfikacji plików konfiguracyjnych sys- temu Nut/OS. Poza tym moduł posiada funkcjonal- ność porównywalną z oryginalnym Ethernut’em.

Dla modułu MMnet01 stworzono z wykorzysta- niem systemu Nut/OS program o nazwie “Orzeszek”, który został podzielony na dwa główne procesy:

• Odbiornik - odpowiada za odbieranie pakietów z komputera sterującego, którego adres IP jest jed- nym z zarejestrowanych w programie adresów.

Aby zapobiec sytuacji przypadkowego urucho- mienia jednocześnie dwóch lub więcej kopii pro- gramu sterującego “Satyna” zastosowano progra- mową blokadę. Polega ona na analizowaniu pa- kietów UDP o jednym z możliwych adresów źró- dłowych IP. Każdy poprawnie odebrany pakiet blokuje komunikację z urządzeniami o innych ad- resach na 60 sekund.

• Nadajnik - odpowiada za przygotowanie pakie- tów UDP do wysłania. Pakiet z danymi zawie- ra znaczniki i potwierdzenia znaczników czasu, które pozwalają na wyznaczenie wskaźnika RTT.

Większą cześć pakietu stanowią ramki z aktu- alnymi wartościami wybranych sygnałów otrzy- manych z falownika za pośrednictwem interfejsu SPI. Pakiety posiadają zmienną wielkość zależ- ną od ilości ramek z danymi otrzymanymi z ste- rownika napędu od czasu wysłania poprzedniego pakietu UDP.

Komunikacja z programem operatora odbywa się z wykorzystaniem protokołu UDP o porcie źró- dłowym i docelowym równym 17671. Wykorzystanie standardowego protokołu pozwoliło np. na zamknię- cie pętli sterującej poprzez uczelnianą sieć kompute- rową.

Komunikacja z procesorem DSP umieszczona zo- stała w procedurze obsługi zewnętrznego przerwa- nia, które jest zgłaszane przez sterownik i traktowane przez mikrokontroler ATmega128 jako zezwolenie na rozpoczęcie transmisji (rysunek (3)).

Rysunek 3: Komunikacja między mikroprocesorem ATmega128 i TMS320F240 z wykorzystaniem inter- fejsu SPI. Od góry: dane wysyłane z ATmega128, da- ne wysyłane z TMS320F240, sygnał zegara SPI, sy- gnał zezwolenia na transmisję.

Wymiana danych odbywa się z wykorzystaniem interfejsu SPI pracującego z zegarem 2 MHz. Z powo- du braku buforów sprzętowych konieczne jest stoso- wanie programowych opóźnień o czasie trwania 1µs pomiędzy kolejnymi bajtami. Zwiększa to czas trans- misji o 25% i powoduje pewną stratę mocy oblicze- niowej mikrokontrolera. Dodatkowo, ze względu na zachowanie ciągłości transmisji, nie jest możliwe wy- korzystanie do tego celu przerwań związanych z in- terfejsem SPI. W efekcie powoduje to, że komunika- cja ze sterownikiem napędu zajmuje 30% czasu pracy mikrokontrolera. Pomimo takiego reżimu prosty pro- cesor 8-bitowy wykonuje wyznaczone mu zadanie w sposób bardzo dobry, biorąc pod uwagę jego niewiel- ką moc obliczeniową.

W przypadku utraty komunikacji z wykorzysta- niem interfejsu ethernetowego “Orzeszek” wysyła do sterownika napędu polecenie wyłączenia falownika.

Awaryjne wyłączenie ma miejsce po upływie ok. 3 sek. od otrzymania ostatniego pakietu UDP.

Dodatkową funkcją “Orzeszka” jest sterowanie momentem obciążenia, który jest wytwarzany przez prądnicę obcowzbudną prądu stałego. Wartość prądu płynącego w tworniku jest proporcjonalna do momen- tu wytwarzanego na wale maszyny. Sygnałem zada- jącym wartość prądu jest stopień wypełnienia sygna- łu PWM generowanego przez licznik mikroprocesora ATmega128. Poprzez kształtowanie chwilowej warto- ści prądu w tworniku możliwe jest realizowanie obcią- żenia o różnorodnych charakterystykach.

5. PROGRAM STERUJĄCY

Nadzór i sterowanie pracą napędu odbywa się poprzez panel sterujący uruchomiony na komputerze operatora. W tym celu stworzono program “Satyna”

pozwalający na sterowanie i archiwizację danych z

sterownika w czasie rzeczywistym. Aplikacja zosta-

ła napisana w języku Ada 2005 z użyciem biblioteki

GtkAda [5]. Biblioteka ta pozwala wykorzystać stwo-

rzony w języku C pakiet narzędziowy Gtk [6], który umożliwia wygodne budowanie graficznego interfejsu użytkownika. Użycie powyższych narzędzi pozwoliło na stworzenie programu, który można uruchomić za- równo na platformie Windows jak i Linux.

Język Ada 2005 jest przeznaczony do tworze- nia aplikacji czasu rzeczywistego i aplikacji dla syste- mów dedykowanych [7]. Zawiera konstrukcje języko- we wspomagające tworzenie wielowątkowych progra- mów, np. typ zadaniowy będący samodzielnym proce- sem, system synchronizacji w postaci asymetrycznych spotkań oraz chronione obiekty i procedury pozwala- jące na bezpieczną wymianę danych [8].

Program “Satyna” został podzielony na współ- pracujące ze sobą procesy (ang. threads):

• Odbiornik - odpowiada za odbierania pakietów UDP z “Orzeszka” i zapisywanie danych do pliku dziennika, gdzie są archiwizowane otrzymywane dane.

• Nadajnik - odpowiada za wysyłanie pakietów sterujących UDP do “Orzeszka”.

• Skryba - odpowiada za wykonywanie skryptu użytkownika, który pozwala na programowe for- mowanie zadawanego momentu napędowego.

• Program główny - odpowiada za obsługę gra- ficznego interfejsu użytkownika oraz uruchamia- nie i zatrzymywanie powyższych procesów. Inter- fejs użytkownika pozwala na zmianę zadawanego momentu napędowego oraz momentu oporowe- go. Wyświetlane są również paski wizualizujące chwilowe wartości wybranych sygnałów sterują- cych oraz sygnałów realizowanych przez sterow- nik napędu.

Do komunikacji z równolegle wykonywanymi procesami wykorzystano wbudowany w język Ada 2005 mechanizm obiektów i procedur chronionych.

Wydzielenie niezależnych procesów pozwoliło na uproszczenie struktury programu.

Wygląd okna programu w trakcie poprawnie na- wiązanej łączności przestawiono na rysunku (4). In- terfejs użytkownika został podzielony na 4 bloki ste- rujące i 2 bloki informacyjne.

Blok przycisków sterujących pozwala na nawią- zanie komunikacji z “Orzeszkiem”, włączenie i wy- łączenie falownika, oraz zamknięcie programu “Saty- na”.

Blok ustawień pozwala na wprowadzenie adresu IP lub nazwy internetowej “Orzeszka”, wprowadzenie nazwy pliku dziennika oraz nazwy pliku zawierające- go skrypt. Dostępne są również opcje uaktywniające zapisywanie pliku dziennika oraz rozpoczynające wy- konywanie skryptu. Język skryptu składa się z kilku prostych poleceń, które umożliwiają modyfikację za- dawanego momentu wzorem liczników stosowanych w mikrokontrolerach. W skład poleceń wchodzą instruk- cje:

• loop - rozpoczyna pętlę, która jest wykonywana przez 60 sekund

Rysunek 4: Panel sterujący

• loop timeout wartość - rozpoczyna pętlę, któ- ra jest wykonywana przez podany w sekundach przedział czasu

• end - kończy odpowiadający mu pętlę

• exit torque wartość - kończy najbliższą pętlę, gdy wartość realizowanego momentu różni się od po- danej wartości o co najwyżej 0.01

• exit speed wartość - działa podobnie jak w przy- padku instrukcji powyżej, z tą różnicą, że spraw- dzana jest wartość prędkości

• set torque wartość - przypisuje zadawanemu mo- mentowi napędowemu wskazaną wartość

• increment torque wartość - zwiększa zadawany moment o podaną wartość

• decrement torque wartość - zmniejsza zadawany moment o podaną wartość

• delay wartość - wstrzymuje wykonanie skryptu o podany interwał czasu

Należy zwrócić uwagę na fakt, że moment mieści

się w przedziale (−0.99, 0.99) i w przypadku wyjścia

poza ten przedział wartość momentu jest ogranicza-

na do najbliższej dopuszczalnej wartości. Natomiast

prędkość zawsze pochodzi z przedziału (−2.0, 2.0)

prędkości znamionowej i oczywiście nie może być

zmieniana bezpośrednio z poziomu skryptu. Ze wzglę-

du na zachowanie prostoty interpretera zrezygnowa-

no na obecnym etapie badań z możliwości tworzenia

własnych zmiennych i wykonywania na nich opera-

cji arytmetyczno - logicznych. Nie stworzono również

możliwości tworzenia rozgałęzień w kodzie skryptu.

Rysunek 5: Panel sterujący - błąd komunikacji

Pomimo skromnej listy instrukcji skrypt użyt- kownika może służyć do tworzenia złożonych przebie- gów sygnałów sterujących np. generator fali trapezo- wej o różnym współczynniku narastania i opadania.

Skrypt realizujący opisany przebieg przedstawiono na listingu (1).

set torque 0.0 loop

loop

increment torque 0.01 exit torque 0.8 delay 0.1 end

delay 1.0 loop

decrement torque 0.1 exit torque 0.1 delay 0.1 end

delay 1.0 end

Listing 1: Skrypt formujący trapezowy sygnał mo- mentu napędowego

Blok zadawania momentu napędowego umożli- wia precyzyjną zmianę wartości zadanej o 0.05 lub 0.01. Dodatkowo można wykonywać skokową zmianę momentu pomiędzy skrajnymi wartościami oraz war- tością zerową. Podobną funkcjonalność posiada blok

zadawania obciążenia. Ponieważ rzeczywistym obcią- żeniem silnika jest prądnica prądu stałego możliwe jest tylko tworzenie momentu oporowego przeciwne- go do momentu napędowego. Minusem tego rozwiąza- nia jest niewielki zakres możliwego do uzyskania mo- mentu oporowego dla małych prędkości obrotowych silnika.

Pozostałe bloki funkcjonalne pełnią już tylko ro- lę informacyjną. Blok statusu prezentuje aktualny stan falownika oraz stan procesów komunikacyjnych.

Przejście falownika w dany stan sygnalizowane jest ikoną czerwonej lampki obok etykiety (rysunek (4)).

Natomiast stan procesów odbiornika i nadajnika sy- gnalizowany jest za pomocą ikon połączonych wty- czek przy poprawnie nawiązanej komunikacji. Ikona ostrzeżenia w postaci wykrzyknika na żółtym tle jest wspólna dla całego bloku i oznacza sytuację gdy nie ma nawiązanej komunikacji z “Orzeszkiem”, a tym sa- mym nie ma żadnych wiarygodnych danych na temat stanu napędu. Sytuację taką przedstawia rysunek (5).

Ostatni blok - blok wartości rzeczywistych pre- zentuje wybrane sygnały w postaci paska postępu. Ze względu na niewielką prędkość aktualizowania danych (co 100 ms) elementy te pełnią jedynie rolę wizuali- zacyjną.

6. PRÓBY LABORATORYJNE Poprawność algorytmu sterowania sprawdzono w trzech różnych konfiguracjach sieci komputerowej.

Pierwsze próby przeprowadzono przy bezpośrednim podłączeniu komputera sterującego do modułu ether- netowego. Po uzyskaniu poprawnych wyników doko- nano prób sterowania poprzez sieć lokalną instytutu oraz sieć rozległą uczelni pomiędzy dwiema jednost- kami oddalonymi od siebie o kilka kilometrów. Wyni- ki tych prób wypadły pomyślnie.

Rysunek 6: Przebiegi zadawanego momentu, pręd- kości obrotowej oraz prądów fazowych zmierzonych przez sterownik napędu

Na rysunku (6) przedstawiono przebiegi czaso-

we wybranych sygnałów archiwizowanych w trakcie

procesu sterowania z uruchomionym skryptem użyt-

kownika przedstawionym na listingu (1). Uzyskane

pomiary pozwalają na odtworzenie stanu elektroma-

gnetycznego napędu. Umożliwia to udoskonalanie al-

gorytmu sterowania wektorowego zarówno w stanach dynamicznych jak i w stanach ustalonych.

7. WNIOSKI

Próby laboratoryjne pokazały, że jest możliwe sterowanie w czasie rzeczywistym, procesami przemy- słowymi o szybkozmiennych sygnałach poprzez inter- fejs ethernetowy przy pomocy 8-bitowego mikrokon- trolera jednoukładowego. Planuje się przeprowadze- nie badań nad regulatorem prędkości zaimplemento- wanym w programie uruchamianym na komputerze PC z zamkniętą pętlą sprzężenia zwrotnego poprzez interfejs ethernetowy. Taki układ pozwoli na zbadanie wpływu opóźnień wprowadzanych przez sieć kompu- terową oraz opracowanie algorytmów zapewniających poprawne sterowanie w takim systemie.

Poprzez możliwość archiwizowania danych po- miarowych i zmiennych procesu mikrokontrolera ste- rującego silnikiem, stworzone stanowisko bardzo do- brze nadaje się do testowania i analizy algorytmów związanych z napędem. Otrzymywane dane pozwala- ją na odtworzenie procesów zachodzących w napędzie bez ingerencji w normalną pracę sterownika.

Ponieważ autorzy dostrzegli niedogodności cza- sowe związane z przysyłaniem danych z wykorzysta- niem interfejsu SPI, rozważane jest wykorzystanie programowalnych układów logicznych CPLD. Zaim- plementowanie sprzętowych buforów typu FIFO po- zwoli na przeniesienie funkcji wymiany danych do układu CPLD. Rozważane też jest zastosowanie 32- bitowego procesora AT91R40008 firmy Atmel, który zastąpi stosowany do tej pory 8-bitowy mikrokontro- ler jednoukładowy. Pozwoli to zwiększyć ilość danych przesyłanych siecią komputerową oraz zaimplemento- wać nowe funkcje.

Literatura

[1] Dębowski A.: Sterowanie pośrednie momentem i strumieniem w falownikowym napędzie tram- waju. Mat. X Ogólnopolskiej Konferencji Na- ukowej „Semtrak 2002”, Zakopane-Kościelisko, 2002, s.145-154.

[2] Chudzik P., Dębowski A., Kobos W., Lisowski G., Szafran J.: Asynchroniczny napęd tramwajo- wy ze sterowaniem wektorowym – zasada działa- nia (1). Technika Transportu Szynowego, 2004, nr 3, s.52-55.

[3] Dębowski A., Chudzik P., Lisowski G.: State transitions in vector controlled AC tram drive.

Proceedings of Int. Conf. on Power Electronics and Motion Control, PEMC, Portoroz (Słowe- nia), August 30 – September 1, 2006.

[4] http://www.ethernut.de

[5] https://libre2.adacore.com/GtkAda [6] http://www.gtk.org

[7] John Barnes: “Programming in ADA 2005”, Ad- dison Wesley, Bk&CD-Rom edition (June 30, 2006)

[8] Ada 2005 Language Reference Manual