ZERVI LABS
Od szkicu interfejsu do użytecznego narzędzia
Aplikacja PC jest pierwszą szerzej opracowaną warstwą Harpii. Powstała po to, aby wygodnie przygotować parametry inkubacji, przesłać je do urządzenia, obserwować przebieg procesu i diagnozować komunikację. Nie jest sterownikiem czasu rzeczywistego — ma być czytelnym panelem nadzorczym dla człowieka, a ciężar ciągłej pracy pozostawić STM32.
Program rozwijam w Pythonie 3.11 z użyciem Kivy. Obsługa portu szeregowego opiera się na pyserial, wykresy na Matplotlib, a profile można zapisywać w plikach JSON. Dzięki temu konfigurację da się przygotować wcześniej, sprawdzić i wykorzystać ponownie bez przepisywania całego harmonogramu od zera.
Co potrafi obecna wersja
Najważniejsze funkcje są zebrane w jednym programie, ale nadal pozostają rozdzielone na czytelne obszary. To ułatwia obsługę, a mi pozwala poprawiać komunikację bez przypadkowego rozmontowania całego interfejsu.
- tworzenie, edycja, sprawdzanie i zapisywanie profili inkubacji;
- odczyt konfiguracji z urządzenia, zapis oraz weryfikacja przez ponowny odczyt;
- panel HMI z parametrami bieżącymi, stanami i wyjściami sterującymi;
- komendy START, PAUSE, RESUME i STOP dla przebiegu procesu;
- wykresy temperatury i wilgotności oraz dziennik komunikacji;
- ręczny odczyt i zapis rejestrów do testów oraz diagnostyki.
Warstwy programu, żeby interfejs nie musiał znać każdego bajtu
Kod został rozdzielony na część startową, interfejs i moduł komunikacyjny. W praktyce główną rolę pełnią pliki main.py, ui.py oraz modbus_handler.py. Widoki zbierają polecenia użytkownika, logika sprawdza dane, a osobna warstwa buduje zapytania Modbus i obsługuje port szeregowy.
Komunikacja nie powinna blokować głównego wątku interfejsu. Dostęp do portu jest pilnowany, a cykliczny odczyt może odpuścić kolejkę, gdy trwa ważniejsza operacja. Dzięki temu opóźniona odpowiedź urządzenia nie zamienia okna programu w nieruchomy obrazek z dopiskiem „brak odpowiedzi”.
Jedna mapa danych dla aplikacji i sterownika
Komunikację uporządkowałem w mapie rejestrów Modbus. Osobne obszary przechowują polecenia, flagi stanu, konfigurację profili oraz dane bieżące. Aplikacja nie musi dzięki temu zgadywać, co oznacza dana liczba — każdy adres ma określoną rolę, format i kierunek przepływu.
Poza zwykłym odczytem i zapisem programu dodałem ręczne narzędzia serwisowe. Pozwalają sprawdzić pojedynczy rejestr lub ramkę podczas uruchamiania systemu. To mało widowiskowy ekran, ale właśnie takie narzędzia zwykle oszczędzają najwięcej czasu, gdy jedna wartość postanowi żyć własnym życiem.
Główne grupy danych Modbus
- Coils — polecenia sterujące, między innymi uruchomienie, pauza, wznowienie i zatrzymanie procesu;
- Discrete Inputs — flagi stanu, alarmów i gotowości urządzenia;
- Holding Registers — profile inkubacji, ustawienia procesu i dane serwisowe;
- Input Registers — bieżące pomiary, wartości zadane, czas pracy i stan elementów wykonawczych.
HMI, trendy i dane z symulatora
Panel HMI zbiera najważniejsze informacje w jednym miejscu: temperaturę, wilgotność, etap procesu, wartości zadane, stany wyjść oraz komunikaty. Osobny ekran wykresów pokazuje trendy w czasie, korzystając z czasu pracy raportowanego przez urządzenie, a nie tylko zegara komputera.
Na tym etapie dane pochodziły z symulatora, dlatego na zrzutach mogą pojawiać się wartości, których żaden rozsądny inkubator nie chciałby zobaczyć. Ich zadaniem było sprawdzenie przepływu, skalowania i reakcji interfejsu, nie udowadnianie jakości regulacji fizycznego urządzenia.
Co zostało sprawdzone, a czego ten etap jeszcze nie udowadnia
Do prób komunikacji wykorzystałem wirtualne porty com0com oraz symulator ModRSsim2. Pozwoliło to sprawdzić otwieranie połączenia, cykliczne odczyty, zapis konfiguracji, reakcje interfejsu, weryfikację danych i obsługę typowych błędów bez czekania na gotową elektronikę.
Te testy potwierdzają działanie warstwy PC i zgodność przyjętego sposobu wymiany danych z symulatorem. Nie są jeszcze testem fizycznego RS-485, oprogramowania STM32, czujników, mechaniki ani skuteczności biologicznej inkubacji. Te elementy pojawią się dopiero podczas kolejnych etapów integracji.
Wynik tego etapu
Powstała funkcjonalna aplikacja nadzorcza, a nie tylko makieta kilku ekranów. Można w niej przygotować profil, obsłużyć wymianę danych, obserwować stan i diagnozować komunikację. Następnym logicznym krokiem będzie spięcie tej warstwy z fizycznym sterownikiem i sprawdzenie, jak grzecznie teoria zachowuje się po podłączeniu prawdziwych przewodów.