W obecnych systemach automatyki, komunikacja między sterownikami oraz innymi urządzeniami to stały element oprogramowania.
Ponieważ dysponuję zestawem sterowników jak na zdjęciu poniżej, postanowiłem przetestować różne sposoby skomunikowania ze sobą sterowników Simatic. Są to jedne z bardziej popularnych PLC, więc mam nadzieję, że dla osób które zaczynają przygodę ze sterownikami, ten artykuł będzie bardzo przydatny. W artykule zwracam także uwagę na pewne elementy, które są często pomijane w tego typu opisach. Dla osób, które dopiero poznają środowisko TIA, będzie to pomocne w nauce programowania – pokażę na czym polega dodawanie bloków funkcyjnych, generowanie DB, timerów itp.
1. Komunikacja PUT/GET
Komunikacja z wykorzystaniem bloków funkcyjnych PUT (zapis) i GET (odczyt) jest bardzo prosta do wykonania. Jest to komunikacja jednostronna, ponieważ opiera się na wymianie danych typu serwer-klient. Bloki funkcyjne są umieszczane w jednym ze sterowników i to wystarczy do wymiany danych między nimi. Bloki funkcyjne PUT/GET znajdują się w zakładce Communication/S7_communication.
Przy realizacji komunikacji PUT/GET należy pamiętać o następujących ograniczeniach:
- W danym czasie może być aktywna tylko jedna komunikacja PUT lub GET dla jednego połączenia S7-connection. Zbocza na wejściu REQ bloczków PUT i GET nie mogę się pojawiać w tym samym czasie. O prawidłowe aktywowanie funkcji GET i PUT musi zadbać programista.
- Komunikacja jest aktywna nawet wtedy, gdy sterownik udostępniający dane jest w trybie STOP. Dlatego do diagnostyki komunikacji najlepiej zastosować watchdogi.
- Należy pamiętać, że jeżeli komunikacja uległa przerwaniu (awaria jednego z sterowników, awaria elementów pośredniczących itp.), dane w DB odbiorczym zostają zapamiętane (zatrzaśnięte), co może w niektórych przypadkach doprowadzić do poważnych konsekwencji. W sterowniku gdzie znajdują się bloki funkcyjne PUT/GET, na wyjściach ERROR tych bloków pojawia się wartość 1 i można wtedy wykonać program obsługujący błąd komunikacji. Natomiast w drugim sterowniku nie ma żadnej informacji o braku komunikacji, dlatego programista również musi zadbać o diagnostykę komunikacji (np. stosując watchdog). W przeciwnym razie możemy doprowadzić do nieprawidłowego działania maszyny lub instalacji.
- w sterownikach S7-1200 i S7-1500 należy zezwolić na pobieranie danych z bloku danych (opcja w Device Conifiguration/General/Properties/Proctecion & Security/Connection mechanisms);
2. Komunikacja PUT/GET – sterownik S7-1500, S7-1200 w jednym projekcie
- Dodanie sterowników do projektu – sterowniki muszą być skonfigurowane w jednym projekcie TIA_PORTAL.
- Konfiguracja połączenia S7-connection – aby wykonać komunikację PUT/GET należy utworzyć połączenie S7-connection. W zakładce Network view należy połączyć ze sobą dwa sterowniki. Naciskamy port Ethernet jednego sterownika i przeciągamy do portu Ethernet drugiego sterownika.
- Następnie w górnych zakładkach wybieramy zakładkę Connections i rozwijanej listy S7_connections i ponownie przeciągamy od jednego portu Ethernet do drugiego.
- Po wykonaniu połączenia pojawią się właściwości utworzonego połączenia S7-connection. Są one tworzone automatycznie (jest możliwość edycji) i będą potrzebne do parametryzacji bloczków PUT/GET w programie sterownika.
- Tak przygotowaną konfigurację sieciową można wgrać do sterowników. Ważne jest aby to zrobić z poziomu Network view. Należy pamiętać też o tym, że sterowniki przejdą w tryb STOP w momencie przesyłania konfiguracji (jeśli maszyna jest w ruchu, lub jej elementy znajdują się z niebezpiecznym położeniu to należy zaczekać do zakończenia procesu).
Jeśli włączymy podgląd online sterowników, to możemy zobaczyć czy połączenie między sterownikami jest prawidłowe. Jeśli wykonujemy konfigurację połączenia dwóch sterowników w tym samy projekcie, to na pewno połączenie jest prawidłowe. Urządzeniem aktywnym dla tej komunikacji jest S7-1500, dlatego w tym sterowniku zostanie dodany program do obsługi komunikacji.
- Program dla sterownika – należy stworzyć w programie DB (w sumie 4 – 2 w jednym sterowniku, 2 w drugim), które będą nam służyć do wymiany danych. Dane i struktura mogą być dowolne. Ważne jest, by zachować porządek w projekcie. Najlepiej aby DB, które służą do wymiany danych były takie same w dwóch sterownikach – czyli miały taką samą strukturę i wielkość. Nie jest to konieczne, ale lepiej zachować pewien porządek. Jeśli DB zostaną stworzone w jednym ze sterowników, to można je przekopiować do drugiego. Dobrą praktyką jest stworzenie rezerw, które można wykorzystać jeśli program np. zostanie rozbudowany. Poniżej przykładowe DB.
- Instrukcja PUT – (wysyłanie danych do sterownika – partnera). Wysyłanie danych jest aktywowane przez zegar z okresem 1 sek. Komunikacja jest aktywowana zboczem dodatnim REQ_PUT – jeśli jest stan wysoki impulsu 1Hz i nie jest aktywny inny proces komunikacyjny. Sygnał REQ_PUT jest kasowany, gdy komunikacja zgłosi błąd lub zostanie zakończona prawidłowo (DONE) – Network 1. Poniżej znajduje się instrukcja PUT do wysłania danych znajdujących się w bloku danych DB10 – SD_1 (zostaje wysłanych 2 wordy bloku DB10 od adresu 0.0). Miejsce zapisu danych w sterowniku partnerze ADDR_1 – również to DB10.DBX0.0, 2 wordy.
- Instrukcja GET – (odbiór danych ze sterownika-partnera). Obiór danych jest aktywowany zboczem dodatnim sygnału REQ_GET – gdy wysyłanie danych zostało zakończone (sygnał REQ_PUT). Sygnał REQ_GET jest kasowany, gdy komunikacja zgłosi błąd lub zostanie zakończony obiór danych (NDR) – Network 3. Poniżej znajduje się instrukcja GET do odbierania danych do bloku danych DB11 – RD_1 (zostaje odebranych 2 wordy bloku DB11 od adresu 0.0). Miejsce odczytu danych w sterowniku partnerze ADDR_1 – również to DB11.DBX0.0, 2 wordy.
Interfejsy bloków funkcyjnych PUT/GET:
- REQ – aktywacja procesu wysyłania lub obioru danych.
- ID – numer identyfikacyjny komunikacji (z konfiguracji połączenia).
- ADDR_1 – wskaźnik do DB partnera służące do zapisu lub odczytu danych. Jest to wskaźnik na obszar danych – zapis P#DB11.DBX0.0 WORD 2 oznacza odniesie się do bloku DB11 sterownika partnera, od adresu 0.0 do 2.0 (WORD 2). Jeśli komunikacja dotyczyła dwóch bajtów, to można zapisać P#DB11.DBX0.0 BYTE 2 itp.
- SD_1/RD_1 – wskaźnik do DB lokalnego, służący do zapisu lub odczytu danych. Jest to wskaźnik na obszar danych – zapis P#DB11.DBX0.0 WORD 2 oznacza odniesie się do bloku DB11 sterownika lokalnego od adresu 0.0 do 2.0 (WORD 2). Jeśli komunikacja dotyczyła dwóch bajtów to można zapisać P#DB11.DBX0.0 BYTE 2 itp.
- Odczyt lub zapisu wartości w DB np. z offsetem dwóch bajtów (1 word) to wskaźnik należy zapisać – P#DB11.DBX2.0 BYTE 2 – odczyt DB11 od adresu DBX2.0.
- DONE/NDR – wyjście informujące od zakończonym procesie wysyłania/obioru.
- ERROR – błąd komunikacji, sygnalizacja sygnałem 1.
- STATUS – informacja o stanie komunikacji.
W sterownikach należy dodać program do diagnostyki komunikacji i do obsługi wykrycia jej braku np. wyzerowanie bloku danych DB obioru danych.
3. Komunikacja PUT/GET – dla sterowników S7-1500, S7-1200 umieszczonych w dwóch projektach
Jeśli sterowniki są w dwóch różnych projektach to również można taką komunikację wykonać w prosty sposób. Jest to częsta sytuacja gdy zostaje dodana nowa maszyna lub część instalacji, do której jest osobny program i należy przesłać dane do istniejącego programu instalacji.
Gdy zostanie dodany bloku funkcyjny GET lub PUT, można stworzyć nowe połączenie komunikacyjne przez właściwości bloku funkcyjnego.
W polu Partner należy wybrać Unspecified.
W Polu Address należy wpisać adres IP sterownika partnera.
Zostanie utworzone połączenie S7-connection, które trzeba przesłać do sterownika.
Program do obsługi komunikacji za pomocą bloków funkcyjnych PUT/GET jest identyczny jak w przykładzie dla sterowników znajdujących się w tym samych projekcie.
Po przesłaniu programu do sterowników, należy przetestować wymianę danych. Należy sprawdzić:
- jakie są opóźnienia w przesyłaniu danych – jeśli opóźnienia w wymianie danych nie są zadowalające, to należy przyśpieszyć komunikację,
- czy dane są przesyłane prawidłowe,
- czy przy wymianie danych między sterownikami różnych producentów nie są zamienione bajty w słowach,
- działanie watchdogów,
- jak zachowuje się komunikacja gdy jeden ze sterowników przejdzie w tryb stop.
4. Podsumowanie
Komunikacja PUT/GET jest łatwa i szybka do wykonania. Jest bardzo przydatna w sytuacjach gdy dodany zostaje nowy sterownik do istniejącej już instalacji. Posiada jednak dużo ograniczeń i wymaga od programisty zadbania o prawidłowe wywołanie bloków funkcyjnych oraz obsługi zdarzeń przy utracie komunikacji, ponieważ jej brak może to doprowadzić do nieprawidłowego zachowania urządzeń.
Jeśli posiadamy dostępne projekty sterowników, między którymi ma być dostępna komunikacja, lepiej wykonać komunikację dwustronną opartą na blokach funkcyjnych TSEND_C i TRCV_C (została dobrze opisana w jednym z wcześniejszych artykułów konkursowych).
W kolejnym z artykułów postaram się przetestować komunikację ze sterownikami S7-300/400, które są nadal popularne i często stosowane w automatyce przemysłowej.
  Artykuł został nagrodzony w Konkursie iAutomatyka – edycja Marzec 2019
Nagrodę Voucher na szkolenie w EMT-SYSTEMS dostarcza ambasador konkursu, firma EMT-SYSTEMS. |
