Dlaczego dane dotyczące konserwacji są niezbędne dla niezawodności przemysłowej
Dane dotyczące utrzymania ruchu łączą zlecenia prac, sygnały z czujników, historię zasobów, koszty i wiedzę techników. Właściwie wykorzystywane usprawniają p...
Sporadyczna samoczynna jazda suwaka to zdarzenie z zakresu bezpieczeństwa maszyny
Oś poruszająca się bez oczekiwanego polecenia nie jest rutynową usterką uruchomieniową. Jest to zdarzenie niekontrolowanego ruchu, które może uszkodzić narzędzia, konstrukcję maszyny, obrabiane przedmioty, oprzyrządowanie i ludzi. Ryzyko staje się trudniejsze do opanowania, gdy suwak przez wiele godzin zachowuje się prawidłowo, a następnie nagle porusza się z nieoczekiwaną prędkością lub w nieoczekiwanym kierunku.
Opisywana w tym przypadku maszyna wykorzystuje jednostkę Siemens SIMATIC S7-200 CPU 226, urządzenie SIMOVERT MASTERDRIVES do osi suwaków, przemiennik MICROMASTER 440 do wrzeciona oraz panel operatorski TP 170A. Dane dotyczące poleceń i stanu są przesyłane przez szeregową sieć komunikacyjną USS.
Zgłaszany problem występuje na jednym suwaku lub na obu. Zdarzenie może pojawić się raz lub dwa razy w ciągu dnia roboczego, po czym następują dwa lub trzy dni normalnej pracy. Wcześniejsze próby obejmowały oddzielenie przemiennika częstotliwości wrzeciona od głównej szafy sterowniczej oraz poprawę uziemienia. Działania te nie usunęły usterki.
Taki schemat często skłania do diagnostyki opartej na domysłach. Inżynierowie mogą wymienić enkoder, poprowadzić kabel inną trasą, zmienić parametr napędu lub dodać kolejny przewód uziemiający. Jedna zmiana może tymczasowo zmienić objaw, stwarzając wrażenie, że problem został rozwiązany. Zdarzenie powraca, ponieważ rzeczywista ścieżka polecenia nigdy nie została potwierdzona.
Rzetelne dochodzenie musi wskazać pierwszy moment, w którym oczekiwane zachowanie staje się nieprawidłowe. Zespół musi wiedzieć, czego zażądał panel HMI, co zaakceptował sterownik PLC, co sterownik PLC przesłał, co odebrał napęd, co napęd uruchomił wewnętrznie oraz co faktycznie zrobił silnik.
Ostrzeżenie dotyczące bezpieczeństwa: Nie kontynuuj testów produkcyjnych bez nadzoru po niekontrolowanym ruchu suwaka. Zapewnij niezależne zabezpieczenie przed przekroczeniem skoku, ogranicz dostęp, zmniejsz dostępną prędkość i siłę oraz przed rozpoczęciem diagnostyki sprawdź działanie zaprojektowanej metody zatrzymania.
Zacznij od potwierdzenia każdego zainstalowanego urządzenia
Starsze systemy firmy Siemens często pozostają w eksploatacji długo po odejściu pierwotnego zespołu odpowiedzialnego za uruchomienie. Rysunki mogą zawierać odręczne zmiany. Kopie zapasowe parametrów mogą być niekompletne. Moduły zamienne mogły zostać zamontowane bez aktualizacji dokumentacji. Dlatego identyfikacja sprzętu musi poprzedzać interpretację parametrów.
Odczytaj kompletny numer zamówienia z każdej tabliczki znamionowej. Nie polegaj wyłącznie na przepisanej liście urządzeń. Podany numer jednostki S7-200 CPU zawiera znaki, które mogły zostać skopiowane nieprawidłowo. Rzeczywisty sterownik może odpowiadać urządzeniu Siemens 6ES7216-2BD23-0XB0 SIMATIC S7-200 CPU 226, ale zasilacz i wariant wyjść należy potwierdzić bezpośrednio na zainstalowanym urządzeniu.
Pojedynczy błędny znak może prowadzić do wyboru niewłaściwej instrukcji, schematu zacisków lub części zamiennej. Litera O jest często mylona z zerem. Cyfrę jeden można pomylić z literą I. Brak przyrostka może również ukrywać istotną opcję sprzętową.
Ta sama zasada obowiązuje w przypadku urządzenia SIMOVERT MASTERDRIVES. MASTERDRIVES to szeroka rodzina urządzeń, a nie jeden stały projekt napędu. Płyty sterujące, wersje oprogramowania, opcje enkodera, płyty technologiczne oraz konfiguracje Vector Control lub Motion Control mogą zmieniać dostępne parametry i wewnętrzne trasy sygnałów.
Należy również zweryfikować numer zamówieniowy MICROMASTER 440. Chociaż MM440 steruje wrzecionem, a nie suwakami, działa w tym samym środowisku szafy i może korzystać z tej samej ścieżki komunikacji USS. Jego zdarzenia przełączania, prowadzenie kabli, konfiguracja adresów oraz czasy komunikacji mogą wpływać na działanie całego systemu.
Zapisz model TP 170A, wersję projektu HMI, ustawienia komunikacji oraz adresy podłączonego sterownika PLC. Panel może zawierać zdarzenia przycisków, funkcje receptur, wartości rozruchowe lub działanie zmiennych, których nie da się zidentyfikować wyłącznie na podstawie programu PLC.
Przed zmianą jakiegokolwiek parametru utwórz pełne kopie zapasowe programu PLC, projektu HMI, zestawu parametrów MASTERDRIVES oraz zestawu parametrów MM440. Zrób zdjęcia ekranów kabli, przełączników na płytach, połączeń zacisków oraz modułów opcjonalnych. Ta dokumentacja bazowa pozwala porównywać każdą późniejszą modyfikację i w razie potrzeby ją cofnąć.

Określ, co operatorzy rozumieją przez niekontrolowany ruch
Słowo „niekontrolowany ruch” może opisywać kilka różnych zdarzeń. Przyspieszenie do pełnej prędkości różni się od krótkiego, niezamierzonego ruchu impulsowego. Ruch podczas uruchamiania różni się od ruchu w trakcie sekwencji automatycznej. Sposób diagnostyki zależy od dokładnego charakteru zdarzenia.
Porozmawiaj z każdą osobą, która była świadkiem usterki. Pytaj o obserwacje, a nie o wnioski. „Enkoder uległ awarii” to wniosek. „Suwak szybko przesuwał się w kierunku dodatnim, podczas gdy na panelu HMI wyświetlana była prędkość zero” to obserwacja.
Zapisz, której osi dotyczy problem, kierunek ruchu, szacowaną prędkość, czas trwania, pozycję początkową, tryb pracy maszyny, stan wrzeciona, aktywny krok programu oraz sposób zatrzymania ruchu. Ustal, czy ruch rozpoczął się ze stanu spoczynku, czy pojawił się podczas już trwającego ruchu.
Jeśli suwak przyspiesza do prędkości maksymalnej, sprawdź polaryzację sprzężenia zwrotnego, aktywne źródła wartości zadanej, sekwencję załączania oraz regulację napędu. Jeśli przesuwa się tylko na krótkim odcinku, sprawdź bity ruchu impulsowego, zduplikowane wyzwalanie zboczem, nieaktualne polecenia oraz przejścia między stanami sekwencji.
Jeśli zdarzenie występuje wyłącznie w trybie automatycznym, większe znaczenie ma logika sekwencji. Jeśli występuje również w trybie ręcznym, skup się na arbitrażu poleceń wspólnym dla obu trybów. Jeśli oś porusza się podczas włączania zasilania, przejścia CPU, resetowania napędu lub ponownego połączenia z HMI, natychmiast sprawdź inicjalizację podczas uruchamiania.
Zachowanie podczas zatrzymywania dostarcza cennych informacji. Jeśli odebranie sygnału zezwolenia na pracę napędu z PLC zatrzymuje oś, stopień mocy może nadal reagować na oczekiwaną ścieżkę zezwolenia. Jeśli ruch trwa do chwili odłączenia zasilania głównego, zbadaj sprzęt napędu, zewnętrzne okablowanie zezwolenia, działanie styczników oraz źródła poleceń znajdujące się poza PLC.
Ustal również, czy napęd wygenerował ostrzeżenie lub błąd. Brak błędu podczas zdarzenia nie dowodzi, że napęd działał prawidłowo, ale sugeruje, że napęd mógł uznać polecenie i sprzężenie zwrotne za prawidłowe.
Traktuj maszynę jako kompletny łańcuch poleceń
Polecenie ruchu może rozpoczynać się na panelu operatorskim TP 170A. Przycisk, pole numeryczne, receptura, zdarzenie ekranowe lub sekwencja automatyczna ustawia wartość w pamięci PLC. S7-200 weryfikuje to żądanie i oblicza prędkość lub wartość zadaną ruchu. Następnie procedura komunikacji USS tworzy telegram zawierający dane sterujące i procesowe.
Jednostka MASTERDRIVES odbiera telegram i przekazuje słowo sterujące oraz wartość zadaną przez swoją wewnętrzną strukturę sygnałów. Końcowe aktywne polecenie może również uwzględniać stałe prędkości, wejścia analogowe, polecenia z zacisków, dodatkowe wartości zadane, wejścia impulsowe lub wewnętrzne bloki funkcyjne.
Droga sprzężenia zwrotnego jest równie ważna. Silnik lub obciążenie może korzystać z enkodera inkrementalnego, resolwera, tachometru lub innego urządzenia sprzężenia zwrotnego. Napęd interpretuje ten sygnał jako prędkość lub pozycję. Niektóre wartości rzeczywiste mogą następnie być przesyłane do PLC.
Mechaniczne wyłączniki krańcowe, czujniki pozycji bazowej, wyłączniki przekroczenia zakresu, styczniki, hamulce i styki gotowości napędu tworzą dodatkowe ścieżki. Każda z nich może wpływać na to, czy ruch się rozpocznie, będzie trwał lub zostanie zatrzymany.
Każdy etap powinien mieć wartość, którą można zmierzyć. W PLC rejestruj surowe żądanie z HMI, wybrany tryb pracy, stan sekwencji, końcową zweryfikowaną wartość zadaną, kierunek, polecenie zezwolenia oraz wynik komunikacji. W napędzie obserwuj odebrane słowo sterujące, odebraną wartość zadaną, aktywną wewnętrzną wartość zadaną, rzeczywistą prędkość, stan sprzężenia zwrotnego, prąd, ostrzeżenia i błędy.
Zero wyświetlane na HMI nie dowodzi, że PLC wysłał zero. Zero w jednym rejestrze PLC nie dowodzi, że inne źródło polecenia było nieaktywne. Poprawny telegram USS nie dowodzi, że napęd został skonfigurowany tak, aby używać tego telegramu jako jedynego źródła wartości zadanej.
Dochodzenie powinno wskazać pierwsze miejsce, w którym oczekiwana wartość różni się od wartości zarejestrowanej. Ten punkt dzieli problem na logikę HMI, aplikację PLC, komunikację, konfigurację napędu, sprzężenie zwrotne, układ mocy lub mechanikę.

Najważniejsze rozróżnienie diagnostyczne
Pierwsze pytanie techniczne jest proste: czy napęd otrzymał prawidłowe polecenie ruchu?
Podczas zdarzenia porównaj cztery wartości:
- Końcowa wartość zadana ruchu w PLC.
- Wartość zadana odebrana przez napęd.
- Aktywna wewnętrzna wartość zadana napędu.
- Rzeczywisty zmierzony ruch silnika lub suwaka.
Jeśli końcowa wartość zadana PLC staje się niezerowa, a napęd za nią podąża, napęd może działać prawidłowo. Niepożądany ruch został wygenerowany wcześniej w torze sterowania. Należy zbadać zdarzenia HMI, logikę sekwencji, zachowane wartości, przejścia między trybami oraz wielokrotne zapisy do końcowego polecenia.
Jeśli końcowa wartość zadana ruchu w PLC pozostaje równa zeru, ale napęd odbiera wartość niezerową, należy zbadać budowę telegramu, mapowanie pamięci, skalowanie, obsługę bufora oraz wykonanie bloku komunikacyjnego. Dokładna nieoczekiwana wartość może wskazać mechanizm. Powtarzająca się stała wartość często wskazuje na zachowane lub nieaktualne dane. Skrajna wartość dodatnia lub ujemna może wskazywać na problem z liczbą ze znakiem lub kolejnością bajtów.
Jeśli napęd odbiera zero, ale jego aktywna wewnętrzna wartość zadana staje się niezerowa, należy sprawdzić konfigurację napędu. Aktywne może być stałe ustawienie prędkości, sygnał analogowy, funkcja sterowania impulsowego, wejście zaciskowe, dodatkowa wartość zadana, potencjometr silnikowy lub opcja technologiczna.
Jeśli wartość zadana PLC, odebrana wartość zadana i wewnętrzna wartość zadana pozostają równe zeru, podczas gdy silnik przyspiesza, zdarzenie jest poważniejsze. Należy zbadać działanie sprzężenia zwrotnego, regulację napędu, zasilanie płyty sterującej, sprzęt napędu, działanie stopnia wyjściowego oraz sprzężenie mechaniczne.
Ta metoda wykorzystująca cztery sygnały zapobiega niekontrolowanej wymianie części. Pozwala również sformułować możliwy do obrony wniosek techniczny. Usterkę przypisuje się na podstawie zarejestrowanych dowodów, a nie założeń.
Sprzężenie zwrotne jest podejrzanym o wysokim priorytecie, ale nie stanowi automatycznego rozstrzygnięcia
Przerywany błąd enkodera lub tachometru jest prawdopodobny, zwłaszcza gdy zdarzenie zmienia się pod wpływem drgań, temperatury, poruszania przewodem lub położenia suwaka. Jednak założenie, że każda utrata sprzężenia zwrotnego automatycznie powoduje maksymalną prędkość, jest zbyt ogólne.
Prawidłowo skonfigurowany napęd powinien zwykle wykrywać brakujące lub nieprawdopodobne sprzężenie zwrotne i reagować zgodnie z ustawieniami monitorowania oraz błędów. Dokładna reakcja zależy od wersji sterowania, opcji sprzężenia zwrotnego, konfiguracji i zastosowania.
Niebezpieczne zachowanie może nadal wystąpić, gdy sygnał sprzężenia zwrotnego jest obecny, ale nieprawidłowy. Odwrócona polaryzacja, nieprawidłowa sekwencja faz, niestabilna amplituda sygnału, uszkodzone kanały, niewłaściwy typ enkodera, nieprawidłowe skalowanie, luźne sprzęgła lub nieodpowiednia konfiguracja regulatora mogą spowodować, że napęd zareaguje w niewłaściwym kierunku.
Przewód z przerwami rzadko ulega uszkodzeniu w postaci idealnego rozwarcia. Jeden przewodnik może rozłączać się tylko podczas zginania przewodu. Styk pinu złącza może zanikać wyłącznie przy silnych wibracjach. Napięcie zasilania enkodera może spadać podczas pracy stycznika. Prąd ekranu może zniekształcać jeden kanał różnicowy, nie powodując całkowitego zaniku sygnału.
Porównaj rzeczywistą prędkość zgłaszaną przez napęd z niezależnym pomiarem. Ręczny tachometr, tymczasowo podłączony sprawdzony czujnik lub odpowiedni pomiar oscyloskopem może ustalić, czy wewnętrzna wartość rzeczywista odpowiada fizycznemu ruchowi.
Jeśli napęd zgłasza zerową prędkość, mimo że wał się obraca, należy podejrzewać tor sprzężenia zwrotnego. Jeśli napęd zgłasza prawidłową prędkość, a wartość zadana staje się nieprawidłowa, sprzężenie zwrotne może działać prawidłowo.
Nigdy nie wykonuj testu sprzężenia zwrotnego, narażając personel na kontakt z poruszającym się suwakiem. Stosuj bariery, zmniejszoną prędkość, kontrolowane warunki testu oraz niezależną metodę zatrzymania.
Sprawdź cały obwód sprzężenia zwrotnego
Układ sprzężenia zwrotnego obejmuje więcej niż sam enkoder. Na mierzoną wartość wpływają czujnik, połączenie mechaniczne, przewód, złącze, zasilanie, ekran, układ uziemienia, płyta wejściowa oraz konfiguracja napędu.
Zacznij od połączenia mechanicznego. Potwierdź, że wał enkodera, pasek, przekładnia lub sprzęgło elastyczne nie mogą się ślizgać. Sprawdź piasty sprzęgła, wpusty, śruby ustalające, pęknięcia, zanieczyszczenia oraz niewspółosiowość. Mechanicznie odłączony enkoder może nadal generować sygnał, który nie odzwierciedla już rzeczywistego ruchu obciążenia.
Sprawdź każde złącze przy dobrym oświetleniu i z użyciem powiększenia. Poszukaj wsuniętych styków, słabych zacisków, wygiętych pinów, korozji, zanieczyszczeń olejem, uszkodzonego odciążenia kabla oraz naprężenia przewodu. Potwierdź, że złącza zamienne mają właściwy typ styków.
Sprawdź ciągłość obwodu po odłączeniu maszyny od zasilania, ale nie polegaj wyłącznie na statycznym pomiarze rezystancji. Pęknięty przewodnik może przewodzić, gdy jest wyprostowany, i rozłączać się po zgięciu. W ramach zatwierdzonego testu niskiego ryzyka monitoruj sygnał sprzężenia zwrotnego, gdy prowadnik kablowy porusza się w pełnym zakresie roboczym.
Zmierz napięcie zasilania enkodera bezpośrednio przy enkoderze podczas pracy pod obciążeniem. Stabilne napięcie wewnątrz szafy nie gwarantuje, że przy czujniku pozostaje ono stabilne. Zapisz wartość minimalną podczas przyspieszania wrzeciona, zmiany kierunku osi, hamowania oraz pracy stycznika.
W przypadku enkodera inkrementalnego sprawdź amplitudę kanałów, ich symetrię, wzajemną relację fazową oraz impuls indeksowy, jeśli jest używany. Pary różnicowe powinny zachowywać równowagę. Serie zakłóceń, brakujące impulsy lub spadek amplitudy mogą wskazywać na problemy z przewodem, ekranowaniem, zasilaniem albo czujnikiem.
Sprawdź typ enkodera, liczbę impulsów, biegunowość, skalowanie oraz źródło sprzężenia zwrotnego w zestawie parametrów zainstalowanego napędu. Nie zakładaj, że numer parametru z innej instrukcji MASTERDRIVES ma zastosowanie do tej płyty sterującej.

Błędy USS nie powinny być sprowadzane do losowych zmian bitów
Komunikacja USS odbywa się za pomocą ustrukturyzowanego telegramu. Protokół obejmuje kontrolę błędów, dlatego uszkodzony telegram powinien zwykle zostać odrzucony, a nie zaakceptowany jako niezależna, prawidłowa wartość zadana prędkości.
Nie oznacza to, że można ignorować USS. Problemy z komunikacją mogą nadal przyczyniać się do niekontrolowanego ruchu wskutek działania aplikacji. PLC może utworzyć nieprawidłowe słowo danych procesowych. Wartość ze znakiem może zostać zinterpretowana nieprawidłowo. Bajty starszy i młodszy mogą zostać zamienione miejscami. Stare dane mogą pozostać w buforze transmisji. Brak odpowiedzi może pozostawić aktywną poprzednią wartość zadaną.
Zduplikowane adresy slave’ów również mogą powodować trudne do wyjaśnienia zachowanie. Każdy napęd w sieci musi mieć unikalny adres. Sekwencja odpytywania PLC musi przypisywać każdą odpowiedź do właściwego slave’a i właściwego obszaru pamięci.
Słowo sterujące wymaga takiej samej uwagi jak wartość zadana prędkości. Napęd może pozostać w stanie aktywnym, podczas gdy program PLC zakłada, że został zatrzymany. Potwierdzanie błędów, polecenia WŁ./WYŁ., bity kierunku oraz logika ponownego uruchamiania mogą być nieprawidłowo przetwarzane podczas przywracania komunikacji.
Zliczaj udane transakcje, przekroczenia limitu czasu, odrzucone ramki, kolejne niepowodzenia oraz zdarzenia przywrócenia komunikacji. Pojedynczy bit „błędu komunikacji” dostarcza zbyt mało informacji. Dane diagnostyczne powinny wskazywać, który slave był odpytywany oraz która transakcja zakończyła się niepowodzeniem.
W urządzeniu MICROMASTER 440 parametr P2010 dotyczy konfiguracji szybkości transmisji USS. Nie należy traktować go jako ogólnego ustawienia limitu czasu telegramu. Parametr P2011 jest zwykle powiązany z adresem USS. Znaczenie wszystkich parametrów należy jednak zweryfikować w odpowiedniej instrukcji MM440 oraz w konfiguracji interfejsu.
Dłuższy timeout nie jest automatycznie bezpieczniejszy. Jeśli napęd nadal wykorzystuje poprzednią niezerową wartość zadaną podczas oczekiwania na upływ limitu czasu, wydłużenie tego opóźnienia może przedłużyć niepożądany ruch. Najpierw określ wymaganą reakcję na utratę komunikacji.
Warstwa fizyczna RS-485 nadal ma znaczenie
Nawet jeśli uszkodzone ramki są odrzucane, niestabilna sieć RS-485 może powodować wielokrotne ponowienia transmisji, nieaktualne dane, pomijanie aktualizacji statusu oraz nieregularne czasy wykonywania aplikacji. Dlatego sieć fizyczna wymaga pełnego audytu.
Udokumentuj magistralę od portu komunikacyjnego S7-200 do każdego napędu. Potwierdź, że okablowanie wykorzystuje prawidłową topologię liniową. Długich odgałęzień gwiaździstych należy unikać, ponieważ mogą powodować odbicia, chyba że dokumentacja zainstalowanego interfejsu wyraźnie na nie zezwala.
Sprawdź, czy wszystkie urządzenia używają zgodnych ustawień komunikacji. Obejmują one szybkość transmisji, parzystość, strukturę telegramu, długość danych procesowych oraz adres slave’a. Zapisz te ustawienia zamiast zmieniać je z pamięci.
Terminacja musi być zgodna z wymaganiami rzeczywistych interfejsów i złączy firmy Siemens. Nie należy automatycznie dodawać standardowego rezystora 120 Ω. Nieprawidłowa terminacja lub polaryzacja może pogorszyć jakość sygnału.
Sprawdź typ kabla komunikacyjnego, ciągłość ekranu, połączenie ekranu ze złączami oraz sposób prowadzenia. Kabel RS-485 nie powinien na długich odcinkach biec obok kabli wyjściowych silnika, przewodów rezystora hamowania, przewodów styczników ani innych obwodów zasilających o wysokiej częstotliwości.
Jeśli możliwości separacji są ograniczone, krzyżuj kable zasilające i sygnałowe pod kątem zbliżonym do prostego. Zapewnij celowe połączenie wyrównawcze potencjałów między szafami i sekcjami maszyny. Unikaj długich przewodów typu pigtail ekranu, które zmniejszają skuteczność przy wysokich częstotliwościach.
W razie potrzeby użyj odpowiedniej różnicowej sondy oscyloskopowej do obserwacji przebiegu. Szukaj odbić, nadmiernego napięcia wspólnego, dzwonienia, powolnych zboczy, impulsów zakłóceniowych oraz zmian amplitudy podczas przyspieszania wrzeciona lub hamowania osi.
Podłączony laptop lub konwerter USB może zmienić uziemienie i obciążenie magistrali. Zapisz, czy błąd zmienia się po podłączeniu urządzeń diagnostycznych.
Komponenty stosowane w komunikacji przemysłowej i sieciach należy oceniać razem z topologią, ekranowaniem, terminacją, adresowaniem i obsługą transakcji PLC. Wymiana jednego złącza nie naprawi niestabilnego automatu stanów komunikacji.

Przejrzyj program S7-200 jako automat stanów
Przerywane błędy podczas uruchamiania często pojawiają się w trakcie przejść, a nie podczas stabilnej pracy. Maszyna może działać prawidłowo podczas ciągłej pracy, ale ulegać awarii przy przełączaniu między trybem ręcznym i automatycznym, zakończeniu bazowania, odzyskiwaniu po alarmie, zmianie receptury lub przywracaniu komunikacji.
Przeszukaj odwołania skrośne programu pod kątem każdej instrukcji zapisującej do końcowych zmiennych prędkości, kierunku i zezwolenia. Starsze programy często zapisują do tego samego słowa pamięci V w kilku sieciach. Ostatecznie wykonany zapis steruje wynikiem, co może powodować zachowanie wyglądające na losowe.
Utwórz jeden przejrzysty etap arbitrażu poleceń. Ręczne przesuwanie skokowe, ruch automatyczny, bazowanie, funkcje konfiguracyjne i polecenia konserwacyjne powinny trafiać do tego etapu jako oddzielne żądania. Końcowa wartość zadana powinna być generowana dopiero po sprawdzeniu trybu, limitów, sprzężenia zwrotnego, komunikacji i zezwoleń bezpieczeństwa.
Przejrzyj logikę impulsów jednokrotnych i wykrywania zboczy. Polecenie przeznaczone do wykonania przez jeden skan może pozostać aktywne, ponieważ jego pamięć zbocza została ponownie użyta, zachowana lub nadpisana. Polecenie może również zostać wyzwolone ponownie po zmianie bitu trybu.
Sprawdź każdy zatrzask. Zidentyfikuj warunek, który go ustawia, oraz każdy warunek, który go resetuje. Zatrzask ruchu zależny wyłącznie od późniejszego kroku sekwencji może pozostać aktywny, gdy sekwencja zostanie przerwana przez błąd.
Sprawdź obsługę danych ze znakiem. Ujemna liczba całkowita zinterpretowana jako słowo bez znaku może stać się dużą liczbą dodatnią. Mnożenie może spowodować przepełnienie. Słowo skopiowane w niewłaściwej kolejności bajtów może utworzyć skrajną wartość zadaną.
Zweryfikuj skalowanie z jednostek inżynierskich do wartości procesowej USS. Zastosuj ograniczenia dodatnie i ujemne po wykonaniu końcowych obliczeń, a nie tylko na wejściu panelu HMI.
Starsze systemy sterowania Siemens SIMATIC S7 mogą niezawodnie działać przez dziesięciolecia, ale ich aplikacje często zawierają modyfikacje z kilku etapów uruchamiania. Uporządkowany przegląd odsyłaczy jest cenniejszy niż założenie, że sprzęt CPU stał się niestabilny.
Stany rozruchu i przywracania wymagają oddzielnych testów
Niezainicjalizowane lub zachowane dane mogą powodować sporadyczny ruch po przerwach w zasilaniu, pobraniu oprogramowania, przejściu CPU ze stanu STOP do RUN, resetach napędu lub ponownym połączeniu panelu HMI.
Zidentyfikuj każdy obszar pamięci retencyjnej używany przez program ruchu. Ustal wartość początkową polecenia prędkości, kierunku, zezwolenia, trybu, kroku sekwencji, bitów ruchu impulsowego i stanu komunikacji po każdym rodzaju restartu.
Procedura rozruchowa powinna wymuszać wyzerowanie wszystkich żądań ruchu. Powinna kasować oczekujące polecenia ruchu impulsowego i automatycznego, weryfikować sprzężenie zwrotne, potwierdzać stan ograniczników, ustanawiać komunikację oraz wymagać celowego wykonania nowej sekwencji zezwolenia.
Zachowana niezerowa wartość zadana nigdy nie może stać się aktywna tylko dlatego, że napęd uzyska gotowość, zanim PLC zakończy inicjalizację.
Przetestuj zimny rozruch, ciepły restart, przejście CPU ze stanu STOP do RUN, reset napędu, ponowne połączenie panelu HMI oraz przywrócenie niesprawnego urządzenia podrzędnego USS. Wykonuj te testy przy mechanicznie zabezpieczonej maszynie i przy zmniejszonej dostępnej prędkości.
Monitoruj zasilanie sterowania 24 V podczas zdarzeń związanych z zasilaniem. PLC, enkoder, panel HMI, interfejs komunikacyjny, styczniki i elektronika sterująca napędu mogą resetować się przy różnych progach napięcia. Krótkotrwały spadek napięcia może sprawić, że jedno urządzenie będzie nadal działać, podczas gdy inne uruchomi się ponownie.
Zarejestruj kolejność włączania zasilania sterowania, przejścia PLC do trybu RUN, uzyskania prawidłowej komunikacji, gotowości napędu, zwolnienia hamulca i zezwolenia na ruch. Ta kolejność powinna być jednoznaczna i powtarzalna.
Panel HMI może generować polecenia, które nie są już widoczne
Projekt TP 170A należy przeanalizować wraz z programem PLC. Polecenie z panelu HMI może zostać zapisane podczas naciskania przycisku, zwalniania przycisku, otwierania ekranu, zamykania ekranu, pobierania receptury, aktualizacji znacznika lub przywracania komunikacji.
Przycisk chwilowy może powodować niebezpieczny stan, gdy jego naciśnięcie ustawia bit, a zwolnienie go kasuje ten bit. Jeśli podczas naciskania przycisku dojdzie do awarii komunikacji, polecenie kasowania może nigdy nie dotrzeć do sterownika PLC.
Operator później widzi przycisk w stanie nienaciśniętym, ale bit PLC pozostaje aktywny. Kolejna zmiana trybu lub warunek zezwolenia może wtedy umożliwić przekazanie nieaktualnego żądania pracy impulsowej do końcowego polecenia ruchu.
Solidna funkcja pracy impulsowej nie powinna opierać się wyłącznie na parze naciśnięcie–zwolnienie. PLC powinien wymagać ciągłego odświeżania polecenia, stosować krótki czas wygaśnięcia, sprawdzać tryb pracy i usuwać polecenie, gdy komunikacja stanie się nieprawidłowa.
Sprawdź każde zdarzenie HMI związane z pracą impulsową, wprowadzaniem prędkości, kierunkiem, resetowaniem, wyborem trybu, bazowaniem oraz sterowaniem cyklem automatycznym. Wyszukaj zduplikowane znaczniki wskazujące ten sam adres PLC.
Wejścia numeryczne wymagają sprawdzania zakresu zarówno na panelu, jak i w PLC. PLC musi odrzucać wartości spoza dozwolonego zakresu inżynierskiego, nawet gdy pole HMI wydaje się prawidłowo skonfigurowane.
Starsze systemy Siemens SIMATIC HMI mogą zawierać zachowanie na poziomie ekranu, które nie jest widoczne w logice PLC. Rejestrowanie surowego znacznika HMI oddzielnie od zweryfikowanego polecenia PLC pomaga zidentyfikować rzeczywiste źródło polecenia.
MM440 może wpływać na zdarzenie, nie sterując suwakiem
MICROMASTER 440 steruje wrzecionem, ale nadal może wpływać na środowisko sterowania suwakiem. Jego prostownik wejściowy, obwód pośredni DC, wyjście silnikowe, układ hamowania i częstotliwość przełączania mogą powodować zakłócenia przewodzone lub promieniowane.
Najsilniejsze zakłócenie może wystąpić podczas przyspieszania, zwalniania, szczytów prądu lub hamowania wrzeciona, a nie podczas pracy ustalonej. Porównaj znaczniki czasu niekontrolowanego ruchu ze stanem wrzeciona.
Rejestruj uruchomienie i zatrzymanie wrzeciona, zmianę prędkości, prąd, stan obwodu pośredniego DC, historię błędów oraz aktywność hamowania. Ustal, czy każde zdarzenie występuje podczas podobnego przejścia stanu wrzeciona.
Jeśli jednostki MM440 i MASTERDRIVES współdzielą magistralę USS, wrzeciono również wpływa na czas komunikacji. Sterownik PLC musi odpytywać każdy element podrzędny w przewidywalny sposób i przetwarzać każdą odpowiedź w prawidłowej strukturze pamięci.
Sprawdź, czy obszary danych USS wrzeciona i suwaka nie nakładają się na siebie. W niewielkich aplikacjach S7-200 pamięć V bywa ponownie wykorzystywana bez wyraźnego rozdzielenia. Blok zapisujący dane wrzeciona może nadpisać część polecenia suwaka.
Przeniesienie MM440 poza szafę nie eliminuje całkowicie jego wpływu. Kable silnikowe, ścieżki uziemienia, prowadzenie przewodów komunikacyjnych i współdzielone zasilacze mogą nadal pozostać połączone.
Należy wykonywać pomiary zamiast wielokrotnie zmieniać położenie urządzeń. Sprawdź separację kabli, połączenia ekranów, dławiki sieciowe lub filtry określone dla napędu, połączenia wyrównawcze szafy, zakończenie kabla silnikowego oraz zależność czasową między zdarzeniami przełączania a błędami komunikacji.
Audyt MASTERDRIVES według funkcji sygnału
Audyt parametrów MASTERDRIVES powinien obejmować całą ścieżkę sygnału. Nie należy zaczynać od listy numerów parametrów skopiowanej z innej instalacji.
Najpierw zweryfikuj zainstalowaną wersję sterowania, wydanie oprogramowania, płytę sterującą i opcję sprzężenia zwrotnego. Następnie sprawdź tryb sterowania, dane silnika, typ sprzężenia zwrotnego, jego skalowanie oraz źródło.
Zidentyfikuj każde źródło, które może sterować komendami WŁ./WYŁ. napędu. Mogą to być słowa sterujące USS, wejścia zaciskowe, komendy stałe, wewnętrzne połączenia binektorów lub funkcje technologiczne.
Zidentyfikuj każde źródło, które może wpływać na końcową wartość zadaną prędkości lub położenia. Sprawdź główną wartość zadaną, dodatkowe wartości zadane, prędkości stałe, funkcje impulsowego ruchu, wejścia analogowe, funkcje potencjometru silnikowego oraz wewnętrzne bloki funkcyjne.
Sprawdź dodatnie i ujemne ograniczenia prędkości, rampy przyspieszania, rampy hamowania, ograniczenia prądu, ograniczenia momentu oraz ograniczenia kierunku. Tymczasowe, zachowawcze ustawienia mogą zmniejszyć ryzyko diagnostyczne, ale nie stanowią niezależnego zabezpieczenia.
Sprawdź monitorowanie sprzężenia zwrotnego i reakcję na usterki. Ustal, co napęd ma skonfigurowane do wykonania, gdy sprzężenie zwrotne zanika, staje się niestabilne, odwrócone lub nieprawdopodobne.
Odczytaj historię ostrzeżeń i usterek napędu przed jej wyczyszczeniem. Ostrzeżenie, które wydaje się niezwiązane z problemem, może rejestrować moment zmiany warunku sterowania.
Użyj zainstalowanej metody inżynierskiej, takiej jak DriveMonitor, PMU, OP1S lub innego zatwierdzonego interfejsu, aby obserwować wewnętrzne złącza i wartości rzeczywiste. Wybierz wartości odpowiednio do konkretnej wersji sterowania.
To podejście funkcjonalne ma zastosowanie w starszych i obecnych systemach napędowych i sterowania ruchem Siemens. Oprogramowanie sterujące, opcje sprzężenia zwrotnego i wewnętrzne trasowanie mogą się różnić, nawet gdy dwa napędy wyglądają fizycznie podobnie.
Zbuduj rejestrator zdarzeń wyzwalanych
Zdarzenia występującego raz dziennie nie da się rozwiązać przez ciągłą obserwację HMI. System potrzebuje rejestratora diagnostycznego, który zapisuje okres przed nieprawidłowym ruchem i po nim.
Utwórz cykliczny bufor PLC zawierający surową komendę z HMI, zweryfikowaną komendę, końcową wartość zadaną prędkości, kierunek, zezwolenie, tryb, stan sekwencji, sygnały wejściowe ograniczeń, stan gotowości napędu, wynik transakcji USS oraz licznik próbek.
Po stronie napędu rejestruj odebrane słowo sterujące, odebraną wartość zadaną, aktywną wewnętrzną wartość zadaną, rzeczywistą prędkość, stan sprzężenia zwrotnego, prąd wyjściowy, prąd wytwarzający moment — jeśli jest dostępny — oraz ostrzeżenia i usterki.
Wyzwolenie może być oparte na rzeczywistej prędkości przekraczającej niewielki próg, gdy końcowa komenda PLC ma wartość zero. Inne wyzwolenie może wykrywać ruch poza zatwierdzonym stanem sekwencji. Niezgodność między zadanym a zmierzonym kierunkiem również może uruchomić rejestrację.
Zachowaj dane sprzed wyzwolenia. Jeśli rejestrowanie rozpocznie się dopiero po przesunięciu suwaka, warunek inicjujący może już nie występować.
Diagnostyka komunikacji powinna rozróżniać udane transakcje, brakujące odpowiedzi, odrzucone wiadomości, kolejne awarie i zdarzenia przywrócenia działania. Zapisuj, który slave był aktywny w chwili wystąpienia błędu.
Logika diagnostyczna powinna być zwarta. S7-200 ma ograniczoną pamięć i ograniczoną wydajność skanowania. Upewnij się, że rejestrowanie danych nie zakłóca taktowania istniejących procedur USS.
Eksportuj dane po każdym zdarzeniu. Zapisuj je wraz z datą, stanem maszyny, raportem świadka i wszelkimi obserwacjami fizycznymi. Sekwencja kilku zdarzeń może ujawnić wzorzec, którego nie da się dostrzec na podstawie jednego zdarzenia.
Używaj liczników diagnostycznych, które odpowiadają na konkretne pytania
Liczniki są przydatne tylko wtedy, gdy ich znaczenie jest jasne. Ogólny licznik poleceń i ogólny licznik sprzężenia zwrotnego mogą się różnić z wielu normalnych przyczyn.
Zliczaj każde zaakceptowane przez HMI żądanie ruchu. Zliczaj każde polecenie ruchu zaakceptowane przez końcową arbitrażową logikę PLC. Zliczaj każde pomyślnie zakończone przesłanie USS. Zliczaj każdą prawidłową odpowiedź odebraną z napędu osi.
Zliczaj również przekroczenia limitu czasu komunikacji, zdarzenia „napęd niegotowy”, aktywacje ograniczników, zmiany trybu i wygaśnięcia poleceń.
Zapisuj ostatnią wysłaną wartość prędkości i słowo sterujące. Zapisuj ostatnią prawidłowo odebraną wartość rzeczywistą i słowo stanu. Tam, gdzie jest to praktyczne, dodaj numer sekwencyjny do struktury polecenia.
Gdy wystąpi zdarzenie, liczniki mogą udzielić odpowiedzi na kilka pytań:
- Czy HMI wygenerował żądanie?
- Czy PLC zatwierdził to żądanie?
- Czy PLC wysłał nowy telegram?
- Czy napęd zwrócił prawidłową odpowiedź?
- Czy rzeczywisty ruch rozpoczął się bez nowego zatwierdzonego polecenia?
Nie należy automatycznie zerować licznika przy każdym uruchomieniu, chyba że jego wcześniejsza wartość jest niepotrzebna. Rozważ zapisywanie licznika zdarzeń w pamięci podtrzymywanej, przy jednoczesnym wymuszaniu bezpiecznej wartości początkowej dla wszystkich poleceń ruchu.
Niezależne zabezpieczenie przed przekroczeniem zakresu ruchu nie może zależeć od standardowej logiki
Programowe ograniczenia położenia są przydatne, ale nie mogą być jedynym zabezpieczeniem przed usterką, która może powstać w programie PLC, torze komunikacyjnym lub standardowym sterowniku napędu.
Każda oś powinna mieć prawidłowo zaprojektowane zabezpieczenie przed wyjazdem poza zakres ruchu. W zależności od oceny ryzyka maszyny może ono obejmować przewodowe wyłączniki krańcowe, czujniki położenia z funkcją bezpieczeństwa, przekaźniki bezpieczeństwa, obwody blokady napędu, styczniki, hamulce lub inną zwalidowaną architekturę.
Standardowe wejście PLC zapisujące polecenie prędkości równe zero nie jest automatycznie funkcją bezpieczeństwa. Ten sam błąd logiki, który spowodował ruch, może uniemożliwić przetworzenie polecenia zatrzymania.
Usunięcie wartości zadanej prędkości również nie gwarantuje odłączenia momentu obrotowego. Napęd może pozostać aktywny, druga wartość zadana może pozostać aktywna albo zgromadzona energia mechaniczna może nadal wprawiać obciążenie w ruch.
Przetestuj niezależnie zatrzymanie awaryjne, blokady osłon, wyłączniki przekroczenia zakresu, styki sygnalizujące błąd napędu, hamulce i styczniki. Potwierdź, że po zadziałaniu zabezpieczenia ponowne uruchomienie wymaga świadomego działania.
Podczas uruchamiania diagnostycznego należy, tam gdzie jest to technicznie możliwe, zmniejszyć maksymalną prędkość, przyspieszenie, moment obrotowy i dostępny zakres przesuwu. Tymczasowe ograniczniki mechaniczne należy stosować wyłącznie wtedy, gdy są zaprojektowane na energię możliwego uderzenia.
Żaden cel diagnostyczny nie uzasadnia narażania osoby na kontakt z osią, która wcześniej wykazała niekontrolowany ruch.
Przykład: Kabel, który ulega awarii tylko podczas zmiany kierunku
Rozważmy suwak, który zachowuje się prawidłowo podczas powolnego testu statycznego, ale porusza się gwałtownie podczas szybkiej zmiany kierunku. Rejestr PLC pokazuje stabilne polecenie. Ślad z napędu pokazuje nagłe zakłócenie zmierzonej prędkości, po którym następuje duży sygnał korygujący.
Test ciągłości kabla enkodera przechodzi pomyślnie, gdy maszyna jest zatrzymana. Kabel przebiega jednak przez prowadnik ruchomy. Jeden przewód jest pęknięty w pobliżu minimalnego promienia gięcia i rozwiera się tylko wtedy, gdy prowadnik osiąga określone położenie.
Pomiar oscyloskopowy na wejściu napędu pokazuje zanik jednego kanału enkodera podczas zmiany kierunku. Polecenie pozostaje prawidłowe i nie jest rejestrowany żaden błąd USS.
Kabel zostaje wymieniony na właściwy typ przeznaczony do ciągłego zginania. Przywracane są odciążenie przewodu i zakończenie ekranu. Zasilanie enkodera oraz jakość przebiegu są testowane na całej długości przesuwu suwaka.
Końcowa weryfikacja obejmuje wielokrotne zmiany kierunku przy zmniejszonej prędkości, a następnie kontrolowaną pracę z normalną prędkością produkcyjną. Nowy, prawidłowy przebieg jest zapisywany jako wartość odniesienia.
Ten przypadek pokazuje, dlaczego usterkę sprzężenia zwrotnego należy potwierdzać dynamicznie. Statyczny test rezystancji może zakończyć się pomyślnie, nawet gdy kabel ulega awarii podczas pracy.
Przykład: Polecenie ruchu impulsowego przetrwa utratę komunikacji z HMI
W innej maszynie naciśnięcie przycisku ruchu impulsowego ustawia bit PLC. Zwolnienie przycisku go kasuje. Podczas przytrzymywania przycisku HMI traci komunikację, więc polecenie zwolnienia nigdy nie dociera do PLC.
W tym momencie inny układ blokady uniemożliwia ruch. Nieaktualny bit ruchu impulsowego pozostaje ukryty. Później operator zmienia tryb maszyny. Końcowa logika PLC akceptuje teraz stare żądanie ruchu impulsowego, a suwak porusza się nieoczekiwanie.
Napęd realizuje prawidłową wartość zadaną z PLC. Komunikacja USS działa poprawnie w chwili rozpoczęcia ruchu. Wymiana enkodera ani dodanie kolejnego połączenia ekranu nie rozwiąże problemu.
Zmieniona logika PLC wymaga ciągłego odświeżania żądania ruchu impulsowego. Polecenie wygasa po krótkim czasie. Jest akceptowane tylko w prawidłowym trybie, przy sprawnej komunikacji i spełnionym wymaganym warunku zezwolenia.
Logika uruchamiania usuwa wszystkie żądania ruchu. Działanie zwolnienia na HMI pozostaje, ale nie jest już jedynym mechanizmem usuwającym polecenie.
Rejestrator zdarzeń potwierdza, że surowy bit HMI pozostał aktywny po wcześniejszej awarii komunikacji. Przyczyną źródłową nie było uszkodzenie komunikacji, lecz niebezpieczna obsługa prawidłowego, ale nieaktualnego polecenia.
Przykład: Zakłócenia ujawniają słabe zarządzanie buforem USS
W trzeciej maszynie występują przekroczenia czasu USS podczas przyspieszania wrzeciona. Uszkodzone telegramy są odrzucane, więc sieć nie przekształca bezpośrednio jednego polecenia prędkości w inne.
Aplikacja PLC nie unieważnia jednak poprzedniego polecenia osi po nieudanej transakcji. Procedura USS również działa warunkowo, powodując nieregularne odstępy między odpytywaniami.
Podczas przejścia między sekwencjami nowe polecenie zerowe jest zapisywane w jednej lokalizacji pamięci, podczas gdy bufor transmisji nadal zawiera starszą wartość niezerową. Następny pomyślnie przesłany telegram zawiera prawidłowe, lecz nieaktualne dane.
Napęd otrzymuje prawidłowo skonstruowane polecenie i reaguje normalnie. Zakłócenie warstwy fizycznej ujawniło słabość oprogramowania, a nie wygenerowało bezpośrednio wartości zadanej.
Działanie korygujące poprawia prowadzenie przewodów i połączenie ekranów. Następnie procedura komunikacyjna PLC zostaje przeprojektowana tak, aby każdy napęd korzystał z dedykowanej pamięci. Końcowa, zweryfikowana wartość zadana jest kopiowana do bufora transmisji bezpośrednio przed transakcją.
Brak odebranej odpowiedzi oznacza dane jako nieprawidłowe. Zaprogramowaną reakcję na utratę komunikacji weryfikuje się w kontrolowanych testach.
Ten przypadek pokazuje, dlaczego diagnostyka komunikacji musi obejmować zarówno przebieg elektryczny, jak i cykl życia danych aplikacji.
Praktyczna sekwencja badania na miejscu
Krok 1: Zabezpiecz maszynę. Zapewnij niezależną ochronę przed przekroczeniem zakresu ruchu, zmniejsz energię testową i ogranicz dostęp personelu.
Krok 2: Potwierdź konfigurację sprzętową. Zapisz pełne numery zamówieniowe, wersje oprogramowania, karty opcji, urządzenia sprzężenia zwrotnego i moduły interfejsów.
Krok 3: Utwórz kopie zapasowe. Zapisz program S7-200, projekt TP 170A, zestaw parametrów MASTERDRIVES i parametry MM440.
Krok 4: Zdefiniuj zdarzenie. Zapisz kierunek, prędkość, czas trwania, tryb pracy, pozycję, stan wrzeciona i sposób zatrzymania.
Krok 5: Zmapuj łańcuch poleceń. Zidentyfikuj każde źródło wartości zadanej, zezwolenia, kierunku, prędkości stałej, impulsowania i dodatkowej wartości zadanej.
Krok 6: Dodaj zsynchronizowane rejestrowanie. Rejestruj polecenia PLC, dane USS, wartości wewnętrzne napędu, sprzężenie zwrotne, prąd, wartości graniczne, ostrzeżenia i błędy.
Krok 7: Sprawdź stany rozruchowe. Zbadaj rozruch na zimno, ciepły restart, przejścia CPU RUN, ponowne połączenie HMI i przywracanie komunikacji.
Krok 8: Dynamicznie sprawdź sygnały sprzężenia zwrotnego. Zbadaj napięcie zasilania, jakość przebiegu, sprzężenie, złącza, ekranowanie i uginanie przewodu.
Krok 9: Przeprowadź audyt USS i RS-485. Sprawdź adresowanie, topologię, terminację, obszary danych, czasy oraz obsługę błędów.
Krok 10: Przeanalizuj odwołania skrośne PLC. Znajdź każdy zapis do końcowej wartości zadanej, kierunku oraz zezwolenia na pracę napędu.
Krok 11: Przeprowadź audyt trasowania sygnałów napędu. Zweryfikuj każde źródło poleceń oraz każdy element wpływający na aktywną wartość zadaną.
Krok 12: Zmieniaj tylko jeden element naraz. Zapisz stan poprzedni, stan nowy, przyczynę, wynik testu oraz metodę wycofania zmiany.
Długoterminowe wzmocnienie musi uwzględniać architekturę
Po znalezieniu bezpośredniej przyczyny zapytaj, dlaczego jedna usterka mogła doprowadzić do niebezpiecznego ruchu. Pojedyncze przekroczenie limitu czasu komunikacji, przerwanie kabla lub błąd HMI nie powinny omijać wszystkich warstw ochronnych.
Rozdziel generowanie poleceń, walidację poleceń, transport komunikacyjny, sterowanie napędem oraz ochronę bezpieczeństwa. Każda warstwa powinna mieć jasno określoną odpowiedzialność.
PLC powinien generować ograniczone i zweryfikowane pod względem stanu polecenie. Procedura komunikacyjna powinna przesyłać aktualne dane z jasno określoną ważnością i aktualnością. Napęd powinien stosować skonfigurowane limity pracy i monitorowanie sprzężenia zwrotnego. Niezależne funkcje bezpieczeństwa powinny sterować ruchem niebezpiecznym.
Rozważ, czy architektura S7-200 i USS nadal nadaje się do utrzymania. Migracja na nowszą platformę PLC i napędu może poprawić diagnostykę, znakowanie czasem, dostępność komponentów, widoczność sieci oraz zarządzanie kopiami zapasowymi.
Nowsza sieć nie czyni automatycznie maszyny bezpieczną. Sam PROFINET nie naprawi słabej arbitrażu poleceń, niewłaściwej logiki uruchamiania ani niewystarczającej ochrony przed przekroczeniem zakresu ruchu.
Modernizacja powinna obejmować HMI, rysunki, kontrolę wersji oprogramowania, architekturę bezpieczeństwa, strategię części zamiennych oraz szkolenie personelu. Wymiana wyłącznie PLC może przenieść problem na inną platformę.
W przypadku wymagających aplikacji pozycjonowania oceń, czy profil ruchu powinien być wykonywany w dedykowanym napędzie lub sterowniku ruchu, zamiast za pomocą wielokrotnie wysyłanych szeregowych poleceń prędkości. Właściwa decyzja zależy od dokładności pozycjonowania, synchronizacji, czasu cyklu, architektury sprzężenia zwrotnego oraz ryzyka związanego z maszyną.
Weryfikacja to coś więcej niż oczekiwanie na ponowne wystąpienie usterki
Siedem dni bez incydentu napawa optymizmem, ale nie dowodzi usunięcia przyczyny źródłowej. Weryfikacja powinna celowo odtworzyć warunki, które wcześniej zwiększały ryzyko.
Wykonaj wielokrotne cykle pełnego przejazdu z kontrolowaną prędkością. Uwzględnij szybkie nawroty, przyspieszanie wrzeciona, hamowanie wrzeciona, nagrzaną szafę, maksymalne normalne obciążenie oraz ruch prowadnika kablowego.
Powtórz testy uruchamiania i odzyskiwania po awarii. Przełączaj zasilanie sterowania zgodnie z zatwierdzoną procedurą. Przetestuj przejście CPU ze stanu STOP do RUN, reset napędu, ponowne połączenie HMI, utratę jednego urządzenia podrzędnego USS oraz przywrócenie komunikacji.
Zweryfikuj reakcję na awarię sprzężenia zwrotnego za pomocą zatwierdzonej metody testowej. Nie odłączaj enkodera produkcyjnego, gdy personel jest narażony na ruch.
Przetestuj każdą krańcówkę sprzętową, ograniczenie programowe, wejście awarii napędu, zatrzymanie awaryjne, hamulec i niezależne urządzenie ograniczające nadmierny przesuw. Potwierdź wymaganą reakcję zatrzymania i zachowanie podczas ponownego uruchomienia.
Porównuj końcowe polecenie PLC, polecenie odebrane przez napęd, aktywną wewnętrzną wartość zadaną i rzeczywisty ruch podczas każdego testu.
Zdefiniuj kryteria akceptacji przed rozpoczęciem testów. Odpowiednie kryteria mogą obejmować:
- Brak niezamierzonego ruchu podczas jakiegokolwiek stanu uruchamiania lub odzyskiwania.
- Brak nieobsłużonej awarii komunikacji USS.
- Brak zachowanego polecenia ruchu po utracie komunikacji z HMI.
- Stabilne zasilanie sprzężenia zwrotnego i przebieg sygnału na całej długości przesuwu.
- Prawidłowe działanie każdego niezależnego urządzenia ograniczającego nadmierny przesuw.
- Zarejestrowana zgodność między poleceniem, odebraną wartością zadaną, aktywną wartością zadaną i rzeczywistym ruchem.
Utrzymuj rejestrator zdarzeń podczas początkowej pracy produkcyjnej. Skuteczne działanie naprawcze powinno wyeliminować zarówno objaw fizyczny, jak i nieprawidłowy wzorzec diagnostyczny, który go spowodował.
Przyczyna źródłowa pojawi się tam, gdzie sygnały po raz pierwszy przestaną być zgodne
Nie należy przypisywać przerywanego niekontrolowanego ruchu suwaka w systemie Siemens S7-200 i MASTERDRIVES „zakłóceniom”, „enkoderowi” ani „USS” bez dowodów.
Rozstrzygającą metodą jest skorelowanie końcowego polecenia PLC, polecenia odebranego przez napęd, aktywnej wartości zadanej wewnątrz napędu oraz rzeczywistej reakcji mechanicznej.
Jeśli polecenie sterownika PLC staje się nieprawidłowe, zbadaj panel HMI i logikę aplikacji. Jeśli przesyłana lub odbierana wartość staje się nieprawidłowa, zbadaj obsługę pamięci, skalowanie, budowę telegramu i sieć RS-485.
Jeśli napęd aktywuje źródło polecenia, którego sterownik PLC nie zamierzał użyć, skontroluj wewnętrzną konfigurację napędu. Jeśli wszystkie polecenia pozostają bezpieczne, a silnik przyspiesza, zbadaj sprzężenie zwrotne, zasilanie płyty sterującej, sprzęt napędu i mechanikę.
Awarie sprzężenia zwrotnego nadal są wiarygodną możliwością, ale należy je testować jako kompletne obwody. Problemy z USS również pozostają wiarygodne, jednak bardziej prawdopodobne mogą być nieaktualne, lecz formalnie prawidłowe dane oraz słaba logika odzyskiwania niż losowo uszkodzony telegram, który staje się prawidłową komendą maksymalnej prędkości.
Maszyna powinna powrócić do normalnej pracy dopiero po skutecznym zadziałaniu niezależnych zabezpieczeń, potwierdzeniu mechanizmu inicjującego zapisanymi dowodami oraz zweryfikowaniu w kontrolowanych testach zarówno działania naprawczego, jak i reakcji na przyszłe usterki.
To zdyscyplinowane podejście wymaga więcej przygotowań niż spekulacyjna wymiana podzespołów. Daje też cenniejszy rezultat: maszynę, której tor ruchu jest zrozumiany, zarejestrowany, udokumentowany i zabezpieczony przed kolejną pojedynczą awarią.