Konwerter Modbus MGate MB3000-G2: narzędzia diagnostyczne wbudowane w konsolę webową
Uruchomienie bramki protokołów Modbus rzadko kończy się na zapisaniu konfiguracji. Natychmiast pojawia się potrzeba weryfikacji, czy dane rzeczywiście przepływają, a w przypadku problemów – ustalenia, po której stronie leży ich przyczyna: w sieci Ethernet, w samej bramce czy na magistrali szeregowej. Seria MGate MB3000-G2 firmy Moxa wyróżnia się tym, że kompletny zestaw narzędzi diagnostycznych jest wbudowany bezpośrednio w konsolę webową urządzenia, bez konieczności stosowania zewnętrznego analizatora magistrali ani dodatkowego oprogramowania.
Protocol Diagnostics – weryfikacja komunikacji po obu stronach konwersji
Zakres funkcji diagnostycznych zależy częściowo od trybu pracy bramki. W trybie Transparent bramka przekazuje zapytania systemu nadrzędnego na magistralę szeregową. W trybie Agent sama cyklicznie odpytuje urządzenia i udostępnia dane z własnej pamięci wewnętrznej.
W trybie Transparent zakładka Client – MGate wyświetla listę podłączonych klientów Modbus TCP wraz z adresem IP, portem i statusem oraz narastającymi licznikami zapytań, odpowiedzi i ramek odrzuconych. Zakładka MGate – Server prezentuje analogiczne dane od strony urządzeń końcowych. Zestawienie obu widoków pozwala precyzyjne zlokalizować przerwę w komunikacji: jeśli klient otrzymuje odpowiedź na każde zapytanie, strona ethernetowa działa poprawnie, a problem dotyczy konkretnego portu szeregowego. Statusy opisują stan bieżący, natomiast liczniki narastają od momentu ostatniego naciśnięcia przycisku RESET COUNTERS – kilkadziesiąt zliczonych timeoutów przy statusie Normal oznacza historię wcześniejszych problemów, a nie sytuację aktualną.
Przy każdym porcie szeregowym oraz każdym połączonym serwerze Modbus TCP dostępny jest przycisk TEST uruchamiający wbudowane narzędzie Test Modbus Device. Wysyła ono zapytanie bezpośrednio z bramki do urządzenia wskazanego przez Modbus ID i zwraca wynik, przyczynę ewentualnego błędu oraz surową odpowiedź. Zapytanie wybiera się spośród standardowych kodów funkcji (odczyt 01, 02, 03, 04 lub zapis 05, 06, 15, 16) albo wprowadza jako własny ładunek w postaci szesnastkowej – adres urządzenia i sumę kontrolną bramka dodaje samodzielnie. Jeśli urządzenie nie obsługuje danego kodu funkcji lub adresu rejestru, odsyła wyjątek widoczny w polu Reason (np. 02 Illegal Data Address), co samo w sobie stanowi istotną informację: urządzenie odpowiada, a błąd leży w parametrach zapytania.
W trybie Agent zakładka Tag View wyświetla wszystkie skonfigurowane tagi z bieżącymi wartościami przeliczonymi według przypisanego typu danych, typem oraz znacznikiem czasu ostatniej aktualizacji. Kolumna Time jest najprostszym wskaźnikiem sprawności urządzenia – gdy przestaje odpowiadać, znacznik czasu jego tagów przestaje się odświeżać, a wyświetlana wartość zależy od ustawienia Fault Protection w komendzie. Funkcja TEST w trybie Agent działa odmiennie niż w trybie Transparent: zamiast wysyłać dowolne zapytanie odczytowe, zapisuje wartość do wybranego tagu, a przez niego do rejestru urządzenia. Wartość wpisuje się szesnastkowo w długości wynikającej z typu danych (np. 25,0 dla typu float to 41C80000). Pozwala to zweryfikować ścieżkę zapisu – adres rejestru, typ danych i kolejność bajtów – zanim skorzysta z niej system nadrzędny. Należy mieć na uwadze, że zapis jest rzeczywisty i nie należy stosować tej funkcji na pracującym obiekcie.
Traffic Monitor – podgląd ramek i analiza błędów
Traffic Monitor przechwytuje ramki Modbus przechodzące przez bramkę, rejestrując czas z dokładnością do milisekundy, źródło, cel, Modbus ID, kod funkcji, dane oraz przyczyny odrzucenia dla ramek błędnych. Przechwytywanie uruchamia przycisk START, a zebrane dane można przefiltrować i wyeksportować do pliku CSV. Przejście na inną stronę konsoli lub wygaśnięcie sesji zatrzymuje monitor i czyści zapis – eksport należy wykonać przed opuszczeniem strony.
W trybie Transparent obie strony konwersji widoczne są w jednym widoku, co pozwala prześledzić kompletny cykl: zapytanie TCP od klienta, to samo zapytanie jako ramka RTU na porcie szeregowym, odpowiedź urządzenia i odpowiedź odesłana do klienta. Dane wyświetlane są w formacie szesnastkowym. Do ich interpretacji służy wbudowany Converter Tool, do którego przepisuje się pojedynczą wartość, a narzędzie pokazuje, jak ten ciąg bajtów wygląda w różnych typach danych.
W trybie Agent monitor obejmuje jedną stronę naraz, wskazaną na liście MGate Role. Rola Modbus RTU/ASCII Client pokazuje zapytania wysyłane przez bramkę na magistralę oraz odpowiedzi urządzeń. Po przełączeniu na rolę Modbus TCP Server widoczny jest ruch od strony systemu nadrzędnego, identyfikowany adresem IP klienta. Zestawienie obu widoków pozwala rozdzielić problemy sieciowe od problemów na magistrali.
Do najczęstszych błędów rejestrowanych w Traffic Monitorze należą: 0x0B Gateway Target Device Failed To Respond (brak odpowiedzi urządzenia – do sprawdzenia okablowanie, adres, parametry portu i timeout), 0x0A Gateway Path Unavailable (brak ID w tabeli routingu lub milczący serwer Modbus TCP), 0x06 Server Device Busy (kolejka pełna, mieści 32 zapytania na klienta) oraz CRC Error wskazujący na uszkodzoną sumę kontrolną – najczęściej wynikającą z nieprawidłowych parametrów portu, zakłóceń elektromagnetycznych lub kolizji na magistrali.
Network Monitor i Serial Port Monitor – diagnostyka warstwy fizycznej
Network Monitor analizuje ruch na interfejsie Ethernet bramki. Zakładka Network Statistics zawiera liczniki ramek Ethernet oraz pakietów według protokołów (TCP, UDP, ICMP, IPv4, IPv6) z przyrostem na sekundę. Rosnące liczniki Error, Drop lub Retransmitted wskazują na problem w sieci: uszkodzony kabel lub wtyk, przeciążony przełącznik albo niezgodne ustawienia portów. Jeśli liczniki stoją, a komunikacja Modbus zawodzi, przyczyna leży w konfiguracji lub na magistrali.
Zakładka Network Connections wyświetla listę gniazd sieciowych ze stanami połączeń. Wpis z lokalnym portem 502 w stanie ESTABLISHED oznacza aktywną sesję Modbus TCP. Warto zwrócić uwagę na wiszące sesje – gdy klient traci zasilanie lub aplikacja się zawiesza bez zamknięcia połączenia, sesja nadal zajmuje miejsce w puli 32 połączeń. Bramka zwalnia nieaktywne sesje po czasie TCP Alive Check Time, domyślnie 5 minut w trybie Transparent i 1 minutę w trybie Agent.
Serial Port Monitor pokazuje warstwę fizyczną magistrali: liczbę bajtów nadanych i odebranych na każdym porcie oraz liczniki błędów ramkowania, parzystości, przepełnienia bufora i przerwania transmisji. Kluczowe jest porównanie liczników Serial Tx i Serial Rx – gdy Tx rośnie, a Rx stoi, bramka nadaje, ale nie otrzymuje odpowiedzi (przerwany lub zamieniony przewód A/B, brak zasilania urządzenia, błędny adres lub prędkość transmisji). Gdy oba rosną, a błędy ramkowania narastają, sygnał dociera zniekształcony. W pierwszej kolejności należy sprawdzić parametry portu, terminację, polaryzację i uziemienie ekranu, zanim przystąpi się do analizy na poziomie protokołu.
Funkcja Ping umożliwia sprawdzenie dostępności urządzenia z perspektywy samej bramki, co pozwala rozstrzygnąć, czy problem leży w sieci, czy w protokole Modbus. Należy pamiętać, że zapora systemu Windows domyślnie blokuje odpowiedzi na ping, więc brak odpowiedzi nie zawsze oznacza awarię sieci.
System Log rejestruje zdarzenia systemowe i sieciowe: restart, zmianę konfiguracji, zanik łącza Ethernet, konflikt adresu IP. Rejestrowanie jest domyślnie wyłączone i należy je aktywować w System Settings > Notification przed wystąpieniem usterki – dopiero wtedy możliwe jest skorelowanie przerwy w danych widocznej w systemie SCADA z konkretnym zdarzeniem w bramce.
Uzupełnieniem warstwy powiadamiania jest funkcja Active Relay, która umożliwia powiązanie zdarzeń diagnostycznych z działaniem fizycznego przekaźnika alarmowego wbudowanego w bramkę. Dzięki temu wybrane stany awaryjne – takie jak zanik łącza Ethernet czy brak odpowiedzi urządzenia – mogą być sygnalizowane bezpośrednio na poziomie instalacji, bez pośrednictwa systemu nadrzędnego.
Pakiet diagnostyczny dla wsparcia technicznego i limity pojemności
Gdy wbudowane narzędzia nie pozwalają samodzielnie rozwiązać problemu, zakładka Diagnostics > Support umożliwia wygenerowanie zaszyfrowanego raportu diagnostycznego przeznaczonego dla inżynierów Moxa. Raport zawiera dane identyfikujące urządzenie oraz komplet informacji diagnostycznych.
Przy planowaniu instalacji istotne są limity serii MGate MB3000-G2: bramka obsługuje do 32 zapytań w kolejce od jednego klienta TCP, do 32 serwerów Modbus TCP, do 31 urządzeń na jednym porcie RS-485 oraz adresy Modbus ID w tabeli routingu w zakresie 1–255. Warianty w serii różnią się liczbą portów szeregowych: MGate MB3170-G2 dysponuje jednym portem, MGate MB3270-G2 (model zastosowany w opisywanych przykładach) dwoma niezależnymi portami z obsługą mapowania adresów Mapped ID, a MGate MB3470-G2 czterema portami z routingiem i priorytetyzacją zapytań.
Diagnostyka serii MGate MB3000-G2 przebiega według logicznej kolejności. Protocol Diagnostics wskazuje, które urządzenie nie odpowiada. Traffic Monitor pokazuje dokładną zawartość ramek i przyczyny ich odrzucenia. Serial Port Monitor diagnozuje warstwę fizyczną magistrali, a Ping oddziela awarię sieci od problemów z protokołem. Funkcja Active Relay pozwala powiązać wybrane zdarzenia diagnostyczne z fizycznym sygnałem alarmowym na poziomie instalacji. Wszystkie narzędzia dostępne są z poziomu przeglądarki internetowej, bez potrzeby stosowania zewnętrznego analizatora magistrali ani dodatkowego oprogramowania na komputerze serwisowym.
Źródło: Elmark Automatyka S.A.
Więcej na www.elmark.com.pl
