Sterowniki silników z komunikacją Ethernet: protokoły, integracja i wybór

Dlaczego Ethernet zastąpił starszą magistralę polową w sterowaniu silnikami

Przez dwie dekady protokoły oparte na RS-485, takie jak Modbus RTU i CANopen, zdominowały komunikację w zakresie sterowania silnikami. Były niezawodne, deterministyczne i tanie w realizacji. Były także powolne, miały ograniczoną topologię i były coraz bardziej niezgodne z wymaganiami nowoczesnych zautomatyzowanych linii produkcyjnych w zakresie danych. Przejście na Ethernet przemysłowy nie było spowodowane modą – kierowała nim matematyka.

Starsze systemy magistrali polowej zazwyczaj działają z szybkością 1–12 Mb/s w topologiach sieci, które ograniczają się do kilkudziesięciu węzłów, zanim wydajność ulegnie pogorszeniu. Protokoły Ethernetu przemysłowego działają z szybkością od 100 Mb/s do 1 Gb/s, obsługują setki węzłów w jednym segmencie sieci i zapewniają czasy cykli poniżej milisekundy, których wymaga wieloosiowa koordynacja ruchu. Według raportu HMS Networks dotyczącego udziałów w rynku sieci przemysłowych za rok 2025: 79% nowych węzłów automatyki przemysłowej jest obecnie dostarczanych z protokołem Ethernetu przemysłowego zamiast tradycyjnej magistrali polowej – co dziesięć lat temu wydawałoby się nieprawdopodobne.

Dla projektantów sterowników silników i integratorów systemów to przejście ma bezpośrednie konsekwencje praktyczne: interfejs komunikacyjny nie jest już specyfikacją drugorzędną. Określa, co sterownik może zrobić w skoordynowanym systemie napędowym, w jaki sposób integruje się ze sterownikami PLC i interfejsami HMI oraz czy może uczestniczyć w potokach danych IIoT bez bramy pośredniczącej. Bezszczotkowe sterowniki silników prądu stałego do przemysłowych zastosowań B2B Coraz częściej interfejsy Ethernet są oferowane w standardzie, a nie jako opcjonalny dodatek – co odzwierciedla to, jak głęboko zmiana protokołu przeniknęła rynek napędów.

Kluczowe protokoły Ethernetu przemysłowego dla sterowników silników

Cztery protokoły stanowią przeważającą większość instalacji sterowania silnikami podłączonych do sieci Ethernet na całym świecie. Każdy z nich stosuje inne podejście architektoniczne do tego samego podstawowego wyzwania: niezawodnego i przewidywalnego przesyłania danych sterujących za pośrednictwem standardowego sprzętu Ethernet.

EtherCAT (Ethernet dla technologii automatyzacji sterowania) został opracowany przez firmę Beckhoff Automation i stał się standardem IEC w 2005 r. Jego innowacją definiującą jest „przetwarzanie w locie”: zamiast odbierania przez każdy węzeł dedykowanego pakietu, pojedyncza ramka EtherCAT krąży po kolei przez wszystkie węzły podrzędne, przy czym każdy węzeł odczytuje własne dane i wstawia dane odpowiedzi w miarę upływu ramki. Eliminuje to obciążenie związane z przełączaniem pakietów i zapewnia czasy cykli poniżej 100 mikrosekund z jitterem poniżej 1 mikrosekundy – wydajność, która sprawia, że ​​synchronizacja dziesiątek osi serwo jest naprawdę możliwa. The Oficjalna dokumentacja techniczna EtherCAT Technology Group szczegółowo opisuje, w jaki sposób protokół zapewnia zgodność z normą IEC 61158, jednocześnie obsługując topologie linii, drzewa, gwiazdy i pierścienia bez przełączników zarządzanych.

PROFINET , zarządzana przez PROFIBUS & PROFINET International (PI), jest bezpośrednim następcą Profibus i dominuje na europejskich rynkach przemysłowych. Działa w dwóch trybach: PROFINET RT (czas rzeczywisty) z czasami cykli od 1 do 10 milisekund dla standardowych aplikacji we/wy oraz PROFINET IRT (czas izochroniczny w czasie rzeczywistym) z czasami cykli zaledwie 250 mikrosekund dla precyzyjnego sterowania ruchem. Kluczową zaletą projektów modernizacyjnych jest natywna obsługa proxy Profibus – istniejące urządzenia Profibus mogą komunikować się w sieci PROFINET za pośrednictwem bramek proxy, umożliwiając stopniową migrację bez wymiany zainstalowanego sprzętu.

Sieć Ethernet/IP , utrzymywany przez ODVA i zbudowany w oparciu o protokół Common Industrial Protokół (CIP) nałożony na standardowe protokoły TCP/IP i UDP/IP, jest dominującym protokołem w produkcji dyskretnej w Ameryce Północnej. Działając w oparciu o konwencjonalną infrastrukturę IT bez specjalistycznych przełączników, zapewnia prostą integrację z istniejącymi sieciami zakładowymi i obsługuje szeroki ekosystem sterowników PLC, napędów i modułów we/wy pochodzących od wielu dostawców. Typowe czasy cykli wynoszące 2–10 milisekund są odpowiednie dla większości dyskretnych zastosowań we/wy i napędów o umiarkowanej prędkości; ściślejsza synchronizacja jest dostępna poprzez rozszerzenie CIPsync.

Modbus TCP to najprostsza i najczęściej obsługiwana opcja – bezpośrednie tłumaczenie klasycznego modelu rejestru Modbus RTU na protokół TCP/IP. Nie posiada natywnych gwarancji czasu rzeczywistego, co dyskwalifikuje go z wymagających ról w sterowaniu ruchem, ale uniwersalna obsługa urządzeń i zerowy koszt licencji sprawiają, że jest praktycznym wyborem dla warstw monitorowania, konfiguracji i rejestrowania danych, gdzie nie jest wymagany determinizm.

Porównanie protokołów: czas cyklu, topologia i kompatybilność

Wybór jednego z tych protokołów wymaga dopasowania charakterystyki protokołu do wymagań aplikacji, a nie wybierania domyślnego tego, który jest najbardziej znany. Poniższa tabela podsumowuje najważniejsze wyróżniki czterech głównych opcji:

Dane wyróżniają się jednym wzorcem: przewaga czasu cyklu EtherCAT nie jest marginalna — jest o rząd wielkości szybsza niż EtherNet/IP w równoważnych warunkach. W zastosowaniach wymagających ścisłej synchronizacji wielu osi silnika, takich jak obrabiarki CNC, ramiona robotów lub skoordynowane systemy przenośników, luka ta przekłada się bezpośrednio na dokładność pozycjonowania. W przypadku napędów jednoosiowych w standardowym sprzęcie procesowym różnica rzadko ma znaczenie w praktyce, a znajomość i kompatybilność infrastruktury EtherNet/IP lub PROFINET RT często przewyższają samą prędkość.

Topologia sieci ma również znaczenie praktyczne. Architektura łańcuchowa EtherCAT eliminuje potrzebę stosowania przełączników zarządzanych, redukując zarówno przestrzeń w szafie, jak i koszty w systemach z wieloma rozproszonymi węzłami dyskowymi. Wymagania PROFINET IRT dotyczące przełączników obsługujących synchronizację zwiększają koszty infrastruktury, ale umożliwiają synchronizację zegara w geograficznie rozproszonych węzłach, czego nie jest w stanie łatwo obsłużyć liniowa topologia EtherCAT.

Integracja komunikacji Ethernet ze sterownikami silników BLDC

Dodanie interfejsu Ethernet do bezszczotkowego sterownika silnika prądu stałego wymaga decyzji na trzech poziomach: sprzętu fizycznego, oprogramowania sprzętowego stosu komunikacyjnego i implementacji profilu napędu w warstwie aplikacji.

Na poziomie sprzętowym integracja EtherCAT zazwyczaj opiera się na dedykowanych układach ASIC kontrolerów podrzędnych — takich jak rodziny ET1100 lub ESC10 — które obsługują przetwarzanie ramek niezależnie od głównego MCU. To odciążenie umożliwia uzyskanie czasów cykli krótszych niż 100 mikrosekund: przetwarzanie w sieci Ethernet nigdy nie konkuruje o cykle procesora z pętlą sterowania silnikiem. Implementacje PROFINET i EtherNet/IP częściej wykorzystują dwuportowe moduły RAM lub implementacje z miękkim rdzeniem na układach FPGA, które oferują większą elastyczność, ale wymagają dokładniejszego zarządzania opóźnieniami w architekturze oprogramowania sprzętowego.

Na poziomie oprogramowania sprzętowego profil napędu określa, w jaki sposób polecenia sterujące silnikiem są mapowane na protokół sieciowy. Profil napędu CiA 402 — pierwotnie opracowany dla CANopen — stał się dominującym standardem warstwy aplikacji dla napędów silnikowych w implementacjach EtherCAT (poprzez CoE, CANopen przez EtherCAT), PROFINET i EtherNet/IP. Definiuje maszyny stanu dla włączania/wyłączania napędu, trybów pracy (pozycja, prędkość, moment obrotowy) i obsługi błędów w sposób neutralny dla dostawcy, co upraszcza programowanie sterowników PLC różnych marek. Sterowniki prawidłowo implementujące CiA 402 można zazwyczaj uruchomić z dowolnym sterownikiem PLC zgodnym z IEC 61131-3 bez niestandardowych bloków funkcyjnych.

W przypadku skoordynowanych systemów wieloosiowych kluczową funkcją oprogramowania sprzętowego jest synchronizacja rozproszonego zegara. Mechanizm rozproszonych zegarów EtherCAT synchronizuje wszystkie węzły podrzędne z dokładnością do 1 mikrosekundy – jest to warunek wstępny dla elektronicznej przekładni, profilowania krzywek i innych funkcji zsynchronizowanego ruchu. Prawidłowe wdrożenie tego wymaga zwrócenia szczególnej uwagi na kompensację opóźnienia propagacji i korektę dryftu zegara w oprogramowaniu urządzenia podrzędnego. Wysokowydajne sterowniki silników serii T uwzględniają architekturę przetwarzania niezbędną do utrzymania niewielkiej częstotliwości aktualizacji pętli prądowej wraz z obsługą komunikacji sieciowej – równowaga, którą często zagrażają podstawowe projekty kontrolerów.

Oprócz samych sterowników napędów, integracja komunikacji na poziomie systemu obejmuje także jednostki nadzorcze. Jednostki sterujące pojazdem ze zintegrowaną komunikacją sieciową agreguj dane napędów z wielu sterowników silników, zarządzaj maszynami stanu na poziomie systemu i udostępniaj nadrzędną bramę Ethernet na potrzeby telematyki i zdalnej diagnostyki — funkcja, która staje się coraz ważniejsza w miarę przesuwania się floty i sprzętu przemysłowego w stronę modeli konserwacji predykcyjnej. Do lżejszych zastosowań w pojazdach elektrycznych i rowerach elektrycznych, sterowniki rowerów elektrycznych i lekkich silników EV coraz częściej wykorzystują interfejsy Bluetooth i CAN jako warstwę komunikacyjną, służąc jako pomost pomiędzy uproszczonymi interfejsami użytkownika a podstawową pętlą napędu silnikowego.

Wybór odpowiedniego protokołu dla aplikacji sterowania silnikiem

Wybór protokołu rzadko sprowadza się do jednego czynnika. Sześć pytań obejmuje praktyczną przestrzeń decyzyjną dla większości projektów systemów sterowania silnikami:

1. Jakiego czasu cyklu wymaga aplikacja ruchu? Koordynacja serwonapędów wieloosiowych zazwyczaj wymaga czasów cykli poniżej 1 milisekundy – co wskazuje na EtherCAT lub PROFINET IRT. Jednoosiowe napędy o zmiennej prędkości w sprzęcie procesowym zazwyczaj działają komfortowo przy szybkości aktualizacji 5–10 milisekund, gdzie EtherNet/IP lub PROFINET RT działają odpowiednio.
2. Jaki sterownik PLC lub ruch jest już w systemie? Często jest to czynnik decydujący. Kontrolery Siemens S7 preferują PROFINET; Systemy Rockwell/Allen-Bradley zbudowane są w oparciu o sieć EtherNet/IP; Platformy ruchu Beckhoff i Omron standaryzują technologię EtherCAT. Przekraczanie granic protokołów jest możliwe za pośrednictwem bram, ale zwiększa opóźnienia i złożoność, co pogarsza przewagę wydajności protokołu natywnego.
3. Ile osi napędowych będzie obsługiwać sieć? Teoretyczny limit węzłów EtherCAT wynoszący 65 535 urządzeń w jednej sieci znacznie przekracza jakąkolwiek realistyczną instalację, ale topologia połączenia łańcuchowego oznacza, że ​​dodanie węzłów nieznacznie wydłuża czas przechodzenia ramki. W przypadku bardzo dużych instalacji z setkami rozproszonych punktów we/wy, topologia gwiazdy oparta na przełącznikach PROFINET może oferować bardziej elastyczny układ fizyczny.
4. Czy w warstwie sieciowej wymagane jest bezpieczeństwo funkcjonalne? Zarówno EtherCAT (przez FSoE, Functional Safety over EtherCAT), jak i PROFINET (przez PROFIsafe) obsługują komunikację bezpieczeństwa zgodną z IEC 61508 za pośrednictwem tej samej infrastruktury kablowej, co standardowe dane procesowe. EtherNet/IP obsługuje bezpieczeństwo CIP dla równoważnych zastosowań. Jeśli wymagane są funkcje bezpiecznego wyłączania momentu lub bezpiecznej prędkości SIL 2 lub SIL 3, należy sprawdzić, czy oprogramowanie sprzętowe sterownika silnika jest certyfikowane dla rozszerzenia bezpieczeństwa wybranego protokołu.
5. Jakie są ograniczenia infrastrukturalne i konserwacyjne? Eliminacja przełączników zarządzanych w EtherCAT upraszcza konstrukcję szafy i zmniejsza liczbę punktów awarii. PROFINET i EtherNet/IP wykorzystują standardową infrastrukturę przełączników IT, którą zespoły utrzymania ruchu mogą już zarządzać i przechowywać części zamienne – to praktyczna zaleta w obiektach bez specjalistycznej wiedzy w zakresie sieci automatyki.
6. W jaki sposób kontroler paruje się z docelowym silnikiem? Protokół komunikacyjny i dopasowanie silnika są od siebie zależne: sterownik zoptymalizowany pod kątem komunikacji sieciowej o dużej przepustowości musi także obsługiwać częstotliwość aktualizacji pętli prądowej oraz wymagania dotyczące stałej czasowej silnika. Przeglądanie sterownik silnika i wskazówki dotyczące parowania silników przed zatwierdzeniem kombinacji kontroler-protokół należy upewnić się, że specyfikacja interfejsu sieciowego nie przekracza wydajności napędu, z której faktycznie może korzystać silnik.

Konkluzja dla zespołów zaopatrzeniowych i inżynieryjnych: właściwy protokół to taki, który pasuje do ekosystemu PLC, spełnia wymagania dotyczące czasu cyklu ruchu i pasuje do topologii instalacji – w tej kolejności. Optymalizacja pod kątem surowej szybkości protokołu w aplikacji, która jej nie potrzebuje, zwiększa koszty bez korzyści. Niedostateczne określenie aplikacji wymagającej deterministycznej synchronizacji powoduje problemy z niezawodnością, których żadne dostrojenie nie naprawi w pełni.