Artykuł sponsorowany

Komunikacja Profinet między falownikiem a Siemens S7 — dlaczego problemy częściej wynikają z parametrów niż z okablowania

Komunikacja Profinet między falownikiem a Siemens S7 — dlaczego problemy częściej wynikają z parametrów niż z okablowania

W uruchomionej linii produkcyjnej, na przykład w instalacji pomp w zakładzie spożywczym, przetwornica Danfoss FC 102 już steruje silnikiem. Integracja z PLC Siemens S7-1500 przez sieć Profinet ma na celu przejęcie przez sterownik kontroli nad startem, stopem, zadaną prędkością oraz odczytem statusu i diagnostyki. Zanim jednak PLC rozpozna falownik, musi on pojawić się w konfiguracji TIA Portal jako urządzenie IO.

Konfiguracja komunikacji Profinet – kluczowe parametry i dane

Profinet pozwala na cykliczną wymianę danych procesowych między sterownikiem PLC Siemens S7 a przetwornicą Danfoss wyposażoną w moduł MCA 120. Cały proces opiera się na prostym schemacie: sterownik S7 jako IO Controller wysyła słowo sterowania (CTW) oraz wartość zadaną (MRV), a falownik odpowiada słowem statusu (STW) i wartością aktualną (MAV). W ten sposób PLC otrzymuje informacje o prędkości czy gotowości do pracy, jednocześnie wydając polecenia startu, stopu czy zmiany kierunku obrotów. Przykładowo, w standardowym telegramie PROFIdrive bit 0 słowa sterującego odpowiada za funkcję start/stop.

Aby przetwornica danfoss fc 102 poprawnie pojawiła się w projekcie, należy najpierw zaimportować do TIA Portal odpowiedni plik konfiguracyjny GSDML. Kluczowe jest, aby parametr 12-08 (Host Name) w falowniku był identyczny z nazwą urządzenia przypisaną w projekcie TIA Portal. Równie istotne jest źródło sterowania. Parametr 8-02 (Control Word Source) musi być ustawiony na komunikację sieciową (np. Option A), a 8-10 (Control Word Profile) na standard PROFIdrive, co zapewnia zgodność z logiką sterowników Siemens. Adres IP najlepiej pozostawić do automatycznego przydziału przez sterownik (DCP).

Strukturę wymienianych danych określa wybrany telegram (parametr 9-22), a parametry 9-15 i 9-16 pozwalają zmapować konkretne sygnały na odpowiednie miejsca w telegramie. Jakiekolwiek rozbieżności w tych ustawieniach mogą sprawić, że falownik nie będzie reagował lub wyświetli błąd, np. W34 (nieprawidłowa nazwa hosta). Inżynierowie z firmy Control-Service, integrując napędy Danfoss z systemami S7 w przemyśle, często weryfikują właśnie te parametry, by zapewnić stabilną komunikację.

Mapowanie sygnałów i typowe przyczyny usterek

Mapowanie danych polega na przypisaniu sygnałów technologicznych do konkretnych zmiennych w sterowniku PLC. Wyjściu %QW0.0 w TIA Portal można przypisać słowo sterujące CTW, a wejściu %IW0.0 słowo statusu STW odczytywane z falownika. Dzięki temu logika programu sterującego może reagować na stan napędu i wysyłać polecenia. Dla operatora na panelu HMI te zmienne są prezentowane w czytelnej formie, np. jako aktualna prędkość czy kod aktywnego alarmu. Dodatkowe sygnały, takie jak moment obrotowy, można skonfigurować w parametrze 9-23.

Wbrew pozorom, problemy z komunikacją rzadko wynikają z uszkodzonego okablowania Ethernet, którego stan można łatwo zweryfikować w parametrach diagnostycznych (12-10/12-13). Najczęstsze przyczyny usterek to niespójna konfiguracja sieci (np. inna nazwa hosta w TIA i falowniku) lub niezgodność wybranego telegramu. Inne źródła błędów to nieprawidłowe skalowanie wartości zadanej i aktualnej (parametr 3-00) lub pozostawienie napędu w trybie sterowania ręcznego. Problemem bywa też niezgodna logika startu, gdy bity słowa sterującego nie są synchronizowane z logiką bezpieczeństwa lub przekroczony zostaje czas na odpowiedź (timeout).

Korekta parametrów, takich jak nazwa hosta czy źródło sterowania, często wystarcza, aby urządzenie pojawiło się w sieci i zaczęło poprawnie komunikować się ze sterownikiem. Można to zrobić bez restartu całego systemu. Jeśli jednak mimo poprawnej konfiguracji napęd reaguje nieprzewidywalnie na polecenia lub zgłasza błędy, problem leży głębiej. W takiej sytuacji należy przeanalizować logikę sterowania w programie PLC oraz sprawdzić powiązane z nią blokady i warunki bezpieczeństwa. Pełna weryfikacja całego łańcucha sygnałów, od pliku GSDML po mapowanie danych procesowych, jest kluczowa dla zminimalizowania kosztownych przestojów.