Emulacja ASUTP: kontrolery Modbus RTU

Emulacja kontrolerów w systemach ASU TP do testowania

Tworzenie oprogramowania dla systemów automatyzacji procesów technologicznych (ASU TP) wymaga dokładnego testowania interakcji między urządzeniami, czujnikami i kontrolerami. Fizyczny pult uruchomieniowy z przełącznikami i czujnikiem ciężaru pozwala na symulację podstawowych scenariuszy, ale ogranicza testowanie według masy (do 30 kg) i nie umożliwia pełnej emulacji procesów równoległych. Przejście do emulacji programowej w Delphi usunęło te ograniczenia, zapewniając precyzyjną symulację protokołu Modbus RTU oraz zachowania modułów wejścia/wyjścia (MWW).

Emulator został zrealizowany jako konstruktor urządzeń: użytkownik dodaje kontrolery, przypisuje im adresy RS-485 oraz definiuje wejścia/wyjścia. Obsługuje wszystkie wersje sprzętu z przyciskami wyłączania, które symulują zerwanie połączenia.

Architektura emulatora

Główny ekran emulatora wyświetla listę urządzeń z wskaźnikami stanu. Dla kontrolerów wagowych dostępne są:

• Suwak zmiany masy bez ograniczeń fizycznych.
• Ręczna konfiguracja parametrów i zmiana stanów.
• Przełącznik trybu ręcznego/automatycznego z losowym przyrostem masy do realistycznego dawkowania.

Moduły wejścia/wyjścia pozwalają na ręczne przełączanie wejść/wyjść. Tryb automatyczny symuluje rzeczywiste dawkowanie materiałów (cement, żwir, woda).

Integracja z głównym oprogramowaniem jest minimalna: dyrektywa kompilatora $IF Emulate=True przekierowuje wywołania z ComPort.Write do Emulator.Send.

{$IF Emulate=True}
Emulator.Send(EmulData, FWaitingTime);
{$ELSE}
ComPort.Write(OutDIOM, 11, @InDIOM, 8);
ComPort.Wait(FWaitingTime);
{$IFEND}

Zmiany są lokalizowane w module komunikacji — polecenia Modbus RTU pozostają niezmienione, odpowiedzi są zgodne z specyfikacją.

Organizacja komunikacji i kolejek poleceń

Komunikacja oparta jest na wzorcu "polecenie" z kilkoma kolejkami do zapewnienia równoległości:

• Odczyt stanu kontrolerów (ciągły, nawet w stanie postoju).
• Odczyt wejść/wyjść MWW do kontroli.
• Wysyłanie poleceń (najwyższy priorytet: uruchomienie dawkowania, włączenie silników).

Ciągły strumień zarządza kolejkami. Kolejki odczytu uzupełniane są do progu, priorytetowe polecenia (od operatora) wstawiane są na początek. Polecenie tworzone jest dynamicznie na podstawie aktualnego i oczekiwanego stanu urządzenia.

Przykład: na betonowni równocześnie uruchamiane są 3+ dawkowania (konfiguracja, ustawienie masy, start). Na cementowni – sekwencyjna kontrola stanów przed kolejnym poleceniem.

Wskaźnik kolejek sygnalizuje utratę połączenia czerwonym kolorem. Opóźnienia na 10 MWW (20 ms/zapytanie) prowadzą do cyklu ~400 ms + skanowanie kontrolerów, co daje około 1 sekundy reakcji — uwzględnione w UI, aby uniknąć fałszywych błędów.

Zalety emulacji programowej

• Pełna symulacja scenariuszy: awarie, zaciągnięcia, równoległe dawkowania bez sprzętu fizycznego.
• Zapisywanie/ładowanie konfiguracji pod konkretne przedsiębiorstwo.
• Rozszerzalność: dodawanie nowych urządzeń — wystarczy znać specyfikację Modbus i kontrolerów.
• Szybsze uruchamianie: mniejsza liczba nieprzewidywalnych błędów na obiekcie.

Emulator działa z aplikacjami zewnętrznych systemów pod Windows XP/7, testując złożone procesy bez ryzyka przestoju lub uszkodzeń.

Co warto wiedzieć

• Emulacja zachowuje dokładność Modbus RTU, minimalizując zmiany w kodzie głównym.
• Obsługa trybu automatycznego z losowym dawkowaniem do realistycznych testów.
• Wielokrotne kolejki poleceń zapewniają równoległość bez blokad.
• Prostota: oswojenie w czasie nauki protokołu i dokumentacji urządzeń.
• Oszczędność: brak fizycznego pulpitu, przyspieszenie rozwoju i debugowania.

— Editorial Team