Migracja komentarzy szczebli w RSLogix 500: przypisywanie komentarzy do adresu wyjścia

Komentarze szczebli w projekcie RSLogix 500 są częścią bazy danych inżynierskich, a nie wykonywanej logiki procesora. Dlatego łatwo je zaniedbać i łatwo uszkodzić podczas porządkowania lub migracji. Gdy komentarze pojawiają się przy niewłaściwych szczeblach po wstawieniu, skopiowaniu lub reorganizacji logiki, należy ustalić tryb przypisania, zachować punkt odniesienia i zweryfikować wynik w kopii offline przed wprowadzeniem zmian do archiwum produkcyjnego.

Wybrany sposób przypisania określa, czy dokumentacja podąża za numerem szczebla, czy za adresem powiązanym ze szczeblem.

Zrozum, co właściwie się przemieszcza

RSLogix 500 może powiązać dokumentację szczebla z lokalizacją pliku i szczebla albo z adresem wyjścia. Komentarz oparty na lokalizacji jest przydatny, gdy plik ma pozostać niezmienny, jednak edycje powyżej danego szczebla mogą oddzielić opis od logiki, którą miał wyjaśniać. Przypisanie do adresu może sprawić, że komentarz będzie podążał za wybranym adresem wyjścia, gdy logika zostanie przeniesiona. Nota pomocy technicznej Rockwell dotycząca tytułów zaimportowanych z AI500 potwierdza, że oprogramowanie udostępnia tryb przypisania i może konwertować dokumentację między powiązaniem z wyjściem a powiązaniem z numerem szczebla.

Żaden z tych trybów nie jest zawsze właściwy. Szczebel może nie zawierać instrukcji wyjściowej, zawierać kilka wyjść, wyjście o adresie używanym w innym miejscu albo instrukcję przenoszoną w ramach większej refaktoryzacji. Komentarz oparty na adresie może więc pojawić się na więcej niż jednym szczeblu, a komentarz oparty na numerze szczebla może pozostać na miejscu, gdy jego logika zostanie przeniesiona. Traktuj przypisanie jako kontrolowaną regułę dokumentacji, a nie jako automatyczny przycisk naprawy.

Zabezpiecz źródło przed edycją

Zapisz oryginalny plik RSS jako tylko do odczytu i zanotuj jego sumę kontrolną, nazwę sterownika, wersję programu oraz datę przesłania. Wyeksportuj lub wydrukuj bazę danych i komentarze szczebli w formie umożliwiającej późniejsze porównanie. Jeśli projekt jest przesyłany ze sterownika, pamiętaj, że opisy i komentarze mogą nie być przechowywane w procesorze SLC w taki sam sposób jak logika drabinkowa. Przesłanie może odzyskać logikę, a jednocześnie pozostawić projekt bez prawidłowej lokalnej bazy dokumentacji.

Pracuj na kopii pliku. Wybierz kilka przypadków testowych: zwykły szczebel z OTE, parę OTL i OTU, szczebel z wieloma wyjściami, szczebel bez oczywistego wyjścia oraz podprogram, do którego zostanie dodana nowa logika. Dla każdego przypadku zanotuj bieżący numer pliku, numer szczebla, wybrany adres kotwicy i treść komentarza.

Dobierz przypisanie do intencji inżynierskiej

Użyj przypisania do adresu wyjścia, gdy wyjście jednoznacznie identyfikuje funkcję, a szczebel prawdopodobnie będzie przenoszony. Komenda pracy silnika, bit stanu sekwencji lub zatrzask alarmu mogą zapewnić trwałą kotwicę, jeśli dany adres jest objęty standardem nazewnictwa i nie jest ponownie używany. Komentarz powinien koncentrować się na przeznaczeniu, blokadach oraz nietypowym zachowaniu funkcji, zamiast powtarzać opis symbolu.

Użyj przypisania do pliku i numeru szczebla, gdy opis dotyczy lokalizacji lub sekcji, a nie jednego adresu. Przykłady obejmują uwagi dotyczące przejść, obliczenia diagnostyczne, logikę inicjalizacji albo szczebel zawierający kilka powiązanych wyjść. W takich przypadkach wymuszanie wstawienia bitu przeznaczonego wyłącznie do dokumentacji do wykonywanej logiki może zwiększyć ryzyko utrzymania. Nie dodawaj nieużywanych instrukcji do działającej maszyny tylko po to, aby spełnić konwencję komentarzy.

Pary zatrzasku i kasowania zatrzasku wymagają szczególnej uwagi, ponieważ często współdzielą ten sam adres. Opis na poziomie adresu powinien wyjaśniać znaczenie stanu zatrzaśniętego. Komentarze właściwe dla szczebli powinny wyjaśniać, co ustawia ten stan, co go kasuje oraz jakie warunki zezwalające mają zastosowanie. Jeśli jeden wspólny komentarz nie może bezpiecznie opisać obu działań, pozostaw szczegółowe uwagi przypisane do lokalizacji i używaj spójnych symboli oraz opisów adresów do wzajemnych odwołań.

Współdzielone adresy wymagają reguły dokumentacji odróżniającej znaczenie stanu od przyczyny działania poszczególnych szczebli.

Migruj komentarze w kontrolowanych partiach

Rozpocznij od jednego pliku programu, a nie od całego projektu. Przed zmianą przypisania porównaj każdy komentarz z oryginalnym raportem. Ponownie przypisuj tylko te komentarze, których zamierzona logika jest jednoznaczna. Wstaw tymczasowy szczebel testowy nad przykładową logiką w kopii offline, przenieś przykładowy szczebel w obrębie pliku i skopiuj jeden przykład między plikami. Sprawdź, które komentarze się przemieszczają, a które pozostają przypisane do lokalizacji.

Po każdej partii wyszukaj puste komentarze, zduplikowany tekst, komentarze przypisane do nieoczekiwanych adresów oraz adresy wyjść używane na wielu szczeblach. Wykonaj odwołania skrośne dla każdej kotwicy. Bit, który wygląda na unikatowy, może być nadal zapisywany przez instrukcję kasowania zatrzasku, instrukcję przeniesienia, operację na pliku lub inną procedurę. Jeśli zależność jest niepewna, pozostaw komentarz źródłowy bez zmian i oznacz go do weryfikacji przez inżyniera automatyki znającego sekwencję maszyny.

Weryfikuj na granicach oprogramowania i archiwum

W miarę możliwości otwórz edytowaną kopię w dokładnie tej wersji RSLogix 500, która jest używana w zakładzie. Następnie ponownie otwórz zapisany plik i powtórz testy wstawiania oraz przenoszenia. Konwersje między wersjami i importy baz danych należy traktować jako osobne migracje. Oficjalny Podręcznik referencyjny zestawu instrukcji SLC 500 pozostaje głównym źródłem informacji o działaniu instrukcji, jednak przypisywanie dokumentacji jest zachowaniem programowej bazy danych i musi zostać zweryfikowane w zainstalowanym środowisku RSLogix.

Wykonaj porównanie logiki, aby potwierdzić, że zmiana dotycząca wyłącznie dokumentacji nie zmieniła wykonywanych szczebli, rozmiarów tablic danych, konfiguracji kanałów ani ustawień procesora. Naprawa komentarzy nie powinna stać się niezweryfikowaną zmianą sterowania. Przed zastąpieniem pliku głównego postępuj zgodnie z zakładowymi procedurami tworzenia kopii zapasowych, zatwierdzania i pobierania programu.

Uczyń konwencję łatwą w utrzymaniu

Dodaj regułę przypisywania do standardu programowania i listy kontrolnej przeglądu kodu. Wymagaj aktualnego archiwum RSS przy każdej zatwierdzonej edycji oraz utrzymuj synchronizację komentarzy z symbolami, rysunkami elektrycznymi i tekstami alarmów HMI. W przypadku maszyn pozostających na platformie SLC powiąż odpowiedzialność za dokumentację z szerszym planem cyklu życia systemów PLC i PAC oraz zakładowymi praktykami edycji online w RSLogix 500.

Najlepszy tryb przypisania to ten, który zachowuje znaczenie podczas zmian rzeczywiście wykonywanych w zakładzie. Zweryfikowany punkt odniesienia, jednoznaczne reguły wyboru, testowanie partiami i porównanie po zapisaniu zapobiegają przekształceniu kosmetycznego problemu z bazą danych w zagrożenie podczas diagnostyki.