ZAGADNIENIE STEROWANIA RUCHEM ULICZNYM W STANDARDZIE MODBUS

Transkrypt

1 Prace Naukowe Instytutu Maszyn, Napędów i Pomiarów Elektrycznych Nr 63 Politechniki Wrocławskiej Nr 63 Studia i Materiały Nr Krzysztof PODLEJSKI*, Przemysław MROZEK* MODBUS, LabVIEW ZAGADNIENIE STEROWANIA RUCHEM ULICZNYM W STANDARDZIE MODBUS W artykule opisano podstawowe zasady wykorzystania środowiska LabVIEW do realizacji transmisji danych w standardzie MODBUS. Środowisko LabVIEW dostarcza odpowiednich bibliotek i funkcji dla standardu MODBUS, umożliwia pomiary wielu wielkości fizycznych i ich analizę a także ułatwia projektowanie i programowanie systemów kontrolno-pomiarowych poprzez rozbudowane formy graficzne. Wszystkie funkcje realizowane w standardzie MODBUS są dostępne w LabVIEW, jednak część z nich wymaga rozbudowania, co pokazano na przykładzie sterowania światłami regulującymi ruch drogowy na przejściu dla pieszych. Opracowany program umożliwia obserwację działania standardu MODBUS, ocenę poprawności transmisji danych w układzie MASTER SLAVE, wykrywanie i analizowanie błędów a także ocenę efektywności działania projektowanego układu, szczególnie z uwzględnieniem kryterium bezpieczeństwa sterowanego procesu. 1. WSTĘP Aplikacje napisane w LabVIEW mogą pracować pod kontrolą systemu MS Windows XP, Vista (także systemów Unix, Linux, Mac OS itp.). Środowisko umożliwia tworzenie aplikacji działających w systemie czasu rzeczywistego na komputerach PXI. Posiada mechanizmy pracy sieciowej DataSocket i RemotePanel realizujące wymianę danych pomiędzy aplikacjami pracującymi na różnych komputerach i możliwość zdalnego sterowania pracą rozproszonego systemu. W efekcie możliwa jest budowa systemu, w którym diagnozowanie poszczególnych urządzeń odbywa się w sposób niezależny, poprzez dedykowane do tego celu urządzenia a jednocześnie możliwe jest sterowanie danym procesem oraz wymiana informacji pomiędzy poszczególnymi elementami [1 4]. W standardzie MODBUS funkcje (rozkazy wysyłane przez jednostkę nadrzędną oraz interpretowane i wykonywane przez jednostki pod- * Politechnika Wrocławska, Instytut Maszyn, Napędów i Pomiarów Elektrycznych, Wrocław, ul. Smoluchowskiego 19, krzysztof.podlejski@pwr.wroc.pl

2 555 rzędne) są oddzielnym blokiem kodu, który może być wielokrotnie wykonywany w danym programie. W MODBUS dzielą się one na funkcje publiczne (standardowe) i funkcje definiowane przez użytkownika. Na rysunku 1 został przedstawiony schemat blokowy polecenia czytaj rejestry wejściowe (ang. Read Holding Register), dostępny w LabVIEW. Funkcja czytaj rejestry wyjściowe służy do odczytywania zawartości (od 1 to 125) rejestrów urządzenia podrzędnego. Rejestry tworzą spójny blok w przestrzeni adresowej urządzenia. Ramka polecenia zawiera adres pierwszego rejestru w bloku i liczbę rejestrów do odczytania. Kod tej funkcji w trybie RTU jest równy Rys. 1. Schemat blokowy polecenia czytaj rejestry wejściowe Fig. 1. Schematic diagram of control statement read input registers LabVIEW dostarcza kompletu narzędzi do realizacji transmisji danych w standardzie MODBUS [6, 7] ale część z nich wymaga rozbudowania przy opracowywaniu różnych aplikacji.

3 APLIKACJA W LabVIEW Z PROTOKOŁEM MODBUS Założono, że przykładowa aplikacja ma umożliwić poznanie protokołu MODBUS, w szczególności funkcji realizujących proces komunikacji między urządzeniami, obrazować efekty zmian wybranych parametrów, sygnalizować występujące błędy, ilustrować sytuacje niebezpieczne i stany awaryjne, umożliwić optymalizowanie działania procesu według przyjętych kryteriów. Analiza wybranych zastosowań standardu Modus i doświadczenie własne, skłoniła autorów do modelowania działania sygnalizacji świetlnej przy przejściu dla pieszych, wyposażonej w możliwość żądania światła zielonego przez pieszych. Rys. 2. Schemat blokowy sygnalizacji Fig. 2. Schematic diagram of the signalling Podstawowy schemat modelu przedstawia rys. 2, na którym cztery urządzenia typu Slave obrazują sygnalizację świetlną dla pieszych i pojazdów samochodowych. Urządzenie Master nadzoruje proces sterowania sygnalizacją. Ten prosty schemat, uzupełniony o możliwość żądania przez pieszych światła zielonego rozwija się w skomplikowany algorytm, budowany według kryterium zachowania bezpieczeństwa na przejściu. Podstawą algorytmu są zdefiniowane odcinki czasu: dt1 czas mierzony od momentu wciśnięcia przycisku skojarzonego ze światłami dla pieszych do chwili gdy zostanie włączone światło zielone. W tym czasie zawiera się interwał dla światła pomarańczowego (dtorange). dt2 czas mierzony od momentu włączenia światła zielonego dla pieszych do momentu włączenia się światła czerwonego, jest to czas jaki potrzebuje pieszy, aby przejść przez jezdnię. W tym czasie zawiera się interwał migotania tego światła (dtblink). dt3 czas włączenia światła czerwonego na przejściu dla pieszych. dtorange czas włączenia światła pomarańczowego dla aut; czas ten nie ma wpływu na pomiar czasu dt1 i dt3

4 557 dtblink czas migotania światła zielonego dla pieszych dtblinkfreq częstotliwość migotania W celu poprawnego funkcjonowania modelu powyższe czasy muszą spełniać następujące warunki: dt1 > 2 * dtorange dt2 > 2 * dtblink dtblink > 2 * dtblinkfreq Dodatkowo można regulować prędkość pojazdów. Do realizacji urządzenia Master w LabVIEW zostały użyte pętle Case i Stacked sequence oraz pętle for dla urządzenia Slave. Rys. 3. Panel czołowy (animacja) Fig. 3. The front panel (animation) Najpierw następuje otwarcie sesji VISA oraz inicjalizacja portów COM (adres, rejestry wejściowe). Master odpytuje urządzenie Slave o wybrane dane. Pierwsza sekwencja przygotowuje dane do formatu ramki w protokole MODBUS. Ramka ta jest zapisywana do portu za pomocą VISA Write VI. Następnie urządzenie Master oczekuje na odpowiedź z urządzenia Slave. Odebrane dane muszą zostać sformatowane tak, aby można je było przechowywać i odczytywać w LabVIEW. Urządzenie

5 558 Slave ciągle monitoruje porty, oczekując polecenia od Master, w tym celu wykorzystano pętlę czasową. Biblioteka NI MODBUS została zmodyfikowana tak, by możliwe było jednoczesne uruchomienie kilku urządzeń Slave. Do zobrazowania pracy świateł na przejściu dla pieszych został utworzony model animacyjny obrazujący przejście uliczne (rys. 3). Program Master mierzy czasy stanów świateł i na ich podstawie kontroluje pracę czterech programów Slave. Master wykorzystuje 4 porty szeregowe do komunikowania się z każdym urządzeniem Slave (komunikacja peer-to-peer). Każdy z programów Slave wykorzystuje jeden port. Porty mogą być fizyczne, ale dla testów zostały utworzone porty wirtualne [8]. Interfejs użytkownika dla programu Master składa się z 3 zakładek: Status, Settings i About. Po uruchomieniu wszystkich urządzeń Slave przy starcie, program Master przechodzi do zakładki Status. W lewej górnej części ekranu zostały umieszczone zielone diody informujące o poprawności uruchomienia aplikacji Slave, poprawności otwarcia portu szeregowego po stronie Master (Visa) i poprawności komunikacji pomiędzy Master a Slave (MODBUS). Wystąpienie błędu powoduje przejście w stan awaryjny i umożliwia jego lokalizację. Program Master składa się z siedmiu głównych sekwencji. Pierwsza to odczytania wartości dt1, dt2, dt3, dtorange, dtblink oraz dtblinkfreq (wprowadzonych przez użytkownika), zainicjowanie zmiennych globalnych i lokalnych oraz ustawienie na panelu frontowym aut, pieszego oraz zakładek głównych. W sekwencji drugiej następuje uruchomienie urządzeń Slave (świateł) po wybraniu przycisku RUN na panelu frontowym. W sekwencji trzeciej następuje zainicjowanie komunikacji między urządzeniami Master i Slave. W tej sekwencji odbywa się również sprawdzenie czy odpowiednie porty zostały otwarte (czy jest możliwa komunikacja Master Slave). Master komunikuje się z urządzeniami Slave za pomocą standardu VISA. Na rysunku 4 została przedstawiona sekwencja czwarta jest to schemat działania kilku pętli równoległych realizujących program obsługujący zdarzenia naciśnięcia przycisku STOP (SLAVE korzysta z algorytmu sterowania światłami, wpisuje stany wszystkich świateł i zatrzymuje ruch uliczny). Ostatnie sekwencje realizują zatrzymanie i zamykanie aplikacji oraz zapisanie wprowadzonych ustawień. Aplikacja Slave składa się z trzech sekwencji struktury Case. W pierwszej sekwencji następuje ustawienie parametrów Slave (adres, wartości rejestrów)oraz otwarcie portów. W drugiej sekwencji występują dwie pętle równoległe (przykładowy diagram na rys. 5). Pierwsza od góry pętla obsługuje komunikację (Slave Car czyta z rejestrów a Slave People, ustawia cyfrowe wejście oraz czyta z rejestrów MODBUS). Dolna pętla ustawia stan świateł na podstawie wartości rejestrów. W trzeciej sekwencji jest realizowane zamykanie portów dla urządzeń Slave.

6 Rys. 4. Diagram działania programu MASTER Fig. 4. Experimental identification tests running scheme MASTER 559

7 560 Rys. 5. Diagram działania programu SLAVE PEOPLE Fig. 5. Experimental identification tests running scheme SLAVE PEOPLE Wszystkie zdarzenia związane z procedurami sterowania światłami i występującymi błędami są zapisywane w odpowiednim pliku.

8 PODSUMOWANIE Celem zrealizowanych zadań było przedstawienie właściwości protokołu MODBUS, jego budowy i działania oraz utworzenie aplikacji opartej na tym protokole w środowisku LabVIEW. Jako model wybrano proces sterowania sygnalizacją świetlną na przejściu dla pieszych z możliwością żądania światła zielonego. Jako kryterium poprawności działania modelu przyjęto bezpieczeństwo pieszych. Na tej podstawie napisano algorytm zawierający zdefiniowane odcinki czasu regulujące zmianę świateł. Program wyposażono w funkcje sygnalizowania i definiowania błędów charakterystycznych dla standardu Modbus. Forma graficzna jest animacją i obrazuje ruch pieszych i pojazdów. Takie rozwiązanie panelu czołowego umożliwia wizualizację skutków poprawnego i nieprawidłowego dobrania wartości zdefiniowanych odcinków czasowych. Intencją autorów było także zwrócenie uwagi na możliwe konsekwencje stosowania układów zautomatyzowanych nie sygnalizujących błędów. W projekcie wykorzystano program Virtual Serial Port Driver dla utworzenia wirtualnych portów, niezbędnych do komunikacji między urządzeniami Slave oraz Master. Do realizacji modelu wykorzystano biblioteki środowiska LabVIEW dla protokołu Modbus, zostały one jednak zmodyfikowane w celu umożliwienia komunikacji urządzenia Master z wieloma urządzeniami Slave. Artykuł zawiera podstawowe informacje dotyczące symulowania zjawisk występujących w ruchu drogowym. Pokazuje możliwości środowiska LabVIEW w wykorzystaniu do tego celu standardu Modbus. Opracowany program działa na zasadzie definiowania odpowiednich odcinków czasów i nie jest sprzeczny z wymaganiami dotyczącymi ruchu drogowego, zawartymi w odpowiednich normach i zaleceniach. LITERATURA [1] BATKO S., Sieci komputerowe. Topologia sieci, HEXA, Warszawa [2] DEREŃ A., Zastosowanie sieci przemysłowych, Turck, Warszawa [3] NORMAN P., Systemy komunikacji w technice automatyzacji, Centralny Ośrodek Szkolenia i Wydawnictw Stowarzyszenia Elektryków Polskich, Warszawa [4] MIELCZAREK W., Interfejsy cyfrowe, Helion, Warszawa [5] SHELDON T., Wielka encyklopedia sieci komputerowych, Robomatic, Wrocław [6] www. Modbus.pl [7] www. LabVIEW.pl [8]

9 562 THE PROBLEMS OF TRAFFIC LIGHTS CONTROL IN MODBUS STANDARD The major goal of this essay is to present Modbus s structure, work and create model which is based on Modbus in the LabVIEW environment. The new model has to show communication between Master and Slave tool. User is able to define time parameter and stimulate process of changing traffic lights and it s dynamics based on new model. The program Virtual Serial Port Driver is used in this essay. This program enable to create virtual port which is necessary in communication between Master and Slave and modify library for Modbus in LabVIEW. The purpose of this essay is to underline inefficient daily use of traffic lights. Defects in traffic light configuration causes difficulties in every day routine, and create traffic jam. User can use new model to set up different times of changing traffic lights and change cars speed. Results of this experiment can improve traffic and assist in correct set up of traffic lights.