Gdy pamięć maszyny okazuje się krótsza niż pamięć zakładu

W utrzymaniu ruchu są sytuacje, które nie dają ani komfortu jednoznacznej awarii, ani pewności stabilnego powrotu do produkcji. Po zaniku zasilania, po restarcie albo po odtworzeniu części danych maszyna uruchamia się poprawnie. Sterownik odpowiada, panel operatorski działa, komunikacja wraca, napędy wykonują ruch. Z zewnątrz wszystko wygląda znajomo. A jednak już po kilku minutach staje się jasne, że zakład nie odzyskał dokładnie tego samego procesu.

Właśnie w takich momentach wychodzi na jaw różnica między tym, co pamięta maszyna, a tym, co pamięta zakład. Maszyna zachowuje tylko to, co zostało w niej naprawdę zapisane i utrwalone we właściwym miejscu. Zakład pamięta znacznie więcej. Pamięta, które nastawy dawały stabilną produkcję, jakie korekty były dopisywane po uruchomieniu, które wartości zostały zmienione już po oddaniu maszyny, jakie odchyłki były akceptowalne, a które powodowały problem z jakością. Ta wiedza przez lata narasta w głowach ludzi, w notatkach serwisu, w recepturach, w parametrach napędów, w ustawieniach panelu i w drobnych zmianach, które nigdy nie trafiły do jednego pełnego archiwum. Gdy pojawia się przestój, restart albo wymiana elementu, okazuje się nagle, że urządzenie wróciło do życia, ale nie wróciło do tego samego stanu pracy.

Co naprawdę wraca po przestoju, a co tylko sprawia takie wrażenie

Najłatwiej rozpoznać ten problem po objawach, które na początku wyglądają niewinnie. Maszyna rusza bez alarmów, ale wydłuża się czas cyklu. Linia kończy sekwencję, lecz pierwsze partie mają gorszą powtarzalność. Oś bazuje się poprawnie, a mimo to dokładność odkładania albo pozycjonowania nie jest już taka jak wcześniej. Operator częściej wprowadza korekty ręczne, wracają starsze nastawy na panelu, receptura wygląda poprawnie, ale efekt procesu już nie. To właśnie są sygnały, że nie musi chodzić o nową awarię sprzętową, tylko o to, że część pamięci procesu nie wróciła razem z uruchomieniem maszyny.

Problem może dotyczyć kilku warstw. W sterowniku problem może dotyczyć retencji, liczników, znaczników stanu, aktywnej receptury lub wartości rozruchowych, które po restarcie wracają do starszej albo domyślnej postaci. W przypadku panelu operatorskiego najczęściej chodzi o receptury, limity, nastawy operatorskie i parametry, które formalnie nadal istnieją, ale nie odpowiadają już ustawieniom używanym przez maszynę przed zatrzymaniem. Z kolei w napędach układ może odzyskać zdolność ruchu, a mimo to nie zachować wcześniejszej dokładności, jeśli nie zostały przywrócone offsety, pozycje odniesienia, punkty teach-in lub parametry osi dopracowane podczas pracy na obiekcie. Dlatego maszyna może sprawiać wrażenie w pełni odtworzonej, choć w rzeczywistości odzyskała jedynie część pamięci procesu.

Moment, w którym diagnostyka zaczyna błądzić

Zespół UR widzi zmianę zachowania i automatycznie szuka nowego uszkodzenia. Podejrzenie pada na sterownik, HMI, napęd, enkoder, mechanikę albo sieć komunikacyjną. Taki tok myślenia jest zrozumiały, ale w wielu przypadkach prowadzi do wymiany sprawnych elementów i do coraz większego chaosu w diagnozie.

Problem nie musi polegać na tym, że pojawiła się nowa awaria sprzętowa. Bardzo często ujawnia się wcześniej niewidoczna słabość odtworzenia. Układ wrócił do stanu technicznie poprawnego, lecz nie wrócił do ostatniego dobrego stanu procesu. Dla produkcji to ogromna różnica, bo nie chodzi już o sam fakt ruchu, ale o powtarzalność, jakość

i przewidywalność działania. Im dłużej zespół zakłada, że wszystko zostało odtworzone poprawnie, tym większe ryzyko, że zacznie leczyć objawy zamiast przyczyny.

Maszyna rusza, ale proces nadal nie wrócił

Ten etap bywa najbardziej mylący. Układ nie stoi, alarmy nie wskazują jednoznacznej awarii, a mimo to produkcja nie odzyskuje wcześniejszej przewidywalności. Zespół widzi, że maszyna wykonuje sekwencję i reaguje na polecenia, więc naturalnie rośnie pokusa, by uznać, że proces zasadniczo wrócił, a pozostały już tylko drobne odchylenia do skorygowania.

Operator dopisuje własne korekty, technolog przywraca część nastaw z pamięci, serwis poprawia pojedyncze parametry, a maszyna z każdą godziną coraz mniej opiera się na spójnym odtworzeniu, a coraz bardziej na doraźnych działaniach. Z zewnątrz wygląda to jak powrót do produkcji, ale w rzeczywistości bywa początkiem długiego procesu powrotu do stanu, który przed przestojem był stabilny i znany zespołowi.

Gdzie jeszcze ukrywa się pamięć procesu?

Pamięć procesu nie kończy się na PLC, HMI i głównym napędzie. W wielu aplikacjach ważne są także falowniki pomocnicze, regulatory temperatury, systemy wizyjne, wagi, czytniki, moduły komunikacyjne, urządzenia bezpieczeństwa oraz lokalne sterowniki obsługujące wybrane fragmenty maszyny.

Każdy z tych elementów może przechowywać własne parametry i własną część logiki procesu. Jeśli po przestoju odtworzymy tylko główny sterownik, a resztę potraktujemy jako tło, układ może ruszyć, ale nie wróci do stanu, który zakład uznawał za sprawdzony.

Stąd bierze się złudzenie, że maszyna pamięta więcej, niż naprawdę pamięta. Przez miesiące albo lata nikt tego nie weryfikuje. Maszyna po prostu pracuje. Prawdziwy test przychodzi dopiero wtedy, gdy trzeba odtworzyć całość pod presją czasu. Wtedy wychodzi na jaw, czy zakład miał rzeczywisty pakiet odtworzeniowy, czy tylko zbiór plików z różnych okresów.

Dlaczego sam plik nie daje jeszcze pełnego odtworzenia?

Dobry backup nie powinien oznaczać jedynie obecności pliku na serwerze, dysku sieciowym albo karcie pamięci. Sam projekt PLC bardzo często obejmuje tylko część tego, co decyduje

o zachowaniu maszyny po przestoju. Poza nim zostają kopia HMI, receptury, parametry falowników i serwonapędów, dane osi, wartości retencyjne, konfiguracje urządzeń zewnętrznych oraz informacja, która wersja była ostatnią wersją produkcyjnie poprawną. Pełne odtworzenie powinno obejmować nie tylko aplikację i konfigurację, ale również aktualne limity pracy i nastawy procesu.

Pełne odtworzenie wymaga więc nie tylko archiwum danych, ale też uporządkowanego procesu powrotu do pracy. Trzeba wiedzieć, co odtwarzamy, w jakiej kolejności, kto potwierdza zgodność wersji, które parametry muszą być sprawdzone przed wznowieniem produkcji i po czym uznajemy, że układ wrócił do stabilnej pracy. Bez tego zakład ma wprawdzie pliki, ale nadal nie ma pewności odtwarzalności.

Najtrudniej odzyskać nie program, lecz ciągłość procesu

Ciągłość procesu decyduje, czy maszyna po postoju nadal pracuje w sposób przewidywalny, czy tylko wykonuje ruchy w przybliżeniu podobne do wcześniejszych. Z punktu widzenia produkcji ta różnica bywa droższa niż sama awaria, bo nie zatrzymuje wszystkiego od razu, tylko rozmywa zaufanie do procesu. Pojawiają się drobne odchylenia, korekty robi się

w biegu, rośnie liczba prób, a zespół coraz trudniej odróżnia stan prawidłowy od stanu jedynie akceptowalnego.

To jest również moment niebezpieczny z punktu widzenia bezpieczeństwa i ryzyka uszkodzeń wtórnych. Jeżeli po restarcie nie wróciły właściwe pozycje referencyjne, offsety, limity ruchu, warunki bezpiecznego restartu albo zależności między osiami i strefami pracy, maszyna może wykonywać ruch formalnie poprawny, ale już niezgodny ze stanem sprzed zatrzymania. Wtedy skutkiem nie musi być wyłącznie gorsza jakość procesu. Może dojść do kolizji, wejścia w niewłaściwą strefę, uszkodzenia narzędzia, przeciążenia mechaniki albo zachowania ryzykownego dla obsługi. Niepełne odtworzenie nie jest więc miękkim problemem organizacyjnym. To realne ryzyko techniczne i bezpieczeństwa.

Co powinien zawierać pakiet odtworzeniowy maszyny?

Rzeczywisty pakiet odtworzeniowy maszyny powinien łączyć dane i procedurę. Musi zawierać aktualny projekt PLC, kopię HMI, parametry napędów, dane osi, receptury, najważniejsze nastawy technologiczne, konfiguracje urządzeń zewnętrznych i jasną informację, która wersja była ostatnią wersją produkcyjnie poprawną.

Do tego potrzebna jest krótka procedura mówiąca, co odtwarzamy, w jakiej kolejności, kto potwierdza zgodność i które punkty kontrolne trzeba przejść przed wznowieniem produkcji. Sama obecność plików nie wystarcza.

Druga rzecz jest jeszcze ważniejsza. Taki pakiet trzeba okresowo weryfikować, a nie tylko posiadać. Trzeba sprawdzić, czy z przygotowanych kopii rzeczywiście da się odtworzyć maszynę i przywrócić ostatni dobry stan procesu. Jeżeli nikt tego nie testował, zakład ma jedynie przekonanie, że backup istnieje. A to zdecydowanie za mało w środowisku, w którym jeden restart potrafi oddzielić zwykły przestój od długiego i kosztownego dochodzenia do dawnej stabilności.

Leszek Ochmann, CEO i założyciel PLE Service serwisu automatyki i elektroniki przemysłowej. Pod jego kierownictwem, zespół inżynierów z powodzeniem przywraca sprawność urządzeniom praktycznie każdego producenta, niezależnie od wieku i stopnia skomplikowania. Ponad 37 000 zrealizowanych napraw w 2 500 fabrykach, w tym w zakładach takich firm jak Bosch, LG, Volkswagen, Danone czy Electrolux, to dowód skuteczności i zaufania, jakim klienci obdarzają PLE Service.

Autor: Zespół PLE Service

Może Cię również zainteresować: BWP Borsuk z nagrodą: HSW skaluje produkcję