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.

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.

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.

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

Modbus ASCII, Modbus RTU, Modbus TCP- rodzaje Modbusa

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.

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

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.

START

BIT 1

BIT 2

BIT 3

BIT 4

BIT 5

BIT 6

BIT 7

BIT 8

STOP

STOP

START

BIT 1

BIT 2

BIT 3

BIT 4

BIT 6

BIT 7

BIT 8

PARITY

STOP

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

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.

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

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:

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.

• 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

• 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).

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 ↗

Efekt przygotowanego układu:

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 mm². 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.

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).

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):

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):

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):

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.

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):

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):

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

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

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.

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):

Odpowiedź Slava ([RTU] → Rx):

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:

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