Wizualizacja danych sensorycznych

Wizualizacja danych sensorycznych
Oprogramowanie do sterowania i wizualizacji działania przetwornicy sterowanej
mikrokontrolerem
Paweł Kaczmarek
nr albumu: 163174
15 czerwca 2010
Spis treści
1 Opis projektu
2
2 Opis programu
2.1 Zapis ustawień . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
3 Opis interfejsu użytkownika
3.1 Główne okno programu . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Okno ustawień komunikacji . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Okno pomiarowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
6
7
4 Komunikacja
4.1 Cel komunikacji i opis wybranych rozwiązań . . . . . . . . . . . . . . .
4.2 Modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Rejestry Modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
8
9
5 Podsumowanie
11
1
1 Opis projektu
Tematem projektu jest stworzenie oprogramowania do sterowania i wizualizacji działania czterokanałowej przetwornicy step - down realizowanej w ramach projektu Sterowniki Robotów, prowadzonego przez dra inż. Marka Wnuka. Przetwornica sterowana
jest mikrokontrolerem MC9S08JM32CLD z rdzeniem HC9S08, ponadto w projekcie
wykorzystywane są przetwornice LM2596ADJ o regulowanym napięciu wyjściowym i
prądzie maksymalnym 3A, halotronowe czujniki natężenia prądu ACS712 (o wyjściu
analogowym) oraz czujnik temperatury TC74 (komunikacja za pomocą interfejsu I 2C)
.
Ukończone oprogramowanie urządzenia ma pozwolić na:
• Pełną kontrolę pracy przetwornicy podczas połączenia z komputerem (zdalne
włączanie/wyłączanie kanałów, włączanie/wyłączanie monitorowania kanałów,
zadawanie alarmowej i maksymalnej temperatury pracy, zadawanie napięcia oraz
jego dopuszczalnej odchyłki i maksymalnego prądu na każdym z kanałów
• Zadanie parametrów do pracy samodzielnej (zapisywanych w pamięci FLASH
µC), pozwalających to na włączenie z zadanymi parametrami pracy zaraz po
włączeniu zasilania)
• Wizualizację przebiegów czasowych napięć, prądów i temperatury urządzenia
• Wyświetlanie statusu urządzenia (aktualne błędy, ich resetowanie)
Najistotniejsze elementy projektu to:
• Stworzenie okienkowej aplikacji sterującej (Qt4)
• Implementacja opcji sterujących
• Uruchomienie komunikacji z mikrokontrolerem (podstawowe funkcje protokołu
Modbus - zapis i odczyt n rejestrów)
• Wizualizacja działania przetwornicy (Qwt)
2 Opis programu
Stworzone oprogramowanie składa się z dwóch dwóch zasadniczych części jakimi są
interfejs użytkownika zapewniający możliwość zmiany parametrów pracy i wyświetlenia
aktualnego stanu przetwornicy oraz moduł komunikacji, oparty o protokołów Modbus
- oba zagadnienia opisane są szczegółowo w kolejnych rozdziałach. Oprócz stworzonych
własnoręcznie modułów i standardowych bibliotek Qt wykorzystane zostały biblioteki
Qwt oraz qextserialport. Schemat blokowy stworzonego programu przedstawiony jest
na rysunku 1, zaś diagram UML, ze względu na swoje rozmiary umieszczony został w
pliku z materiałami dodatkowymi.
2
2.1 Zapis ustawień
Biblioteka Qt4 dostarcza niezwykle użyteczne narzędzie do zapisu ustawień oprogramowania. Za pomocą klasy QSettings zapisać można (do pliku lub w standardowej dla
systemu operacyjnego lokalizacji) dowolne parametry oprogramowania - od rozmiaru
okien, przez zaznaczone komponenty, aż po przechowywane wartości liczbowe. W stworzonym programie możliwości klasy zostały wykorzystane do zapisu 3 grup ustawień:
• ”Rej” - zawartość pierwszych 12 rejestrów protokołu Modbus (zadane parametry
pracy)
• ”Kom” - ustawienia związane z komunikacja z µC, m.in. częstotliwość wymiany
danych czy tryb wysyłania sterowań
• ”Wyk” - ustawienia związane z wyświetlanymi wykresami (które wartości, zakres
osi)
3 Opis interfejsu użytkownika
Graficzny interfejs aplikacji ma pozwalać na realizację całej opisanej powyżej funkcjonalności, składa się ona z 3 okienek stworzonych z wykorzystaniem zintegrowanego
środowiska programistycznego Qt Creator oraz narzędzia do projektowania interfejsów
graficznych Qt Designer.
3.1 Główne okno programu
Rysunek 2 przedstawia główne okno sterujące aplikacją. Zapewnia ono następującą
funkcjonalność:
• Włączenie/wyłączenie wszystkich kanałów
• Włączenie/wyłączenie monitorowania wszystkich kanałów
• Włączanie/wyłączanie każdego kanału z osobna
• Włączanie/wyłączanie monitorowania każdego kanału z osobna
• Zadawanie alarmowej i powodującej wyłączenie temperatury pracy przetwornicy
• Zadawanie zadanego napięcia, jego dopuszczalnej odchyłki oraz maksymalnego
prądy dla każdego z kanałów
• Wywołanie okna ustawień komunikacji (Ustawienia → Ustawienia komunikacji)
• Wywołanie okna rejestracji pomiarów (ikona wykresu na pasku narzędziowym)
• Polecenie żądania pobrania danych od przetwornicy (ikona odświeżania na pasku
narzędziowym)
• Polecenie żądania przesłania sterowania do przetwornicy (ikona strzałki na pasku
narzędziowym)
3
4
Rysunek 1: Schemat blokowy oprogramowania
5
Rysunek 2: Główne okno interfejsu użytkownika
Rysunek 3: Okno ustawień komunikacji
• Wysłanie do programu specjalnych komend sterujących - włącz/wyłącz, reset
błędów, zapisz ustawienia w pamięci FLASH (Komendy sterujące → ...)
• Zapis i odczytanie aktualnych parametrów programu i jego okien (Ustawienia
programu → ...)
• Wyświetlanie aktualnie zmierzonych wartości
• Sygnalizowanie stanu urządzenia (błędów)
Opisane powyżej okno w pełni spełnia swoje zadania. Jedynym brakującym elementem jest stworzenie dodatkowego okna parametrów transmisji szeregowej - takich
jak prędkości, bit parzystości czy liczba bitów stopu - kolejna wersja oprogramowania
zostanie rozwinięta o tę funkcjonalność.
Problem podczas realizacji tej części projektu, było znalezienie optymalnego sposobu wyświetlania informacji o błędach. W Widgetach środowiska KDE znajduje się
kontrolka diody LED, która idealnie nadaje się do tego zastosowania, jednakże nie
powiodło się doinstalowywanie odpowiednich bibliotek, by uruchomić ją w środowisku GNOME (takie rozwiązanie wpłynęło by też negatywnie na przenośność kodu).
Zastosowanym rozwiązaniem jest użycie kontrolek QRadioButton, których w stanie
wyłączenia (brak błędów) nie da się kliknąć, zaś w stanie włączenia (wystąpił błąd)
po kliknięciu automatycznie włączają się z powrotem.
3.2 Okno ustawień komunikacji
Rysunek 3 przedstawia okno ustawień komunikacji. Zapewnia ono następującą funkcjonalność:
• Wybór pomiędzy pobieraniem danych pomiarowych okresowo lub jedynie po wydaniu polecenia
• Wybór częstotliwości pobierania danych
• Wybór trybu wysyłania nowych danych sterujących:
– Automatycznie po każdej zmianie parametrów pracy
– Tylko po ręcznym żądaniu przesłania
– Okresowo
• Wybór częstotliwości okresowego przesyłania danych sterujących
6
Rysunek 4: Okno przebiegów czasowych
Po zamknięciu okna i jego powtórnym uruchomieniu, zaznaczone opcje są zapamiętane.
3.3 Okno pomiarowe
Na rysunku 4 przedstawiono okno przebiegów czasowych przetwornicy. Wykres i legenda przebiegu wygenerowane są za pomocą klasy Wykres dziedziczącej klasę QwtPlot. Podstawa czasu wykresu tworzona jest w zależności od częstotliwości odbierania
nowych danych (może także przedstawiać pomiary w chwilach ręcznego wymuszenia
pobrania wartości). Oprócz wyświetlania przebiegów okno zapewnia następującą funkcjonalność:
• Wybór wyświetlanych przebiegów
• Wybór pomiędzy automatycznym dobraniem skali osi Y, a ręcznym zadaniem
zakresu
• Możliwość podania górnej i dolnej wartości zakresu osi Y
• Zmiana liczby wyświetlanych pomiarów
• Zapis pomiarów do pliku
7
• Podanie ścieżki do pliku zapisu pomiarów
Opcja zapisu pomiarów do pliku pozwala na zapisywanie w określonym pliku (gdy
plik istnieje wyniki dopisane będą na końcu, gdy nie istnieje zostanie stworzony) wartości kolejnych próbek przebiegów wybranych do wyświetlania (oraz podstawy czasu).
Liczba zapisanych próbek jest zgodna z podaną w oknie (lub równa liczbie dokonanych pomiarów, jeśli ta liczba jest mniejsza), a format zapisu to kolumny separowane
znakami tabulacji, co powoduje, że plik może być bardzo łatwo wczytany przez oprogramowanie typu MS Excel czy Arkusz Kalkulacyjny OpenOffice.org.
4 Komunikacja
4.1 Cel komunikacji i opis wybranych rozwiązań
Komunikacja oprogramowania z przetwornicą ma realizować dwa podstawowe cele, jakimi są:
• odczytywanie aktualnego stanu przetwornicy (napięcia i prądy poszczególnych
kanałów, temperatura pola masy, informacje o błędach),
• przesyłanie nowych parametrów pracy (zmiana zadanego napięcia, jego możliwej
odchyłki, maksymalnego prądu, temperatury alarmowej i krytycznej, żądanie zresetowania błędów, wyłączenia przetwornicy oraz zapisu aktualnych ustawień).
Powyższe zadania zrealizowane są za pomocą:
• dwóch podstawowych poleceń protokołu Modbus (zapis i odczyt n rejestrów),
• standardu RS485, działającego w trybie half-duplex.
Wybrany sposób komunikacji wydaje się być bardzo dobrym rozwiązaniem dla przetwornicy zasilającej konstrukcje robotyczne - standard RS485 jest w nich bardzo często wykorzystywany ze względu na możliwość jednoczesnego podłączenia do magistrali
wielu urządzeń, a protokół Modbus zapewnia łatwy sposób odczytu i zapisu danych
zawartych w rejestrach oraz, niezwykle ważną w robotach, niezawodność działania, poprzez liczenie pola kontrolnego każdej z ramek. Podłączenie przetwornicy do komputera
zrealizowane jest za pomocą konwerterów RS485↔RS232 oraz RS232↔USB. Pozwala
to na komunikowanie się z urządzeniem jak ze zwykłym portem szeregowym.
4.2 Modbus
Zaimplementowany protokół Modbus działa w trybie RTU, z jednym bitem startu,
kontrolą parzystości (parzystej) oraz jednym bitem stopu oraz prędkością 9600 bps.
Tryb RTU wybrany został z dwóch powodów:
• jest domyślnym trybem działania protokołu Modbus i wedle dołączonej dokumentacji musi być zaimplementowany w każdym urządzeniu wykorzystującym
ten protokół,
• 8-bitowy tryb transmisji idealnie nadaje się do przesyłania 16 bitowych rejestrów,
których używa przetwornica (w trybie ASCII do przesłania 8 bitów danych potrzeba 2 bajtów).
8
Wykorzystanie trybu RTU wiąże się z koniecznością wysłania całej ramki danych
jako ciągłego strumienia znaków, co wymusza sprawdzanie podczas transmisji dwóch
warunków:
• odstęp czasu między kolejnymi znakami w ramce musi być krótszy niż 1,5 czasu
wysyłania znaku (np. dla prędkości 9600 bps, czas ten wynosi 1719µs),
• odstęp czasu między kolejnymi ramkami musi być dłuższy niż 3,5 czasu wysyłania
znaku (4010µs dla prędkości 9600 bps).
Po stronie mikrokontrolera testowanie czy powyższe warunki zostały spełnione wykonywane jest za pomocą przerwania od odbiornika SCI (testowana jest flaga Idle Line
- oznaczająca ciszę na linii przez okres nadawania jednego znaku) oraz przerwań od
Timera1. Po wykryciu Idle Line Timer1 jest zerowany oraz włączany, tak aby wygenerować przerwanie po czasie równym połowie czasu przesyłania znaku. W obsłudze
tego przerwania ustawiana jest flaga Przerwa oraz ustawiane jest zgłoszenie przerwania za podwojony czas wysyłania znaku. Tym razem w obsłudze przerwania Timer1
jest wyłączany, flaga Przerwa gaszona, a flaga Cisza (oznaczająca koniec ramki) ustawiana. Gdy nowy znak nadejdzie w czasie gdy ustawiona jest flaga Przerwa oznacza
to błąd braku ciągłości strumienia danych lub zbyt szybkie nadejście kolejnej ramki
- dotychczas odebrane informacje oraz nadchodzące, aż do ustawienia flagi Cisza są
ignorowane.
Analogiczna metodę planowano wykorzystać w tworzonym oprogramowaniu. Zamiast użycia flagi Idle Line planowano uruchomić obiekt QTimer po odczytaniu każdej
z ramek na czas równy półtorej okresu przesyłania znaku. Pierwszym napotkanym
problem była niewystarczająca rozdzielczość klasy QTimer (zadawanie czasu w ms),
jednakże dla stosowanej prędkości 9600 bps, nie stanowiło to przeszkody w zastosowaniu metody. Problemem, którego nie udało się rozwiązać, był sposób odbierania danych
przez klasę QextSerialPort. Po otrzymaniu nowych danych emituje ona sygnał readyRead(), oznaczający nowe dane w buforze. Istotą problemu jest pojawianie się znacznie
większej liczby danych niż tylko jednego bajtu (spowodowane jest to sposobem działania klasy QextSerialPort lub czasem od wyemitowania sygnału do odczytu bufora,
w którym nadchodzą kolejne znaki). Dla poprawnego odbierania danych czasy t1,5 i
t3,5 zostały wydłużone, przez co program nie kontroluje w pełni poprawności ciągłości
strumienia danych w ramce. Dodać należy, że sama klasa QextSerialPort nie dostarcza
żadnych mechanizmów pomocnych w kontroli opisanych powyżej czasów - dostępny
w niej pomiar czasu ma bardzo mało rozdzielczość (wedle dokumentacji w systemach
UNIXowych jest to 0,1s).
W trybie RTU każda przesłana ramka kończy się 16 bitowym polem kontrolnym
CRC (Cyclical Redundancy Checking). Wartość pola wyliczana jest przez cykliczne
dokonywanie operacji exlusive OR pola z kolejnymi przesyłanymi rejestrami oraz przesuwanie bitów o 8 pozycji w lewo (dodatkowo gdy LSB pola jest na końcu cyklu równe
1, dokonywana jest kolejna operacja exlusive OR). W programie zastosowano metodę
wyliczania CRC w oparciu o tablice bardziej i mniej znaczącego bajtu CRC, zaczerpniętą z dołączonej dokumentacji
4.3 Rejestry Modbus
Dane sterujące przetwornicą oraz aktualne dane pomiarowe zawarte są w 22 elementowej tablicy Rejestry, która odczytywana jest przez komendy protokołu Modbus Zapisz
9
n rejestrów (kod funkcji: 0x10) oraz Odczytaj n rejestrów (kod funkcji: 0x03). Zastosowanym uproszczeniem jest traktowanie wszystkich rejestrów jako Holding Registers,
mimo, iż w rzeczywistości część z nich pełni rolę rejestrów wejściowych. Dla ułatwienia
odczytywania i zapisywania elementów tablicy Rejestry, indeksowana jest ona za pomocą zmiennej wyliczeniowej enum Nr rej. Oto opis poszczególnych elementów tablicy
Rejestry:
• 0 = Zadane napiecie1 - zadane napięcie kanału 1-ego,
• 1 = Zadany prad1 - zadany prąd maksymalny kanału 1-ego,
• 2 = Zadane napiecie2 - zadane napięcie kanału 2-ego,
• 3 = Zadany prad2 - zadany prąd maksymalny kanału 2-ego,
• 4 = Zadane napiecie3 - zadane napięcie kanału 3-ego,
• 5 = Zadany prad3 - zadany prąd maksymalny kanału 3-ego,
• 6 = Zadane napiecie4 - zadane napięcie kanału 4-ego,
• 7 = Zadany prad4 - zadany prąd maksymalny kanału 4-ego,
• 8 = Dopuszczalny blad21 - górny bajt określa dopuszczalną odchyłkę napięcia
dla kanału 2-ego, zaś dolny na kanału 1-ego,
• 9 = Dopuszczalny blad43 - górny bajt określa dopuszczalną odchyłkę napięcia
dla kanału 4-ego, zaś dolny na kanału 3-ego,
• 10 = Temp wyl alarm - górny bajt określa temperaturę wyłączenia przetwornicy,
zaś dolny temperaturę alarmową,
• 11 = Sterowanie - bity 0...3 określają czy kanały 1...4 maja zostać włączone, bity
4...7 czy kanały 1...4 mają być monitorowane, bit 13 to polecenie resetu błędów,
bit 14 to polecenie wyłączenia przetwornicy, a bit 15 to polecenie zapisu ustawień
do pamięci flash,
• 12 = Aktualne napiecie1 - aktualne napięcie kanału 1-ego,
• 13 = Aktualny prad1 - aktualny prąd kanału 1-ego,
• 14 = Aktualne napiecie2 - aktualne napięcie kanału 2-ego,
• 15 = Aktualny prad2 - aktualny prąd kanału 2-ego,
• 16 = Aktualne napiecie3 - aktualne napięcie kanału 3-ego,
• 17 = Aktualny prad3 - aktualny prąd kanału 3-ego,
• 18 = Aktualne napiecie4 - aktualne napięcie kanału 4-ego,
• 19 = Aktualny prad4 - aktualny prąd kanału 4-ego,
• 20 = Aktualna temp - aktualna temperatura pola masy,
10
• 21 = Status - aktualny status urządzenia, 1 na bitach 0,2,4,6 - napięcie kanałów
1...4 poza zakresem, 1 na bitach 1,3,5,7 - prąd kanałów 1...4 większy od maksymalnego, 1 na bicie 8 - niezerowe napięcie na wyłączonym kanale, 1 na bicie 9 niezerowy prąd w wyłączonym kanale, 1 na bicie 10 - przekroczono temperaturę
alarmową, 1 na bicie 11 - przekroczono temperaturę wyłączenia.
Pierwsze 12 rejestrów modyfikowanych jest przez stworzone oprogramowanie (bardziej
znaczący bajt rejestru nr 11 jest także zmieniany przez mikrokontroler), zaś kolejne
10 jest przez program jedynie odczytywane. Napięcia w rejestrach wyrażone są w mV,
prądy w mA, a temperatura w stopniach Celsjusza.
5 Podsumowanie
Stworzone oprogramowanie spełnia postawione na początku semestru założenia. Dotychczasowe testy pokazały, że można za jego pomocą w łatwy sposób sterować przetwornicą, a wyświetlane przebiegi czasowe i stan urządzenia są zgodne z przewidywaniami. Złe oszacowanie czasu pracy na stworzone modułu komunikacji sprawiło, że
nie jest on w pełni zgodny ze specyfikacją trybu RTU (co udało się osiągnąć po stronie przetwornicy), jednak nie wpływa to w znaczący sposób na poprawność działania
programu. Kończąc projekt zauważono kilka braków, jak np. możliwość zmiany parametrów asynchronicznej transmisji szeregowej, bez ingerencję w kod programu, które
zostaną poprawione w finalnej wersji programu, na której stworzenie zabrakło czasu.
W materiałach dodatkowych dostarczono dokumentację stworzonego oprogramowania oraz samo oprogramowanie, które jednakże nie jest w pełni ukończone, co powoduje
np. wyświetlanie dużej liczby komunikatów diagnostycznych.
11