Ponieważ mam dostęp do testowych sterowników S7-300/400, postanowiłem zaprogramować i przetestować komunikację między kilkoma sterownikami Simatic, wykorzystując do testów fizyczne urządzenia. Poniżej znajdziesz instrukcję jak wykonać komunikację PUT/GET pomiędzy sterownikiem S7-400 i S7-300 (w Step7) a sterownikiem S7-1200 (w TIA Portal).
Zobacz też kursy online z automatyki i robotyki.
1. Komunikacja PUT/GET S7-400 i S7-1200
Do zaprogramowania S7-400 wykorzystanie zostanie środowisko Step7 Manager w wersji v5.6. Sterownik S7-400 będzie masterem komunikacji a S7-1200 slave’m, chociaż bardziej powinno używać tutaj zwrotów client i server komunikacji. Komunikacja po stronie sterownika S7-400 będzie się odbywać przez procesor CP (ponieważ CPU w tyt przykładzie nie posiada wbudowanego portu Profinet/Ethernet).
1.1. Dodanie i konfiguracja sterownika S7-400 do projektu
Sterownik zostanie skonfigurowany w środowisku Step 7 Manager. Sterownik został skonfigurowany w HWConfig, tak jak poniżej na rysunku (został dodany zasilacz, CPU, CP, nadane adresy IP).
Po skonfigurowaniu sterownika można przejść do skonfigurowania połączeń sieciowych w programie NetPro. Poniżej przedstawiono kolejne kroki dodania nowego połączenia S7-connection.
Ponieważ sterownik S7-1200 będzie skonfigurowany w TIA-Portal, to należy dodać połączenie z partnerem typu Uspecified. Kolejne pola w zakładce Properties- S7- connection:
- Establish an activ connection – aktywne;
- Partner – dowolna nazwa sterownika partnera;
- Address – adres IP sterownika partnera.
Następnie należy wybrać przycisk Address Detailst.
Pola należy wypełnić tak jak na rysunku poniżej.
Poniżej wyjaśniono, skąd należy wziąć wartości parametrów z programu TIA Portal. Wartość pola Connection Resources równa się 0x03 – oznacza to komunikację client-server.
Tak przygotowane połączenie należy skompilować i wgrać do sterownika S7-400.
Konfigurację sieciową do sterownika S7-400 można wgrać, zatrzymując sterownik (2b) lub bez jego zatrzymywania, zaznaczając wybrane połączenie i z menu kontekstowego (prawy klik) wybrać „Download selected connection” (2a, 3a).
Jeśli jest połączenie fizyczne ze sterownikiem partnerem, to można już na tym etapie zdiagnozować prawidłowość połączenia ze sterownikiem partnerem:
– brak lub konfiguracja nieprawidłowa połączenia S7_1200;
– konfiguracja prawidłowa połączenia S7_1200.
1.2. Program dla sterownika S7-400
Program dla sterownika S7-400 jest bardzo podobny do tego, który była dodawany dla sterownika S7-1200 w poprzednim artykule.
Należy stworzyć w programach bloki DB komunikacyjne- w sumie 4. Dwa bloki DB w Step 7 – blok DB do wysyłania podpięty do funkcji PUT, drugi blok DB do obioru danych podpięty do funkcji GET. Kolejne bloki danych DB należy utworzyć w programie TIA Portal dla sterownika S7-1200 (1500). Najlepiej aby DB, które służą do wysyłania danych miały taką samą strukturę w dwóch sterownikach: lokalnym i partnerze (również DB do obioru).
Jeśli DB są utworzone, w kolejnym kroku należy dodać program do sterownika S7-400. W tym sterowniku będą funkcje PUT/GET.
Przy dodawaniu bloków funkcyjnych należy zwrócić szczególną uwagę z jakiej biblioteki są one dodawane ponieważ, są one różne dla CPU S7-300, inne dla CP S7-300 i jeszcze inne dla S7-400. To, że zostały dodane złe bloki, nie zostanie wyświetlony żaden komunikach a komunikacja nie będzie działać. Poniżej przykład bloków funkcyjnych i biblioteki, która dla sterownika S7-400 jest nieprawidłowa.
Jeśli dodane zostaną prawidłowe bloki funkcyjne PUT/GET to można z menu kontekstowego, wybrać odpowiednie połączenie, wtedy prawidłowy identyfikator połączenia S7-connection zostanie wpisany jako parametr funkcji PUT/GET.
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 (tj REQ_GET). 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 DB1000 (zostaje wysłanych 1 BYTE bloku DB1000 od adresu 0.0) – parametr SD_1. Miejsce zapisu danych w sterowniku partnerze to DB10 od adresu DB10.DBX0.0 zaspis 2 BYTE- parametr ADDR_1.
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 – zostają zapisane w bloku danych sterownika lokalnego (S7-400) DB1001 (zostaje odebranych 2 BYTE bloku DB1001 od adresu 0.0) – parametr RD_1. Miejsce odczytu danych w sterowniku partnerze – DB11 od adresu DB11.DBX0.0 odczyt 2 BYTE- parametr ADDR_1. W Networku 5 diagnostyka połączenia – należy pamiętać, że jeżeli komunikacja zostanie zerwana do dane w bloku danych tj. DB1001 zostaną zatrzaśnięte. Dlatego należy w odpowiedni sposób obsłużyć brak komunikacji np. wyzerować dane w DB odbiorczym
Poniżej przykład, jeśli wymagane jest przesłanie więcej danych- funkcja PUT.
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;
- SD_1/RD_1 – wskaźnik do DB lokalnego służące do zapisu lub odczytu danych.
Na koniec należy przeprowadzić testy komunikacji.
2. Komunikacja PUT/GET S7-300 i S7-1200
Komunikacja S7-300 z S7-1200 za pomocą funkcji PUT/GET jest bardzo podobna do przedstawionej powyżej. Natomiast należy zwrócić uwagę na dwie różnice.
Został wykorzystany tutaj procesor CPU S7-315PN/DP, który ma wbudowany w procesor CP oraz został dołączony moduł z procesorem komunikacyjnym CP 343-1. Do komunikacji ze sterownikiem S7-1200 jak i programatorem można wykorzystać zarówno CPU jak i CP. Jeśli podczas konfiguracji, moduł CPU (CP wbudowane) jak i moduł CP, zostaną przyłączone do tej samej sieci, to w konfiguracji połączenia S7-connection należy zwrócić uwagę jaki interfejs został wybrany. Przy tworzeniu połączenia jest dostępna opcja wyboru jednego z dwóch dostępnych interfejsów.
Druga uwaga – w programie należy użyć odpowiednich bloków funkcyjnych PUT/GET dla odpowiedniego interfejsu.
– użycie bloków funkcyjnych z biblioteki, gdy komunikacja wykonana jest przez procesor CPU S7-315 (CP wbudowany)
– użycie bloków funkcyjnych z biblioteki, gdy komunikacja wykonana jest przez moduł CP-343-1.
Program do obsługi bloków funkcyjnych (wywołanie, interfejs i parametry bloków programowych) jest tak sam jak dla sterownika S7-400.
3. Komunikacja PUT/GET S7-1200 i S7-400
Nietrudno wyobrazić sobie sytuację odwrotną, gdy posiadamy działający sterownik S7-1200/S7-1500 i należy wykonać komunikację, która pozwalałaby na zapis lub odczyt danych ze sterownika S7-400 lub S7-300.
3.1 Dodanie i konfiguracja połączenia S7-connection w TIA Portal
W programie sterownika S7-1200 należy dodać bloki funkcyjne PUT/GET. W zakładce Properties bloku funkcyjnego można stworzyć połączenie S7-connection ze sterownikiem, który jest w innym projekcie- Unspecified.
Następnie w widoku Netword view w zakładce Connections należy wybrać utworzone połączenie i oknie Properties wybrać opcję Address detalist. Otworzy się okno, w którym należy podać parametry sterownika partnera. Dane np. dla sterownika S7-400, można odczytać z programu Step7/Hardware.
Program dla sterownika S7-1200, do obsługi komunikacji z blokami funkcyjnymi PUT/GET jest identyczny, jak dla komunikacji między sterownikami TIA Portal.
Wysyłanie danych za pomocą bloku funkcyjnego PUT (zostały zmienione tylko numery bloku DB partnera).
Odbieranie danych za pomocą bloku funkcyjnego GET i obsługa braku komunikacji.
Podsumowanie
Komunikacja PUT/GET miedzy sterownikami S7-300/400 i S7-1200/1500 również jest prosta do wykonania i nie stwarza problemów. Potrzeba na to kilku minut. Bardzo dobrze sprawdzi się w sytuacji, gdy mamy dostępny do konfiguracji tylko jeden projekt sterownika. Jednak nadal posiada swoje ograniczenia (prawidłowe wywołanie bloków funkcyjnych, obsługi zdarzeń przy utracie komunikacji, stosowanie watchdogów), dlatego najlepiej wykonać komunikację dwustronną.
Zachęcam wszystkich do próbowania zestawienia komunikacji między różnymi urządzeniami. Mogą to być oczywiście różne interfejsy i protokoły, różne urządzenia. Należy również sprawdzać co się dzieje z urządzeniami gdy komunikacja zostanie zerwana, co się stanie z urządzeniem gdy będzie w położeniu niebezpiecznym, jakie będzie zachowanie sąsiednich maszyn. Ze swojego doświadczenia wiem, że nabyta wiedza bardzo przydaje się podczas pracy i takie próby pozwolą skrócić czas potrzebny na uruchomienie maszyn oraz instalacji.
  Artykuł został nagrodzony w Konkursie iAutomatyka – edycja Kwiecień 2019
Nagrodę Bluza 4F + kubek termiczny + zestaw gadżetów dostarcza ambasador konkursu, firma Finder. |
