Do Projektu iAutomatyka dołączyli:

https://iautomatyka.pl/wp-content/uploads/2018/09/projekt-eaton-vs-siemens-v3.jpg

Komunikacja Modbus RTU: TIA Portal VS CoDeSys 3

autor: Przemek Czech.

Zgodnie z zapowiedziami w dzisiejszym artykule zajmiemy się komunikacją Modbus RTU za pomocą interfejsu RS-485. Pod lupę tym razem weźmiemy sterownik obecnie najpopularniejszego producenta sterowników – Siemens i jego najbardziej znany PLC, model S7-1200 programowany w środowisku TIA Portal (w naszym przypadku V13, jednak implementacja we wcześniejszych wersjach niczym się nie różni) oraz nowość na rynku, która z każdą kolejną funkcjonalnością coraz bardziej mnie zaskakuje (oczywiście pozytywnie) – Sterownik XC303 od Eatona programowany w Xsofcie (oparty na bardzo popularnym ostatnimi czasy CoDeSysie w wersji 3.5). Na starcie powiem, że na jednym z tych sterowników użycie Modbusa to spacer po rurki z kremem.

Za Slave’a posłuży nam znany z wcześniejszych artykułów falownik IG5A, a cały proces jego konfiguracji znajdziemy tutaj: Modbus RTU z WebHMI.

Nie  będę się również bardzo rozwodził nad zasadą działania protokołu oraz budowie ramki, gdyż zostało to wyjaśnione w tym artykule: Modbus RTU dla sterowników Mitsubishi FX5U


Siemens S7-1200

W tym przypadku, do uruchomienia protokołu nie wystarczy nam tylko CPU, gdyż panowie z Niemiec nie przewidzieli potrzeby wbudowania portu RS-485. Musimy zatem posiłkować się modułami rozszerzeń. Mamy do wyboru płytkę komunikacyjną CB 1241 montowaną na froncie sterownika lub moduł komunikacyjny CM 1241 montowany z lewej strony sterownika.

Ja wykorzystam moduł komunikacyjny CM1241, który posiada złącze DB9 (potrzebne dla nas sygnały RX oraz TX znajdują się odpowiednio na 3 oraz 8 pinie złącza).

Okablowanie

Podłączamy zestaw jak na załączonym schemacie. Od modułu CM1241 (piny 3 i 8) prowadzimy przewód do falownika LS IG5A na złącza S+ oraz S- (RS-485).

Programowanie

Tworzymy nowy projekt w TIA Portal. Przejdźmy do konfiguracji sprzętowej i dodajmy wykorzystywany moduł CM 1241.

Dla wygody pracy stworzymy strukturę, która pozwoli nam na pracę z blokami obsługi protokołu. Przechodzimy więc do PLC Data type -> Add new data type.

Nadajemy naszej strukturze nazwę, np. ModbusRTU i definiujemy następujące pola.

  • SlaveID – INT – adres naszego urządzenia podrzędnego (w zakresie 1-255, 0 jest adresem broadcast),
  • Mode – INT – zapis/odczyt – „1” – zapis, „0” – odczyt,
  • Adress – DINT – adres odczytywanego/zapisywanego rejestru,
  • Length – INT – długość przesyłanych danych,
  • Register – INT – wartość wysłanego/odebranego rejestru,
  • Error – BOOL – flaga błędu,
  • Busy – BOOL – flaga zajętości,
  • Done – BOOL – flaga wykonania operacji,
  • Status – WORD – status komunikacji.

Stwórzmy sobie osobny blok danych, w którym będziemy przechowywać nasze dane dotyczące komunikacji.

Dobra praktyką jest wyłączenie optymalizacji bloku jeżeli mamy do czynienia z jakąkolwiek komunikacją, aby mieć kontrolę nad adresami w tych blokach.

Po przygotowaniu bloku pod komunikację można przejść do programowania. Utwórzmy własną funkcję FB_ModbusRTU. Od teraz pracujemy wyłącznie w tym bloku. Dodajmy do bloku FB_ModbusRTU dwie zmienne wejściowe: jedną typu INT – referencję częstotliwości – oraz drugą typu BOOL odpowiedzialną za sygnał start/stop. Będziemy korzystać w zasadzie z dwóch funkcji.

1.MB_COMM_LOAD – konfiguracja parametrów połączenia.

Parametry:

  • REQ – wykonaj,
  • PORT – ID modułu komunikacyjnego,
  • Baud – prędkość komunikacji,
  • MB_DB – nr bloku danych (do jednego modułu komunikacyjnego może być przypisany tylko jeden).

Wywołujemy go w pierwszym Networku naszego FB’ka. Takie wywołanie gwarantuje nam, że komunikacja podniesie się poprawnie, podczas gdy jeden z naszych slave’ów utraci połączenie.

2.MB_MASTER – wysłanie oraz odbieranie ramek do/od Slave’ów

Parametry wejściowe:

  • REQ – wykonaj,
  • MB_ADDR – adres naszego slave’a w sieci Modbus,
  • MODE – tryb pracy (1- Zapis, 0 – Odczyt),
  • DATA_ADDR – adres rejestru (do tego elementu jeszcze wrócimy),
  • DATA_LENGTH – ilość rejestrów,
  • DATA_PTR – wskaźnik na zmienną z danymi bądź adresowanie bezpośrednie.

Zainicjujmy te parametry, które nie zmienią się bez względu na to co chcemy przesłać do falownika (Network 4).

Wywołujemy blok z parametrami, które wcześniej zdefiniowaliśmy w bloku danych DB_ModbusRTU. Stwórzmy również licznik, który posłuży do wybierania przesyłanych danych (Network 3).

Dla wartości licznika 0 funkcje komunikacji będą przesyłać sygnał start/stop, a dla wartości 1 przesyłana jest aktualna wartość częstotliwości.

Wartości 5058 oraz 5057 to wartości słowa kontrolnego dla startu oraz stopu (rozpisałem to binarnie w artykule z WebHMI). Zgodnie z dokumentacją techniczną falownika adres tego rejestru to 6. Wartość 400006 wynika z offsetu, który zależy od funkcji Modbus. Dokładne wartości offsetów dla różnych funkcji można znaleźć w oknie pomocy funkcji MB_MASTER.

Sytuacja podobna jak wyżej. Przypisujemy wartość częstotliwości do zmiennej Register oraz adres rejestru zgodnie z dokumentacją techniczną falownika, przy uwzględnieniu odpowiedniego offsetu.

I to wszystko. Wystarczy wywołać blok stworzonej funkcji z odpowiednimi parametrami i cieszyć się z komunikacji.

Dodatkowo wykonałem wizualizację takiego procesu, ale to już jest materiał na kolejny artykuł.

Eaton XC303

Teraz weźmy na warsztat najmłodsze dziecko Eatona czyli XC303, programowany w Xsofcie (podstawka CodeSys 3.5). Jako, że jestem wielkim fanem CodeSys’a zakupiłem ten zestaw startowy tutaj. Pierwsze co przyszło mi na myśl po odebraniu przesyłki to przetestowanie wszystkich protokołów, które zaimplementował producent. Rzeczywiście – wszystko działa. Ten sterownik jest wręcz stworzony do pracy w sieci, chociażby przez to, że posiada trzy karty sieciowe, co pozwala działać w różnych sieciach. Tego nie oferuje popularny S7-1200. Ale to co zrobiło na mnie największe wrażenie to czas działania. Czas cyklu kilkukrotnie mniejszy niż w S7-1200. Dlatego też pomyślałem, że warto by było napisać coś na temat tego sterownika, a przy okazji zwieńczyć nim cykl artykułów o Modbusie RTU.

Więc do dzieła. Tworzymy nowy projekt oraz dodajemy nasz sterownik. W trybie Online ściągamy konfigurację i przechodzimy do implementacji sprzętowej Modbusa. W Panelu Devices (prawa strona okna) klikamy prawym przyciskiem myszy na Device XC303 i dajemy Add Device. Otwiera nam się nowe okno, w którym wybieramy MODBUS -> Modbus Serial Port -> Modbus COM.

W ten sposób uruchomiliśmy port RS485 z protokołem Modbus. Klikając na niego dwukrotnie otworzy nam się okno z parametrami połączenia, gdzie ustawiamy takie parametry jak używany port szeregowy (my docelowo zostawiamy „1”, ustawiając „2” wybierzemy port USB, w który też ten sterownik jest wyposażony), Baud Rate czyli prędkość komunikacji – w naszym przypadku 9600, Parity jest to kontrola parzystości ramki, Data Bits ilość bitów w ramce, Stop Bits ilość tzw. bitów stopu pomiędzy końcem ramki, a początkiem kolejnej.

Musimy skonfigurować sterownik PLC jako Master w sieci Modbus więc klikamy prawym przyciskiem na Modbus_COM i Add device. Wybieramy Modbus Serial Master  -> Modbus Master.

W konfiguracji Mastera możemy wybrać rodzaj protokołu (RTU lub ASCII),  maksymalny czas odpowiedzi od Slave oraz czas pomiędzy wysyłaniem kolejnych ramek. Polecam również zaznaczyć auto-restart communication, dzięki czemu w przypadku kiedy nam się „wysypie komunikacja” sterownik sam ją podniesie i będzie kontynuował wysyłanie ramek.

Zostało nam jeszcze dodanie urządzenia Slave oraz parametryzacja kanałów wymiany danych.

Slave dodajemy klikając Modbus_Master_Com_Port -> Add Device -> Modbus Serial Slave -> Modbus Slave COM PORT. 

Po dodaniu urządzenia przechodzimy do jego parametrów. W zakładce General ustawiamy adres w sieci Modbus (w naszym falowniku jest to 1) oraz Response Time czyli czas odpowiedzi – 1000 ms.

Przechodzimy do zakładki „Modbus Slave Channel”. Klikamy Add Channel. W sekcji Name podajemy dowolną nazwę. Access Type jest związany z funkcją protokołu Modbus. Do zapisywania rejestrów możemy użyć funkcji Write Multiple Register (Function Code 16). Kolejnym parametrem jest częstotliwość wysyłania danych. Mamy też możliwość wysyłania danych na żądanie. W sekcji Write Register ustawiamy adres z dokumentacji technicznej falownika. Od adresu podanego przez producenta odejmujemy jeden i zapisujemy wartość szesnastkowo. Dla wartości częstotliwości jest to adres 5, zatem w oknie konfiguracji kanału wymiany danych wpisujemy wartość 0x0004. Length ustawiamy na 1 ponieważ interesuje nas tylko jeden rejestr. Tak skonfigurowany kanał zatwierdzamy przyciskiem OK.  

Analogicznie przechodzimy przez proces dodania kanału dla rejestru sygnałów sterujących. Poprawnie skonfigurowana zakładka powinna wyglądać następująco.

W zakładce mapowania zmiennych mamy podane adresy utworzonych zmiennych.

W zasadzie to koniec pracy, bo operując na słowach %QW2 i QW4 możemy sterować falownikiem. Przygotowałem krótką funkcję, która pozwala na sterowanie falownikiem z poziomu wizualizacji.

Wywołanie funkcji w bloku Main:

Stworzona wizualizacja prezentuje się następująco:

Podsumowanie

Ten artykuł zamyka wszystko co chciałem wam przekazać na temat Modbus RTU. Mam nadzieje, że informacje zamieszczone w moich artykułach przydadzą się komuś przy tworzeniu połączeń pomiędzy urządzeniami, szczególnie, że w artykułach pojawiają się popularne urządzenia: sterowniki PLC Siemens, Mitsubishi Electric, sterowniki wykorzystujące oprogramowanie CodeSys, czy nawet popularny ostatnio WebHMI.

Modbus RTU jest już leciwy, ale wciąż jest jednym z najbardziej popularnych protokołów, obsługiwany przez wiele urządzeń różnych producentów. Uważam, że każdy kto zajmuje się sterownikami PLC powinien znać i umieć konfigurować ten protokół.

W kolejnym artykule będę chciał zająć się moim zdaniem następcą tego protokołu, który staję się co raz bardziej „modny” w  automatyce, ale to już niebawem.

 

Artykuł został nagrodzony w Konkursie iAutomatyka w edycji Wrzesień 2018
Nagrodę Multimetr Fluke 115 + gadżety reklamowe dostarcza firma STERCONTROLWięcej o konkursie: https://iautomatyka.pl/konkurs-iautomatyka/

 



Utworzono: / Kategoria: , , ,
  • Autor: Przemek Czech
  • Automatyk, absolwent mechatroniki interesujący się sterownikami PLC oraz systemami nadrzędnymi a zwłaszcza tymi które przenoszą klasyczna automatykę w świat IT
  • Profil Autora

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