SIMATIC S7-1500T - Technologia Motion Control od strony praktycznej

STEROWANIE NAPĘDEM

W premierowej publikacji cyklu zajmiemy się omówieniem podstawowych zagadnień związanych ze sterowaniem ruchem, czyli problematyką Motion Control. Pierwszym zagadnieniem, które zostanie krótko omówione, jest struktura sterowania systemami napędowymi.

W zależności od wymagań aplikacji napędowej, sterowanie - zadawanie prędkości, pozycjonowanie, bazowanie systemu, etc., możemy realizować po stronie samego napędu lub wysyłać komendy przez nadrzędny system sterowania.

Na początku zastanówmy się, jakie są cechy tych dwóch struktur systemu w odniesieniu do oczekiwań projektowych, możliwości konfiguracyjnych czy funkcjonalności samej aplikacji.

STEROWANIE LOKALNE (NAPĘD)

Rys. 1.

Zastosowanie odpowiedniej klasy napędu SINAMICS daje różne możliwości w zakresie sterowania lokalnego. Przy prostych napędach dla silników indukcyjnych możemy uruchomić napęd z poziomu panelu sterowniczego i sterować pojedynczą osią z odpowiednimi parametrami ruchu. Przy bardziej zaawansowanych napędach możemy zmieniać większą liczbę parametrów oraz nadać ich pracy prostą logikę.

W przypadku napędów serwo pojawia się nieco więcej możliwości - już w prostych rozwiązaniach możemy zaprogramować bezpośrednio w napędzie chociażby funkcje sterowania prędkością, pozycjonowania czy bazowania systemu. Serwonapędy z wyższej półki pozwolą na stworzenie zaawansowanej logiki, wręcz programu sterowania przez dedykowane napędom narzędzia inżynierskie.

Wiemy zatem, że zależnie od wybranego rozwiązania napędowego istnieją mniej lub bardziej zaawansowane możliwości sterowania lokalnego. Pytanie zatem, jakie zalety bądź wady niesie za sobą takie podejście do realizacji funkcji sterowania napędami.

Przede wszystkim należy myśleć o aplikacji, którą realizujemy. Trudno będzie mówić o wadach sterowania lokalnego przy zastosowaniu np. napędu SINAMICS V20 w piekarni do wyrabiania ciasta. Proste rozwiązanie do prostej aplikacji - niski koszt napędu, prosta obsługa lokalna, brak konieczności tworzenia jakiejkolwiek logiki programu.

Przy bardziej zaawansowanych aplikacjach, gdzie będziemy musieli zrealizować funkcje serwo - przykładowo synchronizm osi czy też sprzężenia krzywkowe - możemy rozważyć napęd SINAMICS S120, który pozwoli wykonać całą logikę wewnątrz napędu przez język programowania DCC (Drive Control Chart). Aplikacje typu piła latająca, nóż obrotowy czy obsługa prasy jest do zrealizowania z wykorzystaniem jedynie tego napędu.

W takim rozwiązaniu zyskujemy z pewnością dużą dokładność ze względu na to, że realizacja funkcji pozycjonowania w napędzie działa bardzo szybko i nie wymaga wymiany informacji przez magistralę komunikacyjną z systemem nadrzędnym. Z drugiej jednak strony wymagana jest znajomość dedykowanego (licencjonowanego) środowiska inżynierskiego, koszt napędu jest dosyć wysoki, a obsługa wielu osi możliwa jest tylko przez napędy z górnej półki. Może okazać się, że zastosowanie prostszych napędów ze sterownikiem nadrzędnym będzie wygodniejsze oraz tańsza.

Dochodzą tutaj również kwestie diagnostyki, które są ograniczone w porównaniu do rozwiązania ze sterowaniem scentralizowanym (np. ograniczony dostęp do wartości zmiennych). Można sobie również wyobrazić sytuację, gdzie napęd ulega uszkodzeniu, a wraz z nim całość projektu oraz nastaw. Przy rozwiązaniu lokalnym wymagane będzie odtworzenie oraz parametryzacja napędu od początku, przy strukturze scentralizowanej wszystkie informacje przechowywane są w sterowniku PLC.

STRUKTURA SCENTRALIZOWANA (PLC)

Zastosowanie systemu nadrzędnego daje wiele zalet, ale w przypadku sporej części aplikacji będzie po prostu zbędnym kosztem lub okaże się przerostem funkcjonalnym. Z pewnością przy wspomnianych w poprzednim rozdziale prostych aplikacjach, gdzie logika sterowania nie jest wymagana - nie ma sensu stosować nadrzędnego sterownika. W przypadku aplikacji bardziej zaawansowanych, gdzie występuje sterowanie zależne wieloma silnikami indukcyjnymi lub mechanizmy serwo - można już rozważać system nadrzędny. Zdecydowana większość takich aplikacji realizowana jest właśnie w takiej strukturze.

Zyskujemy tutaj przede wszystkim transparentność systemu - konfiguracja napędów w spójnym środowisku inżynierskim razem z programem sterowania oraz urządzeniami HMI daje bardzo dużą elastyczność, standard programistyczny oraz zdecydowanie więcej możliwości - zarówno jeśli chodzi o kwestie funkcyjne, jak i diagnostyczne. Warto również wspomnieć, iż systemy zintegrowane Motion Control (Simatic + Sinamics) oprogramowane są przez tzw. obiekty technologiczne czyli przez zmapowanie fizycznego obiektu do sterownika.

Jest to bardzo wygodny mechanizm, gdyż wszystkie parametry oraz funkcje sterujące realizujemy na odwzorowanym w PLC napędzie z uwzględnieniem zastosowanej mechaniki. Wszystkie etapy konfiguracji wykonujemy tutaj w jednym spójnym środowisku inżynierskim. Więcej o obiektach technologicznych w kolejnej publikacji z cyklu. Prostota obsługi oraz centralna lokalizacja konfiguracji systemu jest również kluczowa we wspomnianym wcześniej przypadku krytycznym, gdzie napęd ulega awarii.

Zadania napędów serwo jesteśmy w stanie zrealizować na systemach z niższej półki, zyskując taką samą jakość i dokładność. Można ewentualnie zastanowić się nad mechanizmami pozycjonowania, gdzie najwyższą dokładność oraz prędkość uzyskamy realizując pętlę kontroli pozycji bezpośrednio w napędzie. Biorąc jednak pod uwagę obsługę trybu izochronicznego (IRT, o którym więcej w dalszej części dokumentu) - przykładowo w systemie, gdzie masterem będzie jednostka centralna z rodziny S7-1500, natomiast napędem Sinamics V90 - okazuje się, że różnica w dokładności ma znaczenie tylko w niewielkiej ilości bardzo specyficznych aplikacji.

Przy aplikacjach niewymagających wysokiej dokładności możemy zastosować inne magistrale komunikacyjne (np. Modbus lub USS) lub wydawać polecenia bezpośrednio przez sygnały I/O zintegrowane napędzie, co zminimalizuje koszt aplikacji.

PODSUMOWANIE

Można stwierdzić, że wybór struktury systemu zawsze zależny jest od wymogów aplikacji. W zdecydowanej jednak większości przypadków wygodniej, a być może i taniej będzie zrealizować aplikację w strukturze scentralizowanej. Taka struktura daje największą elastyczność oraz możliwości integracji systemów napędowych różnej klasy. Obsługa całościowa projektu staje się prosta, począwszy od konfiguracji, przez programowanie, a kończąc na diagnostyce.

KOMUNIKACJA NAPĘD-STEROWNIK

PROTOKOŁY KOMUNIKACYJNE

Rys. 2.

Nasza struktura systemu proponuje napęd zarządzany przez kontroler nadrzędny. Zastanówmy się, jakie mamy do dyspozycji metody wymiany informacji pomiędzy jednostką nadrzędną a napędem.

Podchodząc do zagadnienia komunikacji w układzie napęd-sterownik bardzo ogólnie, mamy do dyspozycji magistralę komunikacyjną lub w przypadkach uproszczonych - komunikację przez sygnały I/O. W tym drugim wariancie istnieje możliwość połączenia napędu z systemem sterowania interfejsem elektrycznym - gdzie polecenia do napędu wydawane będą przez sygnały aktywujące.

Jeśli jednak system będzie wyposażony w standard komunikacyjny w postaci protokołu wymiany danych, najczęściej spotkamy:

• PROFIBUS DP,
• PROFINET,
• EtherNet/IP,
• USS,
• Modbus RTU,
• CANopen.

W zależności od wymagań aplikacji - dostępnego interfejsu, oczekiwanej prędkości wymiany danych czy norm zakładowych - dobieramy konfigurację interfejsów PLC oraz napędu. Najbardziej pożądanym standardem, zwłaszcza w przypadku aplikacji szybkich, jest PROFINET. Standard jest nie tylko najbardziej wydajną drogą wymiany danych, ale również jest bardzo łatwy w konfiguracji oraz obsłudze.

Dodatkowo w przypadku aplikacji, gdzie prędkość oraz synchronizacja odczytu/zapisu informacji jest kluczowa, wspiera on mechanizmy deterministyczne PROFINET RT (real-time) oraz IRT (isochronous real-time).

W zależności od protokołu komunikacyjnego sterownik będzie wysyłał do oraz odbierał informacje z napędu przez tzw. słowa sterujące oraz statusowe.

W większości aplikacji komunikujących się przez PROFINET lub PROFIBUS kwestia przesyłanych wartości parametrów będzie sprowadzała się do ustandaryzowanych struktur wymiany informacji - napędy oraz enkodery komunikują się przez tzw. ramki PROFIdrive (niezależny standard opracowany przez organizację PI International - www.profibus.com - dla sieci PROFINET IO oraz PROFIBUS DP).

TELEGRAMY PROFIDRIVE

Rys. 3.

Sterownik wysyła do napędu komendy sterujące, wartości zadane oraz inne parametry określone przez funkcje programu użytkownika. Napęd z kolei zwrotnie dostarcza m.in. informacji statusowych oraz wartości aktualnego położenia.

W zależności od konfiguracji systemu oraz ilości informacji potrzebnych w programie użytkownika dobierzemy odpowiednią ramkę komunikacyjną PROFIDrive.

Poniższa tabela prezentuje charakterystykę doboru odpowiedniej ramki komunikacyjnej. Najczęściej stosowane to telegramy standardowe 1, 2, 3 oraz 5.

Przenosząc powyższe informacjena strukturę systemu, możemystwierdzić powiązania pomiędzy konfiguracją a wyborem odpowiedniego telegramu - zgodnie z rys.3.

Siemens proponuje do swoich systemów Motion Control rozszerzone telegramy PROFIDrive. Przykładowo standardowe telegramy 3/4/5 mają odnośnik w formie telegramów Siemens 102/103/105. Różnica polega na tym, że telegramy rozbudowane są o dwa dodatkowe bajty przewidziane na funkcje monitorowania siły/momentu obrotowego, np. przy realizacji zadania Fixed stop detection, które pozwala na bezbłędne zatrzymanie obrotu osi w chwili wykrycia określonego poziomu momentu obrotowego.

TRYB IZOCHRONICZNY CZASU RZECZYWISTEGO (IRT)

Rys. 4.

Wymiana informacji pomiędzy napędem a sterownikiem nadrzędnym odbywa się dwoma kanałami:

• Kanał cykliczny - zachodzi tutaj izochroniczna wymiana danych procesowych przez ramki PROFIDrive (obiekt technologiczny) - sterownik wysyła słowa sterujące oraz wartości zadane, natomiast od napędu odbiera słowa statusowe oraz wartości aktualne. Wymiana małych ilości informacji w jednym cyklu programu.
• Kanał acykliczny - zapewnia dostęp do parametrów napędu (odczyt/zapis) przez środowisko inżynierskie lub przez funkcje z biblioteki systemowej (LAcycCom). W tym wypadku wymiana dużej ilości informacji przez kilka cykli programu.

Wymiana danych w trybie Real-Time (RT)

W zakresie sieci PROFINET IO komunikacja (wymiana danych procesowych czy komunikatów alarmowych) zawsze odbywa się w trybie czasu rzeczywistego.

Tryb Real-Time pozwala na przyspieszenie wymiany informacji pomiędzy urządzeniami produkcyjnymi dzięki odrębnej warstwie komunikacyjnej - niezależnej od protokołów internetowych czy UPD(TCP)/IP - dane RT mają wyższy priorytet. Komunikacja urządzeń rozproszonych w trybie RT zapewnia deterministyczną wymianę istotnych informacji (odczyt i zapis informacji w ściśle określonym czasie) w cyklach kilkumilisekundowych.

Krokiem dalej jest zastosowanie trybu izochronicznego Real-Time, co daje jeszcze więcej możliwości w zakresie prędkości komunikacyjnej dla danych procesowych, a także zaawansowanych mechanizmów harmonogramu wymiany informacji przez zarezerwowane pasma komunikacyjne.

Tryb IRT

Rys. 5.

W sieci Profinet IO oraz Profibus DP istnieje możliwość konfiguracji trybu izochronicznego, czyli wymiany danych w czasie rzeczywistym - o ściśle określonym i wysoce powtarzalnym czasie cyklu. W wielu aplikacjach krytycznych czasowo konieczne jest, aby parametry zależne względem siebie, a pochodzące z różnych źródeł, zostały przetworzone w jednym cyklu programu sterownika. Przykładowo:

• równoczesny odczyt wielu wartości pomiarowych z niezależnych modułów wejść,
• wykonanie programu sterowania w sterowniku S7-1500, gdzie odczyt wartości mierzonych oraz sygnały wyjściowe pochodzą z różnych modułów,
• skoordynowane sterowanie napędami przez funkcje systemowe sterownika S7-1500.

Przykładem może być system precyzyjnego mierzenia wartości pozycji na wałku krzywkowym - gdzie mierzone odchylenia na poszczególnych krzywkach oraz kąt obrotu wału muszą być odczytane przez różne moduły w tym samym czasie i przetworzone/porównane w tym samym cyklu programu.

Rys. 6.

Zastosowanie trybu izochronicznego w sterowniku Simatic pozwoli na odczyt wartości w tym samym czasie. Rozproszone moduły I/O zbiorą informacje w tym samym momencie i dostarczą je do nadrzędnej jednostki CPU w określonym przedziale czasu. Odpowiedź systemu na otrzymane informacje zostanie wysłana w podobny sposób. Poniższy diagram pokazuje mechanizm przesyłania informacji w trybie izochronicznym.

Izochroniczna wymiana danych daje pewność, że wszystkie wartości pomiarowe zostaną odczytane z procesu w określonym czasie Ti, zanim zostaną przetransferowane przez magistralę komunikacyjną, oraz w zdefiniowanym czasie To zostaną przesłane do procesu po transferze zwrotnym.

Czasy Ti oraz To mogą zostać obliczone przez TIA Portal automatycznie w zależności od liczby modułów izochronicznych w każdej ze stacji rozproszonych I/O. Czasy te można również ustawić statycznie dla każdej ze stacji pomiarowych, co jest zdecydowanie zalecane w przypadku, gdy wartości pomiarowe pochodzą z wielu źródeł.

Uwaga

W przypadku sterowników z rodziny S7-1500 tryb izochroniczny wspierany jest przez jednostkę centralną w połączeniu z systemem rozproszonych wejść/wejść ET200. Centralna konfiguracja sterownika S7-1500 (moduły I/O podłączone bezpośrednio do CPU) nie pozwala na konfigurację trybu izochronicznego - nie wspiera go wewnętrzna magistrala komunikacyjna sterowników S7-1500.

Moduły rozproszonych systemów I/O mogą być podłączone do CPU sterownika nadrzędnego przez PROFIBUS lub PROFINET. Trzeba się również upewnić, że moduł interfejsu stacji rozproszonej wspiera tryb IRT.

Należy także pamiętać, że w celu poprawnej konfiguracji sieci PROFINET IO pracującej w trybie IRT, komponenty pośredniczące w wymianie informacji również muszą obsługiwać komunikację izochroniczną. Zwłaszcza istotne jest to w przypadku switchy ethernetowych, które są standardowymi komponentami konfiguracji sieci przemysłowych. W zakresie rodziny SCALANCE znajdziemy wiele komponentów, które możemy zastosować w sieci PROFINET IO IRT, np. seria XB200 IRT.

CO DALEJ?

W kolejnej publikacji z serii zajmiemy się szczegółowym omówieniem struktury systemu sterowania nadrzędnego oraz funkcjami Motion Control, przedstawimy podejście do obiektów technologicznych od strony programowej sterownika, a także scharakteryzujemy specyfikę systemu pozycjonowania serwonapędu.

Zapraszamy do lektury kolejnych publikacji!

Siemens
www.automatyka.siemens.pl