Do Projektu iAutomatyka dołączyli:

https://iautomatyka.pl/wp-content/uploads/2018/12/Modbus_1200x630.jpg

Modbus ASCII/RTU – przykład komunikacji PLC Siemens oraz Delta.


Modbus ASCII/RTU jest wciąż jednym z najpopularniejszych protokołów komunikacyjnych. W tym artykule chciałbym przedstawić teorię odnośnie Modbusa, a następnie 2 przykłady praktycznego wykonania takiej komunikacji: PLC Siemens S7-1200 z modułami IO WELLPRO oraz PLC Delta z regulatorami temperatury DTC 1000/2000.


Teoria

Modbus jest protokołem, który został stworzony przez firmę Modicon. Obecnie jest otwartym protokołem komunikacyjnym. Wynika z tego, że każdy producent może go bezpłatnie zastosować w swoim sprzęcie, co przyczyniło się do jego popularności i uczynienia z niego poniekąd standardu w automatyce przemysłowej. Jeśli chcemy połączyć ze sobą 2 urządzenia różnych producentów to najprostszym rozwiązaniem jest komunikacja za pomocą Modbus ASCII/RTU lub Modbus TCP.

Protokół Modbus opisuje zasady wymiany danych pomiędzy 2 lub więcej urządzeniami w sieci. Zasady te porządkują dostęp do łącza i rozwiązują problemy z konfliktami. W Modbusie mamy 2 rodzaje urządzeń:

  • Master,
  • Slave.

W sieci jest tylko 1 urządzenie Master oraz wiele urządzeń Slave. Master różni się od urządzeń Slave tym, że ma możliwość inicjalizacji komunikacji. Master nadaje do jednego/wszystkich urządzeń Slave. Urządzenia Slave wykonują polecenia przekazane przez Mastera: odczyt danych/zapis danych/diagnostyka po czym udzielają odpowiedzi z potwierdzeniem wykonania polecenia oraz danymi zwrotnymi w przypadku odczytu i diagnostyki.

Schemat sieci Modbus:

Na podstawie tego krótkiego opisu możemy już wyróżnić pewne cechy protokołu Modbus:

  • Urządzenie Master jest nadrzędne w stosunku do urządzeń Slave. Cechą urządzenia Master jest to, że posiada logikę sterującą komunikacją i pracą sieci. Masterem może być przykładowo sterownik PLC komunikujący się z falownikami zawierający logikę wynikającą z algorytmu maszyny/linii produkcyjnej. Sterowniki PLC mogą również pełnić rolę Slave względem nadrzędnego panelu HMI, który cyklicznie odpytuje Slave. Opcji jest wiele. Węzły podrzędne (Slave) nie podejmują samodzielnie transmisji,a jedynie odpowiadają na polecenia od Mastera,
  • Hierarchia Master-Slave w protokole Modbus eliminuje problem równoczesnego dostępu do łącza – nie występuje sytuacja, że kilka urządzeń jednocześnie chce nadawać, ponieważ tylko Master może inicjalizować komunikację,
  • Dzięki organizacji łączności na zasadzie Master (klient) – Slave (serwer) eliminowany jest również problem z przesyłaniem kilku komunikatów równocześnie do jednego urządzenia. Slave otrzymuje komunikaty tylko od Mastera – kolejny komunikat nie pojawi się dopóki Slave nie odeśle odpowiedzi lub nie upłynie zdefiniowany w masterze timeout. Master otrzymuje tylko odpowiedzi od Slave. Nie występuje sytuacja odpowiedzi od kilku Slave równocześnie ponieważ w przypadku komunikatu do wszystkich Slave (Broadcast) Slave nie udzielają odpowiedzi. W przypadku komunikacji z 1 Slave (Unicast) Master otrzymuje: odpowiedź poprawną / odpowiedź błędną, co jest sprawdzane / nie otrzymuje odpowiedzi, co jest sprawdzane przez timeout. Sprawdzanie odpowiedzi w taki sposób zabezpiecza komunikację przez zawieszeniem,
  • W protokole Modbus przesyłane są komunikaty – ramki. Na podstawie opisu komunikacji możemy wywnioskować jak będzie wyglądać ramka. Rzeczą oczywistą są dane – do zapisu dla Slave bądź odczytane ze Slave. Master komunikuje się z kolejnymi Slave, a więc Slave musi wiedzieć czy Master zwraca się do niego czy innego urządzenia, a więc konieczny jest adres. Dane mogą być odczytywane bądź zapisywane w różne obszary pamięci – wynika z tego, że ramka musi zawierać wybraną funkcję oraz adres startowy od którego zaczyna się odczyt/zapis. Wspominałem również, że sprawdzane są błędy komunikacji. Jedną z form kontroli jest kontrola spójności ramki – do wykonania kontroli spójności przewidziane są specjalne dane w ramce – suma kontrolna.

Ramki w protokole Modbus

Ramka Modbus ASCII


Bajty wysyłane szesnastkowo – po 2 znaki ASCII (każdy znak odpowiada 4 bitom) kodowane heksadecymalnie 0-9, A-F. Odstęp pomiędzy kolejnymi znakami musi być mniejszy niż 1 sekunda.

Ramka Modbus RTU

Bajty wysyłamy binarnie – 8 bitowe znaki – kodowanie binarne.

  • T – czas transmisji jednego znaku
  • Pomiędzy ramkami musi znajdować się odstęp czasowy (cisza na linii) dłuższy niż 3,5 T.
  • Pomiędzy kolejnymi znakami ramki nie może znajdować się odstęp dłuższy niż 1,5 T.

Adresy urządzeń Slave, Kody funkcji, Obszary pamięci, Błędy

Adresy

Dla urządzeń Slave adresy są w protokole Modbus wybierane z puli: 1-247. Adres 0 to adres rozgłoszeniowy. Urządzenie Master jako nadrzędne i jedyne tego typu w sieci nie posiada adresu. Najprostszą metodą ustawienia adresu urządzenia są fizyczne przełączniki. Gdy nie mamy do nich dostępu kolejną metodą jest dedykowane oprogramowanie od producenta urządzenia Slave. Najczęściej zapewniana jest funkcja automatycznego wykrywania parametrów komunikacji. Aby nadać unikalny adres dla każdego urządzenia musimy się łączyć z każdym urządzeniem po kolei ponieważ mają one ustawiony domyślny adres. Najtrudniejszą metodą ustawienia adresu jest ustawienie parametru adresu za pomocą zaprogramowanej własnoręcznie komunikacji Modbus.

Tabela funkcji dostępnych w protokole Modbus:

Tabela z adresami pamięci w protokole Modbus:

Przy czym warto przed każdym wpisaniem adresu danych sprawdzić go w dokumentacji producenta urządzenia z którym się łączymy, a powyższą tabelę traktować orientacyjnie.

Tabela z kodami błędów w protokole Modbus:

Każde zapytanie przesłane do urządzenia Slave powinno zwrócić odpowiedź. W przypadku problemów z komunikacją zwracana jest odpowiedź z błędem. Błędy wykrywane są na 2 sposoby: dzięki kontroli bitu parzystości znaku oraz za pomocą sum kontrolnych CRC/LRC.  Jeśli master nie otrzyma odpowiedzi w określonym czasie pojawia się błąd – Timeout. Czas oczekiwania na odpowiedź od Slave jest konfigurowany w urządzeniu Master. Wszystkie błędy występujące w komunikacji powinny być obsłużone przez urządzenie Master w taki sposób, aby możliwe było przywrócenie komunikacji.

Okablowanie

W komunikacji Modbus standardem transmisji jest RS-485. Okablowanie jest proste – 2 przewody o przekroju 0,75 mm2, na końcach przewodów wymagane są rezystory terminujące o oporności 100-120 Ohmów, kabel LiYCY. Przy zastosowaniu skrętki ekranowanej maksymalna długość przewodów to 1000 metrów. Transmisja charakteryzuje się dużą odpornością na zakłócenia. W aplikacjach przeznaczonych do pracy w trudnym środowisku wprowadzane są dodatkowe elementy w celu tłumienia sygnałów zakłócających. Ekran podłączamy po stronie Mastera.

Testowanie komunikacji

Plusem komunikacji Modbus jest możliwość diagnostyki, do której potrzebne jest tylko połączenie RS-232/RS-485 z komputerem PC. Jeśli laptop nie posiada portu szeregowego to prostym i tanim rozwiązaniem są konwertery.

Do diagnostyki potrzebujemy jeszcze oprogramowania. Programy do testów Modbusa ASCII/RTU ale również TCP jako Master/Slave są ogólnodostępne np. ModbusView TCP lub Simply Modbus Master. Za pomocą takiego programu jesteśmy w stanie sprawdzić komunikację z 2 stron: jako Master oraz Slave i określić po której stronie znajduje się problem.  Ogromnym ułatwieniem jest możliwość podglądu przesyłanych ramek. Niektórzy producenci umieszczają w dokumentacji opis jak powinny wyglądać ramki wymieniane z danym urządzeniem – z taką pomocą możemy w łatwy sposób usunąć błędy w ramkach wysyłanych przez Mastera.

Często producenci dostarczają gotowe oprogramowanie dedykowane sprzedawanym przez nich urządzeniom Slave. Za jego pomocą jesteśmy w stanie ustawić parametry komunikacji takie jak np. adres czy prędkość komunikacji, zdiagnozować urządzenie, sprawdzić stan rejestrów, czy zmienić inne parametry urządzenia.

Ja do testów używałem Wellpro Debugging Software oraz Delta Digital Controller Communication. Program dostępnych darmowo od producentów.

Ustawianie parametrów komunikacji modułów WELLPRO:

Test funkcji modułu WELLPRO:

Ustawianie parametrów komunikacji modułów DTC:

Test funkcji modułów DTC:

Oba programy są bardzo proste i intuicyjne dlatego nie będę opisywał ich obsługi.

Komunikacja Modbus: PLC Siemens – Moduły WELLPRO

Moduły WELLPRO to dobre rozwiązanie jeśli potrzebujemy dużej ilości wejść/wyjść w niskiej cenie odnośnie których nie mamy dużych wymagań względem niezawodności. Jest tak dlatego, że po utracie komunikacji stan wyjść jest utrzymywany – w wielu przypadkach utrzymanie stanu wyjść przez dłuższy czas może być niebezpieczne i spowodować uszkodzenia mechaniczne. Można mieć również pewne wątpliwości względem ich jakości, bo cena jest naprawdę niska. Jednak jeśli potrzebujemy przykładowo podłączyć dużą ilość lampek/przycisków to jak najbardziej takie rozwiązanie się sprawdza.

Opis wykonania komunikacji będzie przedstawiony w sposób jak najprostszy, tak, żeby każdy mógł go zrozumieć. Uważam, że również w taki właśnie sposób powinny być pisane programy. Opis obejmuje przygotowanie logiki do: zliczania zbocza statusów komunikacji, przechwytywania kodu błędu, resetu diagnostyki, wykonania komunikacji. Oczywiście to tylko jedna z metod – każdy może wykonać taką komunikację na własny sposób.

Do wykonania komunikacji potrzebujemy modułu z RS-485. W moim przypadku był to moduł CM1241. Moduł komunikacyjny trzeba dodać do konfiguracji sprzętowej. Otwieramy „Devices & networks”. Jeśli mamy dostęp do urządzenia i możemy wejść w online to najprościej w zakładce Online wybrać opcję „Upload devices as new station (hardware and software)” – mamy wtedy pewność, że konfiguracja sprzętowa jest poprawna, ponieważ została pobrana bezpośrednio z urządzenia. Jeśli nie mamy dostępu do urządzenia to musimy dodać moduł RS-485 ręcznie. Wybieramy go z okienka „hardware catalog”. Trzeba zwrócić uwagę aby wybrać poprawną wersję urządzenia. Najprościej wpisać nazwę modułu do wyszukiwarki i posiłkować się zamówieniem/fizycznym modułem i tym, co znajduje się w opisie.

Będę dodawał część screenów w całości bez żadnego powiększenia. Jeśli coś będzie niewidoczne to należy kliknąć prawym przyciskiem myszy i wybrać „Otwórz grafikę w nowej karcie”. 

Dodawanie modułu RS-485:

Po dodaniu modułu musimy go skonfigurować. Przedstawię tylko podstawową konfigurację potrzebną do uruchomienia modułu WELLPRO. Aby uruchomić RS-485 należy ustawić „Protocol: Freeport” oraz „Operating mode Half duplex RS-485 2-wire operations”. Następnie należy ustawić „Baud rate”, „Parity”, „Data Bits”, „Stop bits” zgodnie z ustawieniami jakie mamy w module (jeśli nic nie zmienialiśmy to możemy te ustawienia sprawdzić w dokumentacji, a jeśli zmienialiśmy to znamy je z programu konfiguracyjnego).

Konfiguracja modułu CM1241:

Jeśli mamy już skonfigurowany moduł to możemy przejść do pisania programu. Pierwszą rzeczą, którą musimy zrobić to jednokrotnie wykonać instrukcję „MB_COMM_LOAD” służącą do konfiguracji portu komunikacyjnego. W tym miejscu mogą się zacząć schody ponieważ zarówno blok „MB_COMM_LOAD” oraz „MB_MASTER”, a więc 2 bloki, których potrzebujemy do komunikacji mają kilka wersji. Jeśli coś nam nie działa to na pewno rzeczą, którą warto sprawdzić są wersje bloków komunikacyjnych. Ja używałem „MB_COMM_LOAD” w wersji 2.1 oraz „MB_MASTER” w wersji 2.2.

Instrukcje do komunikacji Modbus i wybór wersji:

Bloki komunikacyjne to zdecydowanie jedna z częściej powtarzających się w projektach część kodu, dlatego warto poświęcić więcej czasu na to, żeby napisać program w jak najlepszy sposób – tą część programu z pewnością będziemy kiedyś wykorzystywać w jakimś innym projekcie.

Ja przygotowałem sobie UDT w zakładce „PLC data types”. Mój data type składa się z 2 struktur, które podłączam na wejściu i wyjściu bloku funkcyjnego. Elementy struktury reprezentują interfejsy bloku MB_COMM_LOAD”, a oprócz tego wyjścia z licznikami statusów DONE i ERROR, wyjście z zapisanym STATUSem oraz wejście resetujące diagnostykę. Warto dodać komentarze do zmiennych, ponieważ po utworzeniu zmiennej typu „MB_COMM_LOAD_V2_1” wszystkie komenatrze będą widoczne i pomocne w pracy nad bloczkiem.

Data type:

Gdy mamy gotowy typ danych mały problem może stanowić wejście „PORT” typu „PORT” podpisane jako ID portu komunikacyjnego. Możemy je znaleźć wchodząc do zakładki „PLC tags”, a następnie „System constants” –  znajdujemy tam zmienną nazywającą się tak jak nasz moduł komunikacyjny o typie „PORT”, a więc tego, który jest nam potrzebny.

Port:

Gdy mamy sprawdzony numer portu możemy stworzyć DB w którym utworzymy zmienną typu „MB_COMM_LOAD_V2_1”. Następnie można przejść do ustawiania parametrów komunikacji wpisując do pola „Start value” odpowiednie wartości – musimy ustawić „Port”, „BAUD” oraz „RESP_TO”. „RESP_TO” to czas Timeoutu komunikacji o którym wspominałem w teoretycznej części artykułu.

DB „MODBUS_RTU”:

Mając gotowe typy danych i zmienne możemy przejść do tworzenia bloku funkcyjnego obsługującego instrukcję „MB_COMM_LOAD”. Do „Inputów” i „Outputów” kopiujemy utworzone wcześniej struktury z „Data type”. Potrzebujemy również zmiennej typu „MB_MASTER” pod którą podłączymy instancję bloku „MB_MASTER”. Ta zmienna może być tylko typu InOut. Jeśli jest problem z jej utworzeniem to polecam w jakimś miejscu w programie utworzyć blok „MB_MASTER” wraz z instancją, a następnie usunąć instrukcję z programu pozostawiając instancję. Trzeba również zwrócić uwagę na to, aby wywołując blok „MB_COMM_LOAD” jego instancja znajdowała się w zmiennych bloku funkcyjnego, który właśnie tworzymy, a więc w polu „Static”.

U mnie w pierwszej drabince znajduje się wywołany i obszyty blok funkcyjny „MB_COMM_LOAD”, a następnie zliczanie zboczy ze statusów, przechwytywanie „STATUSu” oraz reset zmiennych diagnostycznych.

Blok funkcyjny:

Blok funkcyjny:

Blok funkcyjny obsługujący instrukcję „MB_COMM_LOAD” jest wywołany w bloku startowym Startup[OB100]. Na wejście REQ podawana jest jedynka. Instrukcje wykonują się jednokrotnie.

Wywołanie bloku funkcyjnego obsługującego instrukcję „MB_COMM_LOAD”:

Następnym krokiem po instrukcji „MB_COMM_LOAD” jest przygotowanie obsługi instrukcji „MB_MASTER”. Wszystko wygląda analogicznie jednak instancja bloku „MB_MASTER” musi być w zmiennych typu InOut ze względu na to, że jest używana przez instrukcję „MB_COMM_LOAD” w bloku OB100. Dodatkowo w InOut mamy również zmienną typu Variant, która jest pointerem do tablicy danych.

Blok funkcyjny:

Tablica danych, które odczytujemy/zapisujemy za pomocą instrukcji „MB_MASTER” musi znajdować się w bloku funkcyjnym, który jest niezoptymalizowany. W związku z tym po utworzeniu DB musimy wejść w jego ustawienia „Properties”, a następnie odznaczyć checkbox „Optimized block access”.

Blok danych:

Do wywołania bloku funkcyjnego podłączamy struktury, tablicę danych z niezoptymalizowanego DB, oraz instancję bloku „MB_MASTER” podłączoną również do bloku „MB_COMM_LOAD”.

Wywołania bloku funkcyjnego:

Mając gotowy blok funkcyjny obsługujący instrukcję „MB_MASTER” pozostaje już tylko przetestować komunikację, a następnie przygotować logikę obsługującą komunikacją w normalnym cyklu pracy.

Zmienną „DATA_LEN” ustawiamy na 8, ponieważ wszystkie zmienne (odczytywane/zapisywane) mają 8 bitów. Zmienna „MB_ADDR” oznacza adres urządzenia Slave z którym chcemy się połączyć.

  • Dla odczytu ustawiamy „MODE” na 0 oraz „DATA_ADDR” na 10001.
  • Dla zapisu ustawiamy „MODE” na 1 oraz „DATA_ADDR” na 1.

Połączenie wykonuje się gdy „REQ” = 1.

Zmienne podłączone do „MB_MASTER_V2_2_Wywolanie”:

Po stronie Siemensa to już koniec. W modułach WELLPRO niezbędne jest tylko ustawienie adresu jeśli liczba urządzeń > 1.

Jeśli chcemy traktować moduły jak typowe IO potrzebna jest jeszcze logika do cyklicznego odczytu wejść i wystawiania wyjść. Poniżej filmik z testów gotowego programu.

Testy komunikacji:

A tak wyglądają testy komunikacji w warunkach bardzo domowych. W tle zasilacz Wago, który wygrałem w Konkursie iAutomatyka (Dzięki :D). Na filmiku widzimy szybkość komunikacji reprezentowaną przez migające lampki oraz czas w jaki odświeżają nam się wyjścia (wszystkie wysterowane równocześnie).

Komunikacja Modbus: PLC Delta – Moduły DTC 1000/2000

Regulatory temperatury serii DTC 1000/2000 posiadają wbudowany protokół Modbus – mamy możliwość podłączenia do 7 rozszerzeń (automatyczne adresowanie). DTC 1000/2000 pozwala na podłączenie szerokiego wachlarzu czujników na wejściu oraz posiada różne rodzaje wyjść. Zapewnia również regulację typu: ON-OFF, PID oraz ręczną kontrolę. Korzyścią płynącą z komunikacji Modbus w modułach jest możliwość centralizacji podglądu danych procesowych i regulacji czy odpowiednie reakcje na informacje zwrotne z modułów zrealizowane przez sterowanie w PLC.

Port komunikacyjny RS-485 znajduje się już na pokładzie w naszym PLC – w dokumentacji oraz w sterowniku widnieje jako COM2.

Konfigurację rozpoczynamy od ustawienia Timeoutu i Communication Delay. Wartości do ustawienia odczytujemy z dokumentacji – jest dostępna tabela określająca czasy w zależności od modułu i PLC.

Timeout i Communication Delay:

Następnie przechodzimy do ustawienia parametrów komunikacji. Mamy do tego specjalną tabelkę w dokumentacji.

Dokumentacja parametry komunikacji:

Znając bity w rejestrze ustawiamy je pod parametry naszej komunikacji (odczytujemy z dokumentacji). Możemy ustawić parametry komunikacji jako podtrzymywane. Wybieramy Modbus ASCII lub Modbus RTU.

Parametry komunikacji:

Markery statusów komunikacji: 

Następnie możemy przejść do instrukcji odczytu i zapisu. Za pomocą wejścia „EN” wykonujemy instrukcję. „S1” to adres Slave, „S2” to adres danych w Slave, „n” ilość rejestrów do odczytu. Odczytane dane pojawią się w rejestrach od „D1050”.

Instrukcja „MODRD”:

Za pomocą wejścia „EN” wykonujemy instrukcję. „S1” to adres Slave, „S2” to adres danych w Slave, „n” to dane, które chcemy zapisać.


Instrukcja „MODWR”:

Rozpiska rejestrów i inne informacje znajdują się w dokumentacji „DTC1000/2000 Temperature ControllerUser Manual”.

Konfigurację modułów DTC1000/2000 wykonujemy w oprogramowaniu z wcześniejszej części artykułu. Do ustawienia jest adres jeśli mamy > 8 modułów, rodzaj czujników na wejściu, rodzaj regulacji.

U mnie program wygląda tak, że mam przygotowaną komunikację ręczną i automatyczną. W trybie ręcznym wszystkie parametry bloku jak adres Slave, adres danych itd. wpisuję ręcznie – tryb serwisowy. W trybie automatycznym wykonywany jest cykliczny odczyt temperatury ze wszystkich Slave, można ustawiać temperaturę (przerwanie odczytu), załączać i wyłączać pracę danego regulatora oraz zmieniać parametry PID.

Testy komunikacji:

Na filmiku widzimy cykliczny odczyt temperatury z modułów.

Artykuł został nagrodzony w Konkursie iAutomatyka w edycji Grudzień 2018 
Nagrodę Voucher na szkolenie Mitsubishi + gadżety firmowe dostarcza firma Mitsubishi Electric 

Więcej o konkursie: https://iautomatyka.pl/konkurs-iautomatyka/

 



Utworzono: / Kategoria: , , ,

Reklama

Newsletter

Zapisz się i jako pierwszy otrzymuj nowości!



PRZECZYTAJ RÓWNIEŻ



NAJNOWSZE PUBLIKACJE OD UŻYTKOWNIKÓW I FIRM

Reklama



POLECANE FIRMY I PRODUKTY