Jak działa protokół Modbus?

Jak działa protokół Modbus? Protokół Modbus RTU to kluczowy standard komunikacji w świecie przemysłowym, umożliwiający skuteczną wymianę danych między urządzeniami. W niniejszym artykule dokładnie zgłębimy działanie tego protokołu, rozpoczynając od teorii i struktury ramki danych, poprzez omówienie praktycznych zastosowań aż po analizę danych na konkretnym przykładzie urządzenia – przetwornika wielopunktowego pomiaru TD2. Naszym celem jest przedstawienie kompleksowego spojrzenia na Modbus RTU, od podstawowych koncepcji po zastosowania w rzeczywistych środowiskach przemysłowych. Zawartość artykułu w skrócie:

  • Przykłady zastosowań,
  • sposób implementacji w systemach automatyki,
  • omówione warstwy komunikacji,
  • przesyłane ramki przeanalizowane bajt po bajcie z pomocą monitora portu szeregowego!

Jeśli podstawowe zagadnienia związane z komunikacją są Ci znane, możesz od razu przejść do cześci Komunikacja urządzeń Master – Salve. Pokazuje w niej działanie protokołu poprzez podgląd danych przesyłanych pomiędzy urządzeniami w sieci RS-485.

Program NtroScannerRS

Uwaga! Podczas konfigurowania urządzeń w czasie testów bardzo przydatne był program NtroScannerRS. Wyświetla on na bieżąco listę dostępnych szeregowych portów COM. Wykrycie nowego portu jest sygnalizowane informacją w prawym rogu ekranu. Program ten udostępniam za darmo tu: DARMOWE MATERIAŁY

Czym jest Protokół Modbus?

Jest to jeden z najstarszych protokołów komunikacyjnych. Zaprojektowany do komunikacji między wieloma urządzeniami poprzez skręconą parę przewodów. Pomimo że Modbus został opracowany i wprowadzony do użytku ponad 40 lat temu, jest wciąż popularny i wykorzystywany w przemyśle. Popularność protokołu Modbus wynika następujących powodów:

  • Idea działania jest stosunkowo prosta,
  • łatwy w implementacji,
  • łatwo dostosować go do zmian w projekcie,
  • niedrogi w implementacji,
  • uniwersalny — Modbus posiada bardzo mało ograniczeń w kwestii wymiany danych między urządzeniami.

Wielu producentów systemów automatyki implementuje modbusa w nowych urządzeniach i systemach. Nikogo z branży nie powinno dziwić obecność interfejsów Modbus we współczesnych modułach sieciowych, obok popularnych i młodszych standardów, jak Ethernet czy WiFi.

Standard Modbus umożliwia obsługę praktycznie wszystkich najpopularniejszych mediów transmisyjnych wykorzystywanych w rozwiązaniach przemysłowych np:

  • Skrętki-TP,
  • Ethernetu,
  • modemów telefonicznych,
  • komunikacji bezprzewodowej,
  • sieci GSM.

Uniwersalność modbusa niesie za sobą tę zaletę, że przy modernizacji systemów sterowania możliwe jest wykorzystanie istniejącej infrastruktury sieciowej, którą często jest skrętka TP.

Standard Modbus został opracowany przez firmę Modicon (obecnie Schneider Electric) w roku 1979. Szybko stał się standardem dedykowanym dla sieci automatyki przemysłowej, a firma Modicon udostępniła go jako darmowy, otwarty protokół komunikacji. Obecnie wsparciem i rozwojem tego standardu zajmuje się organizacja Modbus-IDA. Zrzesza ona dostawców i użytkowników protokołu Modbus.

Pierwsze instalacje modbusa bazowały na komunikacji RS232. Z czasem komunikacje została adaptowana przez standard RS 485. Pozwoliło to na przesyłanie danych na większe odległości oraz z większą szybkością transmisji.

Jeśli chodzi o standard przesyłu danych RS-485, to napisałem o nim dosyć szczegółowy artykuł, dostępny pod linkiem: Czym jest i jak działa RS-485 ?

Modbus RTU w sterownikach

Bazą komunikacji w Modbusie jest architektura Master — Slave. Urządzenie nadrzędne zwane Master, odpytuje urządzenie podrzędne, które nazywamy Slave. W instalacji może występować tylko jedno urządzenie Master. Urządzeń slave natomiast, w sieci z komunikacją przez Modbus RTU, nie można podłączyć więcej niż 255. Rolę Mastera może pełnić sterownik PLC, system DCS → moduły rozproszone, RTU → terminal zdalny, czy też komputer PC. Slavami są zwykle urządzenia obszarowe/obiektowe, które są podłączone do sieci w konfiguracji wielogałęziowej. Poniżej mamy przykład takiego połączenia sterownika PLC z 3 urządzeniami slave w sieci RS-485.

Komunikacja sterownika przemysłowego z przetownrikami temperatury przez protokół Modbus.

W Ntronic oferujemy przetworniki z portami RS485, w których protokołem komunikacyjnym jest właśnie Modbus — RTU. Urządzenia w protokole Modbus pracują jako moduły Slave, więc pozwalają one na łatwą komunikację ze sterownikami PLC. Ich główne zadanie to umożliwienie sterownikom przemysłowym, odczytywanie danych o temperaturze i wilgotności z wielu punktów jednocześnie w sieci OneWire.

Przetwornik TD2 ↗

Umożliwia odczyt z czujników temperatury i wilgotności w sieci OneWire o długości nawet 400 m. Dane można odczytywać portami RS485 i USB. Istotne jest, że te porty są separowane galwanicznie.

Przetwornik OneWire z RS-485 i modbus rtu. Obsługiwany przez protokół Modbus
TD2 przetwornik temperatury z interfejsem OneWire.

Moduł TD1.01 ↗

TD1.01 to konwerter temperatury z wyświetlaczem LED. Odczytuje temperaturę z 64 czujników temperatury DS18B20 w sieci o długości 100 m. Dane odczytujemy portem RS485 przez Modbus RTU

Przetwornik temperatury na szynę DIN z wyświetlaczem i portem RS485. Obsługiwany przez protokół Modbus
TD1.01 przetwornik temperatury z interfejsem OneWire i wyświetlaczem LED

Modbus ASCII, Modbus RTU, Modbus TCP- rodzaje Modbusa

Sposób kodowania danych w 3 najpopularniejszych obecnie rodzajach protokołu Modbus, którymi są: ASCII, RTU, TCP:

We wszystkich trzech wymienionych rodzajach Modbusa, wiadomości wysyłane są w tym samym formacie, a różnica wynika tylko ze sposobu ich kodowania na potrzeby transmisji.
Standard Modbus ASCII dane zapisuje w kodzie szesnastkowym, z wykorzystaniem znaków kodu ASCII. Do zapisania pojedynczego znaku, potrzeba aż dwa bajty, co wynosi dwa razy więcej niż w typach RTU i TCP. Jest to najwolniejszy rodzaj protokołu z całej grupy, jednak nadaje się doskonale do transmisji z wykorzystaniem modemów telefonicznych bądź transmisji radiowej RF (znaki ASCII dokładnie precyzują strukturę i zakres transmitowanych komunikatów). W konsekwencji nawet przy możliwych opóźnieniach sygnału w medium transmisyjnym przesyłana wiadomość nadal jest prawidłowo interpretowana w odbiorniku.

W standardzie Modbus RTU dane komunikatu zapisywane są w kodzie binarnym. Każdy bajt danych kodowany jest jednym bajtem komunikatu (bajtem w ramce). To rozwiązanie doskonale nadaje się do wykorzystania z medium transmisji w kanałach RS232RS485, z szybkościami transmisji od 1200 do 115 kbit/sek. Najczęściej stosowane szybkości to 9600 i 19 200 bit/sek. Modbus RTU jest najczęściej stosowanym obecnie protokół w sieciach automatyki przemysłowej i dlatego też większość informacji zamieszczonych w niniejszym artykule będzie dotyczyć aplikacji i zastosowań tego właśnie rodzaju protokołu.

Modbus TCP to nic innego jak protokół Modbus z transmisją przez sieć Ethernet. Zamiast adresów sieciowych urządzeń automatyki, do komunikacji z modułami Slave wykorzystuje się bezpośrednio adresy IP, a dane komunikatów Modbus tunelowane są w ramkach pakietów TCP/IP. W ten sposób każda sieć bazująca na protokole Ethernet może być wykorzystana jako medium transmisji komunikatów Modbus.

Podstawy komunikacji w sieciach Modbus

Urządzenie Master musi znać adresy wszystkich slave`ów w sieci. Chcąc uzyskać informacje z jakiegoś urządzenia, wysyła do sieci komunikat, tzw. ramkę danych. Zawiera ona adres urządzenia adresowanego, zapytanie o informację i sumę kontrolną, która służy do weryfikacji ewentualnych błędów transmisji. Komunikat ten trafia do wszystkich modułów w sieci, jednak odpowiedzieć może tylko ten o podanym adresie sieciowym.

Zapytanie w protokole Modbus
Reakcja urządzeń typu Slave na zapytanie Mastera w protokole Modbus

Tylko urządzenie Master może inicjować transmisje danych. Urządzeniu slave wolno tylko przesłać odpowiedź na zapytanie. Nie może ono być inicjatorem komunikacji. Oznacza to, że dla przykładu z rysunku powyżej, sterownik PLC chcąc uzyskać dane ze wszystkich slave`ów, lub przesłać je do nich, musi najpierw wysłać ramkę danych z adresem pierwszego Slava. Poczekać na odpowiedź i następnie wysłać ramkę z adresem 2 Slava. Znowu poczekać na odpowiedź. I na końcu wysłać i odebrać odpowiedź z 3-go slava.

Brak odpowiedzi na ramkę Modbus

Time out w protokole Modbus

Może się zdarzyć, że Master nie otrzyma odpowiedzi na zapytanie. Sytuacja taka wystąpi gdy doszło do zakłócenia przesłanych danych. Slave nie odpowie na zapytanie, jeśli nie otrzyma kolejnego bajtu podczas przesyłania ramki w określonym czasie — dochodzi wtedy do tzw. time-out`u komunikacji. Oznacza to po prostu urwaną ramkę i jest ona ignorowana. Jeśli natomiast zakłócenie spowoduje zmianę nawet tylko jednego bajtu, wówczas wyliczona suma kontrolna CRC nie będzie się zgadzać z tą przesłaną w ramce. Taka ramka zostanie odrzucona i Slave również nie odpowie na zapytanie.

Moduł Master po wysłaniu zapytania oczekuje na odpowiedź, odlicza czas oraz sprawdza ramki pod kątem poprawności sumy CRC. Jeśli wystąpił time-out, bądź suma CRC się nie zgadza, wysyła zapytanie ponownie. Parametr Time-out jest to parametr modyfikowalny i należy go tak dobrać, alby najwolniejszy Slave zdążył odpowiedzieć.

Ramka danych protokołu Modbus

Modbus RTU charakteryzuje się 8-bitowym kodowaniem danych. Dane przesyłane są asynchronicznie. Każdy przesyłany bajt wymaga przesłania 11 bitów z bitami startu i stopu. Jeśli nie chcemy kontrolować bitu parzystości, wówczas wykorzystujemy dwa bity stopu.

STARTBIT 1BIT 2BIT 3BIT 4BIT 5BIT 6BIT 7BIT 8STOPSTOP
Ośmiobitowy bajt danych bez kontroli parzystości
STARTBIT 1BIT 2BIT 3BIT 4BIT 6BIT 7BIT 8PARITYSTOP
Ośmiobitowy bajt danych z kontroli parzystości

Każdą wiadomość rozpoczyna i kończy tzw. cisza na łączu. Jest to czas bezczynności, trwający 3,5 x czas pojedynczego znaku.

Cisza na łączu w ramce danych Modbus

Cała ramka musi być transmitowana w sposób ciągły. Pomiędzy znakami tworzącymi ramkę nie może być większy odstęp niż 1,5 x długość pojedynczego znaku.

Maksymalna odstęp czowy między bajtami w komunikacji Modbus

Każda przesyłana ramka, niezależnie czy wysyłana przez Mastera czy Slave`a, zawiera następujące bajty:

ADRES URZĄDZENIA FUNKCJA POLE DANYCH Suma CRC
1 BAJT1 BAJTMAX 252 BAJTY2 BAJTY
Bajty zawarte w każdej ramce Modbus

Pole adresu w ramce Modbus

Poprzez to pole, Master adresuje Slave’a do którego chcę nadać ramkę. Slave w ramce z odpowiedzią umieszcza w tym polu swój adres, umożliwiając masterowi kontrolę z którym Slav`em realizowana jest transakcja, co więcej tylko Slave o adresie z ramki może odpowiedzieć na zapytanie Mastera. Urządzeniom można przypisać adres z zakresu 1 – 247.

Adres 0 Zarezerwowany jest dla komunikatów typu Broadcast, które są odbierane przez przez wszystkie Slave’y. Na komunikaty Broadcast’owe Slave’y nie mogą odpowiadać. Ze względu na fakt, że Master nie uzyskuje potwierdzenia czy Slave`y otrzymały polecenie, komunikat broadcast jest rzadko wykorzystywany.

Pole z numerem funkcji w ramce Modbus

Bajt ten informuje urządzenie Slave o czynności jaką ma wykonać. Wartość z zakresu 1 – 127 zarezerwowane są do przesyłania poprawnych kodów funkcji. Zakres 128 – 255 przewidziany jest dla odpowiedzi Slave`a któremu nie udało się wykonać polecenia. Przykładowo Master wysłał ramkę danych o funkcji 6 (zapis pojedynczego rejestru). W odpowiedzi zamiast funkcji 6 otrzymał 134 (86h – heksadecymalnie). Otrzymując taką ramkę Master wie, że zapis rejestru nie powiódł się. Dodatkowo Slave w polu danych ramki umieszcza kod błędu, co umożliwia Masterowi określenie rodzaju, bądź jego powód.. Jeśli natomiast zapis powiódłby się, Slave odesłałby ramkę z funkcją 6. (więcej na temat odpowiedzi wyjątkowych opisałem na końcu artykułu w części Błędne odpowiedzi).

Wspomniany zakres poprawnych funkcji 1 – 127, można podzielić na na 3 podgrupy:

  • publiczne – zdefiniowane przez standard, ich funkcjonalność jest jasno określona i udokumentowana. Są powszechnie stosowane w urządzeniach i będą szerzej omówione w artykule.
  • zdefiniowane przez producenta – mieszczą się one w dwóch zakresach: 65 – 72 oraz 100 – 110. Nie są zdefiniowane przez specyfikacje. Pozwalają producentom na przypisywanie własnych funkcjonalności urządzeń, jednak nie ma gwarancji, że użycie danego kodu funkcji będzie unikalne. Jeśli producent chciałby przypisać funkcjonalność do funkcji publicznej musi zgłosić się do organizacji zajmującej się wsparciem i rozwojem standardu Modbus
  • zarezerwowane – zastosowane przez niektórej firmy do starszych produktów, nie są dostępne do użytku publicznego.

Poniżej tabelka z najczęściej stosowanymi funkcjami publicznymi:

KODKOD SZESNASTKOWOOPIS
101hOdczyt wyjść bitowych
202hOdczyt wejść bitowych
3 03h Odczyt rejestrów
4 04h Odczyt rejestrów wejściowych
5 05h Zapis pojedynczego bitu
6 06h Zapis pojedynczego rejestru
7 07h Odczyt statusu urządzenia slave
8 08h Test diagnostyczny
15 0Fh Zapis bitów
16 10h Zapis rejestrów
17 11h Identyfikcja urządzenia slave
128 – 25580h – FFhOdpowiedzi wyjątkowe
Funkcje publiczne protokołu Modbus

Pole danych w ramce Modbus

Część z danymi zawiera dodatkowe informacje niezbędne jednostce Slve do wykonania określonego rozkazu zdefiniowanego w polu funkcji.

Część z danymi możemy podzielić na mniejsze części zawierające dodatkowe informacje, takie jak adresy rejestrów, liczba bajtów w polu danych oraz same właściwe dane. Poniżej przykłady ramek z różną zawartością pola danych.

  • Master żąda odczytu 4 rejestrów (kod funkcji 03h), pole danych zawiera: adres rejestru początkowego (09h) oraz ilość rejestrów do odczytu (04h). Ponieważ żądanie dotyczy odczytu danych, w ramce nie występuje pole na dane właściwe.
ADRES FUNKCJA POLE DANYCH Suma CRC

03h09h04h
adres rej początkowego ilość rejestrów
Ramka z żądaniem odczytu rejestrów
  • gdy master żąda zapisu grupy rejestrów (kod funkcji 10h), pole danych powinno zawierać: adres rejestru początkowego, ilość rejestrów, ilość pozostałych bajtów w polu danych oraz dane do zapisu
ADRES FUNKCJA POLE DANYCH Suma CRC

10h09h
02h 04h 01h 02h 03h 04h
Adres rejestru początkowego Ilość rejestrów Pozostałe bajty do przesłania Dane do zapisu
Ramka z żądaniem odczytu grupy rejestrów
  • Pole danych może mieć długość równą zero, gdy operacja określona kodem funkcji nie wymagającym żadnych parametrów. Może to być specjalny kod funkcji określony przez producenta urządzenia.

Suma CRC w ramce Modbus

Suma CRC to nic innego jak 16-bitowe słowo, będące specjalnym wyliczeniem algorytmu CRC16 ze wszystkich przesłanych bajtów w przesyłanej ramce. Urządzenie odbierające ramkę wylicza jej wartość z przysłanej ramki. Jeśli się nie zgadza z odebraną wartością, oznacza to zakłócenie i cała ramka jest odrzucana.

Typy danych w Modbus

W protokole Modbus zdefiniowano 2 rodzaje danych: cewki oraz rejestry. Każdy rodzaj danych ma przypisany określony zakres adresowy. To jednak producent urządzenia Slave definiuje jakie dane i w jakich zakresach rejestrów się znajdują. Próba odczytu, bądź zapisu do niezdefiniowanego adresu, powinna zwracać ramkę z informacją o błędzie.

Cewki reprezentują pojedyncze bity, mogą one przyjmować stan ON (1), bądź OFF (0). Zakres adresowy 1 – 9999 przypisano cewkom, mogącym odzwierciedlać stany fizycznych wejść urządzenia i wartość tych cewek możemy tylko odczytywać, są to tak zwane wejścia bitowe. Cewki z zakresu 10001 – 19999 (wyjścia bitowe) mogą reprezentować wyjścia fizyczne urządzenia np przekaźniki. Nazywane bywają wyjściami kontaktowymi. Ich wartości możemy odczytywać i zapisywać.

Rejestry dane reprezentowane w postaci 16-bitowych słów. Mogą one przyjmować wartości od 0 do 65535 (00h – FFFFh). Rejestry reprezentujące wartości liczbowe odczytywane z wejść analogowych urządzenia (np. pomiar temperatury, napięcia czy prądu) są to tzw. rejestry wejściowe i przypisany jest im zakres adresowy 30001 – 39999. Są to rejestry tylko do odczytu. Rejestry z zakresu 40001 – 49999 zwane, rejestrami pamiętającymi, mogą reprezentować np. ustawienia, czy konfigurację urządzenia. Są to rejestry, których wartości można odczytywać i modyfikować (oczywiście w zakresie zdefiniowanym przez producenta).

Jak przesłać liczby po przecinku i 32-bitowe w protokole Modbus

W rejestrach nie przewidziano reprezentacji danych dla liczb ujemnych, dla wartości powyżej 65535 oraz liczb postaci ułamkowej np: 115.124. Przesyłane dane są jednak ciągiem 0 i 1, więc nic nie stoi na przeszkodzie, aby dane odpowiednio zakodować.

  • Chcąc przechowywać w urządzeniu wartości temperatury z dwoma miejscami po przecinku. Przykładowo 78,45°C, wystarczy pomnożyć ją przez 100 i w rejestrach przechowywać wartość 7845. Po każdym odczycie w sterowniku dokonać dzielenia tej wartości przez 100.
  • Jeśli chcemy przesyłać liczby 32-bitowe, wystarczy odczytywać dwa sąsiednie rejestry. Po prostu jedna wartość 32-bitowa będzie zapisana w urządzeniu jako dwie 16-bitowe. W taki sposób możemy obsługiwać nawet liczby zmiennoprzecinkowe formatu 32-bitowego zapisane w standardzie IEEE.
TYP ZMIENNEJ RODZAJ ZMIENNEJ MOŻLIWOŚĆ ZAPISU ZASTOSOWANIE NUMER REJESTRU / CEWKI ADRES
Cewka wejściowajedno-bitowatylko odczytdwustanowe wejścia, wyjścia urządzeń 1 – 99990000 – 270E
Cewka wyjściowa jedno-bitowa odczyt i zapis przekaźniki wewnętrzne, wyjścia urządzeń 10001 – 19999 0000 – 270E
Rejestry wejściowe Słowo 16-bitowe tylko odczyt Liczbowe wartości na wejściach lub wyjściach 30001 – 39999 0000 – 270E
Rejestry pamiętające Słowo 16-bitoweodczyt i zapis Odczyty i zapisy do rejestrów wewnętrznych 40001 – 499990000 – 270E
Podziała na Cewki i rejestry w protokole Modbus

Niezależnie od typu danych, w przesyłanej ramce wszystkie dane adresowane są zakresem od 0 do 9999. Rozróżnianie ich następuje poprzez odpowiednie kody funkcji. Pole adresu w ramce należy skorygować o tzw. offset – odpowiedni dla danego typu danych. Chcąc przykładowo zapisać adres 30010, w polu adresu należy umieścić wartość 0009, gdyż 30010 – 30001 = 9.

Offsetem dla każdego typu danych są numery pierwszego rejestru (podświetliłem je na zielono w tabelce powyżej).

Mapa pamięci protokołu Modbus

Zasady umieszczania danych w rejestrach nie zawsze są zachowywane przez producentów urządzeń i np. wartości odczytywane z wejść analogowych możemy odczytać z adresów rejestrów pamiętających. Dlatego podczas wdrażania systemu z siecią Modbus niezbędną rzeczą jest Mapa Pamięci Modbus Urządzenia. Jest to nic innego jak baza danych, zazwyczaj w formie tabeli, w której wyszczególniane jest, jaki zakres rejestrów i cewek jest obsługiwany oraz co znajduje się pod tymi adresami. Mapa pamięci zazwyczaj jest udostępniana przez producenta w instrukcji urządzenia. Korzystając z mapy pamięci, można bardzo łatwo uzyskać dostęp do niezbędnych danych, zgodnie ze specyfikacją urządzenia.


Komunikacja urządzeń Master — Slave w Modbus RTU

Podczas projektowania instalacji przemysłowej i wdrażania komunikacji Modbus-RTU pomiędzy urządzeniami, projektant nie musi wiedzieć, jak faktycznie realizowana jest transmisja danych. Znając parametry urządzeń współpracujących, wystarczy poprawnie wypełnić pola w programach konfiguracyjnych urządzeń: Master’a i wszystkich Slave`ach. Nie zawsze urządzenie Slave wymaga konfiguracji.

Wiedza, jakie dane i spod jakich adresów urządzenie Master ma je odczytywać z urządzeń Slave`e powinna być wystarczająca do uruchomienia komunikacji pomiędzy urządzeniami. Natomiast znajomość działania protokółu oraz sposobu organizowania danych w przesyłanych ramkach pozwala na znacznie szybsze uruchomienie instalacji i ewentualne wykrycie i naprawienie błędów projektowych. Obserwacja transmisji oraz znajomość szczegółów dostarcza znacznie więcej informacji, niż sam efekt końcowy typu działa lub nie działa.

Na potrzeby tego wpisu przygotowałem testowy układ instalacji złożony z trzech przetworników TD2 połączonych w sieci RS-485. Do sieci wpiąłem również konwerter RS-485/USB umożliwiający mi podłączenie komputera (jako Mastera). Do każdego z przetworników podłączyłem po jedynej sondzie temperaturowej TEMPI1N. Wszystkie przetworniki zasiliłem z zasilacza 24 V.

Przetwornik TD2 to urządzenie pozwalające na odczyt wartości z wielu czujników, temperatury, wilgotności umieszczonych na wspólnej magistrali, której długość może wynosić nawet 400 m. Przykłady jak wykorzystać przetwornik w artykule na temat wielopunktowego pomiaru.

Przetwornik TD2 ↗

Przetwornik OneWire z RS-485
TD2 przetwornik temperatury z interfejsem OneWire.

Efekt przygotowanego układu:

Odczyt temperatury z przetworników w protokole Modbus.

Porty komunikacyjne RS-485 przetworników TD2 skonfigurowałem (poprzez port USB) na prędkość 115200 kb/s, brak kontroli parzystości, 2 bity stopu. Adres Slave kolejno 1, 2, 3 od lewej. Do każdego przetwornika podłączyłem po jednym czujniku temperatury. By ułatwić rozróżnienie, z którego modułu odczytujemy temperaturę, do konfiguracji dodałem ustawienie by Slave 1 zaniżał temperaturę o 10°C, natomiast 3-ci zawyżał o 10°C. Więcej na temat sposobów konfigurowania urządzenia w instrukcji obsługi. Do podłączenia wykorzystałem przewody 0,75 mm2. Oznaczenia kolorów to zasilanie 24 V DC brązowy, czujniki temperatury czarny, z wewnętrznymi żyłami czerwoną, żółtą i czarną, sieć RS-485 skręcona para biały z zielonym.

Zalecenia sieci RS485

Do realizacji sieci RS-485 zaleca się stosować skrętkę ekranowaną dwużyłową, kabel LiYCY lub dwu parową skrętkę ekranowaną (2×2 skręcone przewody, gdzie druga para jako rezerwa) kabel Li2YCY. Zalecane parametry kabla:

  • Impedancja falowa przy f>100 kHz: od 100 do 130 Ohm,
  • pojemność: 100 pF/m,
  • przekrój: 0,75 mm2 lub 0,8 mm2.
Emulator zapytań Modbusowych

Tak przygotowany układ posłuży do obserwacji przesyłanych danych. Jako moduł Master wykorzystam komputer z programem testującym  QModMaster. Jest to darmowe narzędzie symulujące pracę urządzenia Modbus Master. Podobnie jak fizyczne urządzenia programy testujące mogą pełnić rolę Master i Slave. Niektóre posiadają funkcjonalność podglądu przesyłanych bajtów, co jest niewątpliwą zaletą w wykrywaniu błędów. W przypadku naszego programu ta funkcja nazywa się Bus Monitor i z niej będziemy korzystać w testach.

Do rozpoczęcia testów potrzebujemy tylko przeprowadzić krótką konfigurację programu. W sekcji Options → Modbus RTU …wybieramy nr portu szeregowego odpowiadający konwerterowi RS-485/USB (u mnie 28), pozostałe parametry komunikacji ustawiamy tak jak w urządzeniach Slave czyli: 115200 kb/s, brak kontroli parzystości, 2 bity stopu. Zatwierdzamy OK.

W głównym oknie ustawiamy Modbus Mode na RTU i klikamy Connect. Zapytania będziemy wysyłać przyciskiem Read / Write. Natomiast Bus Monitor posłuży do podglądania przesyłanych bajtów. Poza wyświetlaniem przesłanych bajtów posiada on funkcjonalność rozkodowania danych w polu PDU (Protocol Data Unit).

Podgląd ramki Modbus

W przykładzie obok widzimy, że ramka wysłana przez Mastera [RTU] Tx, została nadana do Slave`a nr 2 z kodem funkcji 04 (odczyt rejestrów wejściowych) i adresie startowym 10 (czyli 30011, bo offset dla rejestrów wejściowych to 30001) o żądanej ilości rejestrów równej 10 (0Ah).

Podgląd ramki Modbus

Podczas testów w głównym oknie programu będziemy modyfikować ustawienia adresu Slave, adres startowy oraz ilości pożądanych danych (number of registers). Dla wygody format wyświetlanych danych ustawmy na dziesiętny (DEC).

Odczyt rejestrów — zapytanie 03h i 04h (odczyt temperatury)

Ponieważ format przesyłanych ramek funkcji 03h i 04h różni się tylko innym numerem funkcji, z tych dwóch przeanalizuję tylko funkcję odczytu rejestrów wejściowych: 04h.

Na początek przeprowadziłem prosty test odczytu pojedynczego rejestru wejściowego. Wartość temperatury z pierwszego czujnika, w przetworniku TD2, można odczytać z rejestru 30011. Chcąc odczytać temperaturę z czujnika podpiętego do środkowego przetwornika, wypełniamy okna programu. Adres Slave 2, kod funkcji 0x04 (oznacza to samo co 04h), ilość rejestrów 1. Klikamy Read / Write.

W narzędziu Bus Monitor widzimy, że przesłano następujące ramki.

[RTU] → Tx → 02 04 00 0A 00 01 11 FB
[RTU] → Rx → 02 04 02 09 F6 7B 26

Analiza ramki wysłanej przez Mastera ([RTU] → Tx):

ADRES FUNKCJA POLE DANYCH Suma CRC
02h 04h00h 0Ah 00h 01h11h FBh
Slave numer 2Odczyt rejestrów wejściowych Adres pierwszego czytanego rej: 30011-30001 = 10 ilość rejestrów: 1

Liczby 16-bitowe przesyłane są w dwóch częściach: Hi i Lo. W pytaniu wysyłany jest tylko adres początkowego (pierwszego czytanego) rejestru (000Ah) i łączna liczba wszystkich rejestrów (tu 0001h), które chcemy odczytać. Liczba odczytywanych rejestrów również przesyłana jest w dwóch częściach Hi i Lo.

Analiza ramki odesłanej przez Slava ([RTU] → Rx):

ADRES FUNKCJA POLE DANYCH Suma CRC
02h 04h02h 09h F6hFBh 26h
Slave numer 2Odczyt rejestrów wejściowych Ilość przesyłanych bajtów: 2przesyłana dana: 09F6h, (decymalnie 2550)

W ramce z odpowiedzią na funkcje 04h, przed polem z zawartością rejestrów, umieszcza się liczbę pozostałych bajtów z danymi do przesłania. Z otrzymanej odpowiedzi wynika, że zawartość rejestru 30011 to 2550, a to oznacza wskazanie temperatury 25,5°C.

Adresowanie 3. slave-a

Przy wysłaniu kolejnej ramki zmieniłem adres Slave na 3:

[RTU] → Tx → 03 04 00 0A 00 01 10 2A
[RTU] → Rx → 03 04 02 0D DE 44 38

Analiza ramki odesłanej przez Slave`a nr 3 ([RTU] → Rx):

ADRES FUNKCJA POLE DANYCH Suma CRC
03h 04h02h 0Dh DEh44h 38h
Slave numer 3Odczyt rejestrów wejściowych Ilość przesyłanych bajtów: 2przesyłana dana: 0DDEh, (decymalnie 3550)

Odczytana wartość to 35,55°C. Tak wysoka wartość wynika z tego, że przetwornik nr 3 został wcześniej tak skonfigurowany, aby do wartości z pierwszego czujnika dodawał wartość 10°C. Dzięki temu mamy pewność, że na zapytanie Mastera odpowiedział Slave o adresie podanym na początku ramki. W międzyczasie sprawdzałem, czy na poprawnym module zapalają się diody RX i TX, co oczywiście się zgadzało.

Odpowiedź jednocześnie dwóch urządzeń w sieci Modbus

Specyfikacja Modbus`a nie zezwala na powielanie adresów Slave. Jeśli w sieci są duplikowane adresy, odpowiada więcej niż jedno urządzenie. Żeby to przetestować, ustawiłem adres numer 1 dla dwóch urządzeń TD2 i wysłałem zapytanie. Oczywiście suma CRC nie była zgodna.

Zapis rejestrów

Zapis pojedynczego rejestru – 06h

Zapisu rejestrów dokonujemy funkcjami 06h (zapis pojedynczego rejestru), lub 10h (zapis wielu rejestrów). Zapisywać możemy tylko zakres rejestrów pamiętających (40001 – 49999) – tylko obszar określony przez producenta urządzenia.

Dobrym przykładem wykorzystania funkcji zapisu rejestrów jest wprowadzenie, wspomnianej wcześniej 10-stopniowej korekty temperaturowej. Wartość korekcji dla czujnika numer 3 w przetworniku TD2 mieści się pod adresem 40401. Ponieważ chcemy zapisać jeden rejestr, wykorzystamy funkcję 06h. Korekta 10°C odpowiada wartości 1000 w rejestrach. Adres startowy ustawiamy 400, natomiast w białej tabelce poniżej parametrów wpisujemy 1000.

Slave odpowiedział identyczną ramką, co oznacza poprawny zapis danej. Analiza ramki ([RTU] → Tx i Rx):

ADRES FUNKCJA POLE DANYCH Suma CRC
03h 06h01h 90h03h E8h89h 47h
Slave numer 3Zapis pojedynczego rejestru Adres zapisywanego rej: 40401-40001=400 przesyłana dana: 03E8h (decymalnie 1000)

Zapis rejestrów – 10h

Do zapisu wielu rejestrów musimy wykorzystać funkcję 10h (oczywiście działa ona także do zapisu pojedynczego rejestru). Dla przykładu chcąc zmienić parametry temperatury załączenia i wyłączenia przekaźnika (progi termostatu) w przetworniku TD2 wystarczy wpisać pożądane temperatury do rejestrów 40014 i 40015. Numery tych rejestrów łatwo znaleźć w mapie pamięci urządzenia dostępnej w instrukcji.

Zakładamy, że chcemy załączać przekaźnik przy temperaturze 29,75°C i wyłączać przy 25,15°C.

Analiza ramki wysłanej przez Mastera ([RTU] → Tx):

ADRES FUNKCJA POLE DANYCH Suma CRC
03h 10h00h 0Dh00h 02h04h0Bh 9Fh09h D3h4Ch 49h
Slave numer 3Zapis rejestrów Adres pierwszego zapisywanego rej: 40013-40001=12(0Dh) Przesłana ilość rejestrów Pozostałe bajty do przesłania 29752515

Odpowiedź Slave`a ([RTU] → Rx):

ADRES FUNKCJA POLE DANYCH Suma CRC
03h10h 00h 0Dh 00h 02hD1h E9h
Slave numer 3 Zapis rejestrów Adres pierwszego zapisanego rej.Ilość zapisanych rejestrów

Chciałem potwierdzić udany zapis temperatur, dlatego dodatkowo za pomocą programu konfiguracyjnego odczytałem ustawienia urządzenia (przez USB).

Konfiguracja przetwornika z Modbus

Błędne odpowiedzi

Podczas przesyłania danych, urządzenie Slave może w polu danych umieścić informację o błędzie. Dzięki czemu Master wie, że żądana operacja nie powiodła się oraz może nawet znać przyczynę błędu.

Odczyt Cewek w Modbus

Ramkę zawierającą informację o błędzie uzyskujemy próbując wysłać zapytanie odczytu wejść bitowych 02h, które nie jest obsługiwane przez urządzenie TD2.

Informacja o błędach składa się z: bajtu adresu urządzenia , bajtu z informacją o błędzie, bajtu o rodzaju błędu i pola CRC.

Analiza ramki wysłanej przez Mastera ([RTU] → Tx):

ADRES FUNKCJA POLE DANYCH Suma CRC
02h02h 00h 0Dh 00h 01hB9h F9h
Slave numer 2 Odczyt wejść bitowych Adres pierwszego wejścia.Ilość wejść

Odpowiedź Slava ([RTU] → Rx):

ADRES FUNKCJA POLE DANYCH Suma CRC
02h82h 01h 71h 60h
Slave numer 2Błąd poleceniaPrzyczyna błędu: Niedozwolona funkcja

Identyfikacja ramce z informacją o błędzie w Modbus

Jeśli Slave w polu funkcji przesłał bajt z ustawionym najstarszym bitem, w tym przypadku: 82h = 1000 0010b. Oznacza to, że przesłane polecenie nie zostało wykonane. (przykładowo dla funkcji 04h byłoby to 84h, a dla 10h – 90h.

Kod w polu danych 01h oznacza przyczynę nie wykonania polecenia – nieobsługiwana funkcja. Podstawowe kody błędów to:

KOD BŁĘDUOZNACZENIE
01hNiedozwolona funkcja
02hNiedozwolony adres danych
03hNiedozwolona wartość danych
04h Błąd urządzenia slave (niezidentyfikowana przyczyna)

Numery wyższe to błędy specjalistyczne np. 05 – potwierdzenie prawidłowego odbioru (gdy np. właściwa odpowiedź jest długa i może powodować timeout) .


Można by przeanalizować więcej przypadków wymieniania danych w protokole Modbus, jednak przede wszystkim, celem artykułu było poznanie podstawowych zagadnień Modbus — RTU oraz metody odczytu danych z Przetwornika TD2. Jeśli chciałbyś więcej tego typu wpisów, czy też masz jakieś uwagi, lub chciałbyś coś dodać. Proszę, podziel się tym w komentarzu, czy też napisz do mnie na maila. Zachęcam Cię również do zapisania się na mój newsletter (formularz do zapisu na dole strony), informuję w nim o nowych wpisach i nowościach z firmy Ntronic.

Wiodącym celem firmy Ntronic jest dostarczanie niezawodnych produktów spełniających oczekiwania klientów, dlatego wszelkie sugestie są skrupulatnie analizowane.

tel: +48 518 459 388
norbert.szymczyk@ntronic.pl

Dziękuje Norbert

5 thoughts on “Jak działa protokół Modbus?

Dodaj komentarz