Błąd pułapki przepełnienia SLC 500 0020: naprawa zatrzasku S:5/0

Główny błąd SLC 500 0020H jest powszechnie opisywany jako błąd przepełnienia, ale kod ten obejmuje więcej niż tylko jedną nieprawidłową instrukcję ADD. Firma Rockwell definiuje go jako stan błędu podrzędnego, który pozostawał aktywny, gdy procesor dotarł do instrukcji END, TND lub REF, i dlatego został podniesiony do rangi błędu głównego. Zadanie diagnostyczne polega na ustaleniu, który bit stanu spowodował to podniesienie, określeniu, jaka operacja go ustawiła, oraz zdecydowaniu, czy kontrolowane odzyskanie działania jest bezpieczne.

Błąd 0020H powinien prowadzić do analizy pliku stanu, a nie do automatycznego wniosku, że sprzęt procesora uległ awarii.

Przed skasowaniem czegokolwiek odczytaj plik stanu

Przed zresetowaniem sterownika zapisz kod błędu, numer katalogowy procesora, tryb pracy, czas, stan produkcji oraz wartości S:5 i S:6. S:5/0 to pułapka przepełnienia matematycznego. S:5/2 wskazuje błąd rejestru sterowania pochodzący z instrukcji takich jak FIFO, przesunięcie bitowe lub operacje sekwencyjne. Inne bity S:5 również mogą zostać podniesione przy końcu skanu. Wyzerowanie procesora przed zapisaniem tych wartości niszczy dowody i zwiększa ryzyko ponownego wystąpienia tej samej awarii.

Podręcznik referencyjny zestawu instrukcji Rockwell SLC 500 stwierdza, że S:5/0 jest ustawiany, gdy wystąpi przepełnienie matematyczne, a główny błąd 0020H zostaje zgłoszony, jeśli bit ten nadal jest ustawiony podczas wykonywania END, TND lub REF. Podręcznik zaleca sprawdzenie bitu po wykonaniu odpowiedniej instrukcji, podjęcie właściwego działania, a dopiero potem wyzerowanie S:5/0 za pomocą OTU lub wyzerowanie odpowiedniego słowa stanu.

Rozumiej zarówno wynik matematyczny, jak i działanie pułapki

W przypadku ADD, SUB, MUL, DIV lub NEG wynik, którego nie można zapisać w miejscu docelowym, ustawia bit przepełnienia arytmetycznego S:0/1 oraz pułapkę S:5/0. Przy domyślnym stanie S:2/14 wynik dodatni jest ograniczony do 32767, a ujemny do -32768. Gdy S:2/14 jest ustawiony, zamiast tego w miejscu docelowym można zapisać 16 najmniej znaczących bitów. To ustawienie zmienia sposób obsługi miejsca docelowego; nie potwierdza jednak, że wynik aplikacji jest prawidłowy.

Instrukcje DDV oraz niektóre instrukcje konwersji lub skalowania mają dodatkowe zasady, dlatego analiza musi opierać się na dokładnym opisie danej instrukcji. Dzielenie przez zero, nieprawidłowa długość sterowania lub adres pośredni znajdujący się poza dozwolonym zakresem mogą prowadzić do innej ścieżki stanu. Nie należy przypisywać każdego zdarzenia 0020H do „przepełnienia liczby całkowitej” bez sprawdzenia S:5 i instrukcji wykonanej bezpośrednio przed ustawieniem bitu.

Znajdź pierwszą operację powodującą błąd

Przejrzyj ostatnie zmiany i porównaj je z każdą instrukcją mogącą ustawić zaobserwowany bit stanu. W przypadku przepełnienia matematycznego sprawdź obliczenia skalujące, sumy produkcyjne, konwersje jednostek, skumulowane wartości czasu pracy, ograniczenia liczb ze znakiem oraz wartości pośrednie. Obliczenie może być matematycznie prawidłowe w jednostkach inżynierskich, ale niebezpieczne, jeśli wartość pośrednia jest przechowywana jako 16-bitowa liczba całkowita.

Monitoruj lub rejestruj wartości operandów źródłowych, wartości docelowe, S:0/1 oraz S:5/0 wokół podejrzanych instrukcji. W systemie testowym działającym offline odtwórz przypadki graniczne: tuż poniżej dozwolonego zakresu, na jego granicy oraz powyżej niej. Jeśli wiele instrukcji może ustawić pułapkę podczas jednego skanu, dodaj tymczasowe zatrzaski diagnostyczne wskazujące pierwsze miejsce wystąpienia. Po ustaleniu przyczyny te bity diagnostyczne należy przejrzeć, nazwać i usunąć albo formalnie pozostawić.

Stosuj logikę odzyskiwania wyłącznie zgodnie z jasno określoną polityką

Bezwarunkowe OTU S:5/0 na ostatnim szczeblu może zapobiec podniesieniu błędu na końcu skanu, ale jednocześnie tłumi wyłączenie niezależnie od tego, które obliczenie spowodowało przepełnienie. Może to być dopuszczalne w przypadku niekrytycznego licznika, którego wartość jest ograniczana i sygnalizowana alarmem. Nie jest to dopuszczalne, gdy wynik wpływa na ruch, ciśnienie, temperaturę, dozowanie, ochronę urządzeń lub decyzję związaną z bezpieczeństwem.

Odporna logika sprawdza wynik instrukcji w miejscu jej wykonania. Przed wykonaniem zweryfikuj operandy, wybierz miejsce docelowe o odpowiednim zakresie, ograniczaj wartość tylko wtedy, gdy znaczenie procesu to uzasadnia, ustaw alarm diagnostyczny, podstaw udokumentowaną bezpieczną wartość, a następnie wyczyść pułapkę. Jeśli właściwą reakcją jest zatrzymanie sekwencji, zachowaj błąd zamiast wymuszać dalszą pracę procesora.

Procedura błędu użytkownika może wspierać kontrolowane odzyskiwanie działania dla wybranych zdarzeń, a podręcznik Rockwell zawiera przykład zliczający powtarzające się wystąpienia 0020H i ostatecznie umożliwiający wyłączenie. Taki schemat dostarcza więcej informacji niż bezwarunkowe kasowanie, ponieważ rozróżnia pojedyncze, obsłużone zdarzenie od powtarzającej się usterki. Samą procedurę błędu należy dokładnie przetestować; drugi błąd występujący w jej trakcie może nadpisać informacje diagnostyczne lub uniemożliwić odzyskanie działania.

Oddziel błędy oprogramowania od problemów sprzętowych

Pułapka przepełnienia zwykle wskazuje na dane programu i działanie instrukcji, a nie na awarię kasety. Mimo to niestabilne zasilanie, problemy z pamięcią lub niezamierzone zmiany programu mogą zmieniać dane i wymagają analizy, jeśli potwierdzają je dowody. Sprawdź baterię sterownika i historię zasilania, porównaj uruchomiony program z zatwierdzonym archiwum oraz ustal, czy operator HMI, komunikat lub system zewnętrzny zapisuje operandy, których dotyczy problem.

Nie wymieniaj procesora SLC jako pierwszej reakcji na powtarzalne przepełnienie matematyczne. Zastępczy procesor uruchamiający ten sam program z tymi samymi danymi odtworzy błąd. Jeśli platforma jest przestarzała, zarządzaj częściami zapasowymi i migracją zgodnie z planem cyklu życia zakładu dotyczącym systemów PLC i PAC, ale oddziel tę decyzję od bezpośredniej analizy przyczyny źródłowej.

Potwierdź skuteczność poprawki

Przetestuj poprawioną logikę dla wartości normalnych, obu granic zakresu, nieprawidłowych danych wejściowych, utraty komunikacji, pierwszego skanu oraz każdego warunku resetowania. Potwierdź, że alarmy wskazują dotknięte obliczenie, podstawiona wartość jest bezpieczna, a powtarzające się zdarzenia są zliczane. Obserwuj S:5/0 i S:0/1 podczas reprezentatywnego cyklu produkcyjnego i sprawdź, czy procesor nie ukrywa po prostu powtarzającego się przepełnienia.

Zarchiwizuj pliki RSS sprzed i po zmianie, dowody błędu, wyniki testów oraz uzasadnienie zastosowanej logiki odzyskiwania. Połącz tę dokumentację z zakładowymi wytycznymi dotyczącymi migracji skalowania SLC podczas modernizacji aplikacji. Błąd 0020H staje się możliwy do opanowania, gdy zespół traktuje go jako precyzyjny problem stanu i jakości danych, a nie jako bit, który należy od razu wyzerować.