Ten artykuł to w zasadzie mini kurs komunikacji Modbus TCP/IP. Zaprezentujemy możliwości komunikacyjne WebHMI z wykorzystaniem tego protokołu. Najpierw krótko sobie przypomnimy podstawowe informacje na temat Modbusa w ogóle oraz Modbusa TCP/IP w szczególności. Następnie przygotujemy nasz komputer oraz środowisko wirtualne do testów. W dwóch ostatnich krokach WebHMI skonfigurujemy zarówno jako klienta jak i serwer, oraz przetestujemy jego działanie z wykorzystaniem darmowych symulatorów.

Żaden artykuł nie będzie tak dobry jak film video. Dlatego zanim przejdziemy dalej warto zapoznać się z podstawami.

Protokół komunikacyjny Modbus

Modbus wciąż stanowi jeden z najczęściej używanych pomimo że jest jednym z najstarszych protokołów transmisji cyfrowej używanych w automatyce przemysłowej i budynkowej . Jego popularność wynika z:

• Otwartego standardu,
• Prostoty implementacji,
• Prostoty we wdrażaniu i diagnostyce,
• Możliwości obsługi za pomocą różnych mediów komunikacyjnych: RS-232, Ethermet, RS-485 etc.

Te wszystkie cechy sprawiają, że jest protokołem tanim i niewymagającym, dzięki czemu mimo takich wad jak niska szybkość transmisji spotkać go można praktycznie we wszystkich urządzeniach mających możliwość komunikacji sieciowej obok promowanych przez poszczególnych producentów nowocześniejszych protokołów jak Profibus, CAN czy Ethercat.

Jedna ze składowych ramki komunikacyjnej Modbus to kod funkcji. To on decyduje o tym, co będziemy odczytywać lub zapisywać. Dostępne są następujące kody funkcji:

• #01 – odczyt wyjść bitowych (Coils)
• #02 – odczyt wejść bitowych (Discrete Inputs)
• #03 – odczyt n rejestrów (Holding Registers)
• #04 – odczyt n rejestrów wejściowych (Input Registers)
• #05 – zapis 1 bitu (Coil)
• #06 – zapis 1 rejestru (Holding Register)
• #07 – odczyt statusu
• #08 – test diagnostyczny
• #0F – zapis n bitów (Coils)
• #10 – zapis n rejestrów (Holding Registers)
• #11 – identyfikacja urządzenia slave
• #80 – #FF – zarezerwowane na odpowiedzi błędne

Powyżej pojawiły się nazwy takie jak Coil czy Holding Register. Określają one obszary pamięci w komunikacji Modbus:

• Coils (C) – zmienne bitowe – możliwy odczyt i zapis – 1 bit długości
• Holding Registers (HR) – rejestry – możliwy odczyt i zapis – 16 bitów długości
• Discrete Inputs (DI) – zmienne bitowe wejściowe – możliwy tylko odczyt – 1 bit długości
• Input Registers (IR) – rejestry wejściowy – możliwy tylko odczyt – 16 bitów długości

Znajomość tych obszarów pamięci jest niezbędna do poprawnego adresowania zmiennych podczas konfiguracji komunikacji.

Modbus TCP/IP

Tematem tego artykułu jest Modbus TCP/IP, na którym się teraz skupimy. Jest to wersja Modbusa pracująca w oparciu o:

• Ethernet jako medium,
• TCP/IP jako protokół komunikacyjny i adresacja,
• architekturę klient-serwer,

gdzie tak naprawdę ramka Modbus RTU „opakowana” jest w protokół TCP/IP.

Modbus TCP/IP opiera się na sieciach Ethernet. Oznacza to, że fizycznie łączymy się za pomocą skrętki, a komunikacja przebiega w ramach sieci komputerowych, dzięki czemu możemy wykorzystać w budowie architektury i topologii naszej sieci urządzenia sieciowe takie jak switche i routery. W naszym przypadku jest to o tyle istotne, że będziemy mogli przeprowadzić symulację takiej sieci także w środowisku wirtualnym. Co więcej, przy odpowiedniej konfiguracji sieci zakładowej możliwa będzie zdalna komunikacja pomiędzy urządzeniami, co w przypadku Modbus RTU nie jest możliwe. Wykorzystanie TCP/IP jako protokołu wiąże się także z tym, że zamiast wykorzystywać adresy Slave od 1 do 247 wykorzystujemy adresy IP w postaci A.B.C.D, gdzie kolejne litery oznaczają kolejne oktety. Wykorzystując ten fakt możemy budować sieci bardziej rozbudowane niż 247 Slavów w Modbusie RTU.

Architektura klient-serwer to architektura sieci komputerowej, w której urządzenia zwane serwerami czekają i odpowiadają na żądania klientów. W przeciwieństwie do standardowego Modbus RTU, gdzie może funkcjonować w danej magistrali tylko jeden Master i wiele Slave’ów, tutaj klientów będących odpowiednikiem Mastera oraz serwerów będących odpowiednikiem Slave’ów może być wiele.

Modbus TCP/IP w WebHMI

WebHMI posiada możliwość zarówno skonfigurowania go jako klienta Modbus TCP/IP, jak i jako serwer. Jest to jego bardzo duża zaleta, wykorzystywana np. w aplikacjach gdzie WebHMI służy jako koncentrator danych pomiędzy sterownikami i urządzeniami polowymi a systemem nadrzędnym. Głównie jednak wykorzystuje Modbus TCP/IP do odczytywania danych z urządzeń i wyświetlania ich na wizualizacji SCADA. Zachęcamy do zapoznania się z możliwościami WebHMI:

Przykład wykorzystania WebHMI i odczytywania danych ze sterownika PLC WAGO PFC200

Zanim przejdziemy do dalszej części artykułu, warto zapoznać się z przykładem komunikacji w praktyce. Dzięki temu łatwo zorientujesz się do czego wykorzystujemy Modbus TCP/IP i zobaczysz do czego dążymy. W kolejnym rozdziale przejdziemy do części praktycznej i konfiguracji symulacji Modbus TCP/IP.

Przygotowanie środowiska wirtualnego

W ramach tego artykułu symulację będziemy przeprowadzać w środowisku wirtualnym Virtualbox, które pozwala na samodzielne przetestowanie WebHMI bez konieczności jego zakupu. Po jego instalacji pierwszym krokiem będzie pobranie oraz uruchomienie obrazu demonstracyjnego zgodnie z instrukcją.

Widok maszyny wirtualnej WebHMI w wersji demonstracyjnej

W efekcie będziemy posiadali działający obraz WebHMI z domyślnym adresem IP 192.168.1.1 (1)

Typy adapterów sieciowych w Virtualbox

Przed jego uruchomieniem należy w obrazie WebHMI aktywować kartę sieciową oraz ustawić odpowiedni typ połączenia (1):

• „Host-only adapter”, jeśli z WebHMI zamierzamy się łączyć za pomocą hosta, czyli naszego systemu operacyjnego zainstalowanego na komputerze.
• „Internal network”, jeśli będziemy się łączyć się z poziomu maszyny wirtualnej.
• „Bridged” – dla obydwu przypadków powyżej.

Następnie należy stosowanie skonfigurować naszą kartę sieciową w hoście lub maszynie wirtualnej, za pomocą której będziemy się łączyć, czyli przede wszystkim ustawić statyczny adres IP oraz maskę podsieci, a w przypadku maszyny wirtualnej również typ karty „Internal network” lub „Bridged”. Ja na potrzeby tego artykułu ustawiłem adres 192.168.1. 44.

WebHMI jako klient Modbus TCP/IP

Przejdźmy teraz do pierwszego zagadnienia, czyli skonfigurujmy WebHMI jako klienta Modbus TCP/IP.

W celu konfiguracji klienta Modbus TCP należy utworzyć nowe połączenie na podstronie Ustawienia → Zmienne.

Nowe połączenie Modbus TCP/IP

Nie będziemy tutaj wnikać szczegółowo w parametry połączenia, o których możecie poczytać np. tutaj, lecz skupimy się tylko na parametrach istotnych dla protokołu Modbus TCP/IP. Poza obowiązkowym nadaniem nazwy (1) wybieramy model urządzenia „Modbus” (2), protokół „ModBus TCP” (3),  oraz adres IP serwera, który będziemy odpytywać (4). Dodatkowo możemy jeszcze ustawić:

• Przesunięcie adresów (offset) (5), który w zależności od typów urządzenia może przyjmować wartości „0” lub „1”.
• Numer portu TCP (6), domyślnie przyjmujący wartość „502”.
• ID urządzenia (7), który domyślnie w Modbus TCP/IP jest ignorowany, choć ma swoje specyficzne zastosowania.

Następnie należy utworzyć zmienne dla tego połączenia.

Tworzenie zmiennych w połączeniu Modbus TCP

W polu adres należy podać adres rejestru (1), który chcemy odczytać z serwera. Poniżej pola wyświetla się informacja (2) ostrzegająca nas w przypadku wpisania nieprawidłowego adresu, podpowiadając również format dozwolonych adresów. Więcej szczegółów na temat adresacji możemy się dowiedzieć z instrukcji w dokumentacji producenta.

Rys. 6. Adresacja rejestrów klienta Modbus TCP w WebHMI.

Efekt po dodaniu zmiennych na ekranie „Zmienne”:

Ekran zmienne po dodaniu połączenia klienta Modbus TCP

W naszym przykładzie postanowiłem wykorzystać po jednej zmiennej każdego typu, czyli Coil, Digital Input, Input Register oraz Holding register  (1). Ze względu na brak połączenia widzimy kreski zamiast wartości w kolumnie „Wartość” (2). Warto zwrócić uwagę na format adresu, który należy odczytywać jako „numer_ID@adres_IP” serwera (3).

Przejdźmy teraz do serwera Modbus TCP. Dla celów tego artykułu użyłem darmowego serwera ModRSsim2.

Ekran symulatora serwera ModRSim2

Po uruchomieniu programu serwer od razu zaczyna działać i jest dostępny pod adresem IP komputera, na którym jest uruchomiony. Dowodem na to, że już działa, są informacja o niezerowej ilości odpytujący urządzeń (1), licznik odebranych i wysłanych pakietów (2) oraz diody Rx i Tx (3) oznaczające tradycyjnie sygnalizację odbioru i przesyłu pakietów. Na liście rozwijanej (4) możemy wybrać, która grupa rejestrów nas interesuje. Po wybraniu wyświetlają się w oknie poniżej (5). Program ma bardzo dużo innych przydatnych opcji, w które się nie będę teraz wgłębiał,

Poniżej animacja przedstawiająca testy połączenia:

Testy symulacyjne komunikacji WebHMI jako klienta Modbus TCP

Jak widzimy na załączonym GIF-ie, komunikacja działa poprawnie. Po kolei sprawdziłem czy wszystkie typy rejestrów są  odczytywane i zapisywane prawidłowo. Możecie też zobaczyć, że zgodnie z oczekiwaniami rejestry typu Holding Registers oraz Coil można zarówno odczytać, jak i zapisywać do nich, zaś rejestry typu Digital Input oraz Analog Input (Input Registers) można tylko odczytać bez możliwości ich zmiany z poziomu klienta.

WebHMI jako serwer Modbus TCP/IP

Przejdźmy teraz do ostatniej części artykułu, w której skonfigurujemy WebHMI do pracy jako serwer Modbus TCP/IP.

Pierwszą rzeczą którą należy wykonać jest aktywowanie funkcji serwera Modbus TCP. Opcja ta jest dostępna na podstronie Ustawienia → Ustawienia. Zaznaczamy „Włącz lokalny Modbus TCP serwer” (1) oraz ustawiamy numer portu (2) – domyślnie 502.

Włączenie serwera Modbus TCP

Po zaznaczeniu powyższej opcji w menu pojawi się nam nowa zakładka „Modbus TCP Serwer” (1). Po wybraniu tej opcji ukaże się nam okno do konfiguracji zmiennych, które wystawimy za pomocą Modbusa.

• 

  Opcja Serwera Modbus TCP

• 

  Konfiguracja adresów serwera Modbus

W tym oknie konfigurujemy, które zmienne chcemy udostępniać poprzez serwer Modbus TCP. W tym celu utworzyłem wcześniej połączenie korzystające z wewnętrznych rejestrów WebHMI (1), choć równie dobrze mogłyby to być zmienne połączenia o dowolnym innym protokole. Zmienne, które chcemy udostępniać poprzez serwer Modbus TCP, muszą mieć zaznaczone pole „Eksport” (2). Ostatnią czynnością jaką musimy wykonać jest ustawienie adresu rejestru Modbusowego naszej zmiennej (3). Adres podajemy jako wartość liczbową bez kodu funkcji tak jak też się spotyka w niektórych urządzeniach, czyli dla rejestru analogowego o adresie 10 zapiszemy 10. Nie określamy obszaru pamięci, gdyż wszystkie zmienne wystawiane przez WebHMI są 16-bitowymi rejestrami, które można odczytywać jako Input Registers lub odczytywać i zapisywać jako Holding Registers.

Przejdźmy teraz do konfiguracji klienta Modbus TCP. W tym celu wykorzystamy popularny w Polsce freeware’owy program Radzio! Modbus Master Simulator.

Konfiguracja parametrów połączenia w RMMS

Po otwarciu pierwsze co to należy skonfigurować połączenie. W tym celu klikamy w menu Connection -> Settings, a następnie ustawiamy odpowiednie parametry połączenia. W naszym przypadku należy wybrać protokół Modbus TCP (1), adres IP 192.168.1.1 (2) oraz numer portu 502 (3).

Dodanie połączenia w Radzio! Modbus Master Simulator

Następnie należy dodać nową zakładkę (1), w której podamy typ (2) oraz adres początkowy (3) i długość (4) ciągu rejestrów serwera, z których będziemy chcieli skorzystać.

W tym momencie pozostało nam tylko uruchomić klienta poprzez komendę Connect w menu Connection.

Testy symulacyjne komunikacji WebHMI jako serwer Modbus TCP

W powyższym GIF-ie przedstawiłem testy odpytywania serwera Modbus TCP działającego na WebHMI z symulatorem klienta. Przetestowałem kolejno czytanie rejestru jako Input register, a następnie czytanie i zapisywanie jako Holding register.

Warto zwrócić uwagę, że próba odczytania adresów, które nie są wystawione w WebHMI spowoduje pojawienie się błędu. Widać to także na powyższej animacji. Dopiero gdy wybrano długość 1, to błąd komunikacji zniknął.

Diagnostyka komunikacji Modbus w WebHMI

Skonfigurowaliśmy połączenia zgodnie z powyższym poradnikiem, jednak nie odczytujemy danych. Co w tym wypadku? Warto wtedy zajrzeć do logu diagnostycznego WebHMI, ale zanim to nastąpi to musimy jeszcze zmienić poziom logowanych wiadomości. Przechodzimy więc do podstrony Ustawienia → Ustawienia i wybieramy w opcji Poziom Logu wartość „Trace+Debug+Info+Errors”. Dzięki temu na podstronie „WebHMI Log” otrzymamy całe ramki danych wymieniane przez urządzenia. Pomogą one przy ustaleniu problemu w komunikacji. Ramki te są jednak zapisane szesnastkowo. Zamiast uczyć się na pamięć budowy takiej ramki i wszystkich możliwych kodów błędów można skorzystać z narzędzi online, które rozkodują nam taką ramkę:

Podsumowanie

W tym tutorialu przypomnieliśmy sobie podstawowe informacje na temat protokołu Modbus oraz Modbus TCP/IP, a następnie przeprowadziliśmy testy WebHMI skonfigurowanego zarówno jako serwer, jak i klient, w komunikacji z darmowymi symulatorami.