RSLogix 500: Migration von Kontaktplan-Kommentaren – Kommentare an Ausgangsadresse anhängen

Rung-Kommentare in einem RSLogix-500-Projekt sind Teil der Engineering-Datenbank und keine ausführbare Prozessorlogik. Dadurch werden sie leicht vernachlässigt und können bei einer Bereinigung oder Migration leicht beschädigt werden. Wenn Kommentare nach dem Einfügen, Kopieren oder Neuorganisieren von Logik an den falschen Rungs erscheinen, sollte man zunächst den Zuordnungsmodus ermitteln, eine Ausgangsbasis sichern und das Ergebnis in einer Offline-Kopie prüfen, bevor das Produktionsarchiv geändert wird.

Die Wahl der Zuordnung bestimmt, ob die Dokumentation einer Rung-Nummer oder einer mit der Rung verbundenen Adresse folgt.

Verstehen, was tatsächlich verschoben wird

RSLogix 500 kann die Rung-Dokumentation entweder mit der Datei und der Rung-Position oder mit einer Ausgangsadresse verknüpfen. Ein positionsbasierter Kommentar ist nützlich, wenn eine Datei absichtlich unverändert strukturiert bleibt. Werden jedoch Rungs oberhalb dieser Rung bearbeitet, kann sich die Beschreibung von der Logik trennen, die sie erklären sollte. Bei einer Zuordnung zur Adresse kann der Kommentar der ausgewählten Ausgangsadresse folgen, wenn sich die Logik verschiebt. Rockwells Support-Hinweis zu importierten AI500-Titeln bestätigt, dass die Software einen Zuordnungsmodus bereitstellt und die Dokumentation zwischen der Zuordnung zu Ausgang und Rung-Nummer umwandeln kann.

Keiner der beiden Modi ist grundsätzlich immer richtig. Eine Rung kann keine Ausgangsanweisung, mehrere Ausgänge, einen Ausgang mit einer an anderer Stelle wiederverwendeten Adresse oder eine Anweisung enthalten, die im Rahmen einer größeren Umstrukturierung verschoben wird. Ein adressbasierter Kommentar kann daher auf mehr als einer Rung erscheinen, während ein Rung-Nummer-Kommentar an seiner Position verbleiben kann, wenn sich die zugehörige Logik verschiebt. Betrachten Sie die Zuordnung als kontrollierte Dokumentationsregel und nicht als automatische Reparaturfunktion.

Die Quelle vor der Bearbeitung schützen

Speichern Sie die ursprüngliche RSS-Datei schreibgeschützt und dokumentieren Sie ihre Prüfsumme, den Controllernamen, die Programmversion und das Upload-Datum. Exportieren oder drucken Sie die Datenbank sowie die Rung-Kommentare in einer Form, die später verglichen werden kann. Wenn das Projekt von einem Controller hochgeladen wird, ist zu beachten, dass Beschreibungen und Kommentare möglicherweise nicht auf dieselbe Weise im SLC-Prozessor gespeichert werden wie die Kontaktplanlogik. Ein Upload kann die Logik wiederherstellen, während die korrekte Offline-Dokumentationsdatenbank weiterhin im Projekt fehlt.

Arbeiten Sie mit einer duplizierten Datei. Wählen Sie mehrere Testfälle: eine normale OTE-Rung, ein OTL- und OTU-Paar, eine Rung mit mehreren Ausgängen, eine Rung ohne offensichtlichen Ausgang und ein Unterprogramm, in das neue Logik eingefügt werden soll. Notieren Sie für jeden Fall die aktuelle Dateinummer, Rung-Nummer, ausgewählte Ankeradresse und den Kommentartext.

Die Zuordnung nach der Engineering-Absicht auswählen

Verwenden Sie die Zuordnung zur Ausgangsadresse, wenn der Ausgang die Funktion eindeutig identifiziert und die Rung wahrscheinlich verschoben wird. Ein Motorlaufbefehl, ein Sequenzstatus-Bit oder eine Alarmverriegelung kann einen dauerhaften Anker bilden, sofern diese Adresse durch einen Benennungsstandard geregelt und nicht wiederverwendet wird. Beschränken Sie den Kommentar auf Zweck, Verriegelungen und abweichendes Verhalten der Funktion, statt die Symbolbeschreibung zu wiederholen.

Verwenden Sie die Zuordnung zu Datei und Rung, wenn die Beschreibung zu einer Position oder einem Abschnitt und nicht zu einer einzelnen Adresse gehört. Beispiele sind Übergangshinweise, Diagnoseberechnungen, Initialisierungslogik oder eine Rung mit mehreren zusammengehörigen Ausgängen. In solchen Fällen kann das Erzwingen eines reinen Dokumentations-Bits in die ausführbare Logik allein zum Transport eines Kommentars ein Wartungsrisiko darstellen. Fügen Sie einer laufenden Maschine keine ungenutzten Anweisungen hinzu, nur um einer Kommentar-Konvention zu entsprechen.

Selbsthalte- und Rücksetzpaare verdienen besondere Aufmerksamkeit, da sie häufig dieselbe Adresse verwenden. Eine adressbezogene Beschreibung sollte die Bedeutung des gespeicherten Zustands erklären. Rung-spezifische Kommentare sollten erläutern, wodurch der Zustand gesetzt und gelöscht wird und welche Freigabebedingungen gelten. Wenn ein gemeinsamer Kommentar beide Aktionen nicht sicher beschreiben kann, sollten die ausführlichen Hinweise positionsbezogen bleiben und konsistente Symbole sowie Adressbeschreibungen für Querverweise verwendet werden.

Gemeinsam genutzte Adressen erfordern eine Dokumentationsregel, die die Bedeutung des Zustands vom Grund für die Aktion der jeweiligen Rung unterscheidet.

Kommentare in kontrollierten Chargen migrieren

Beginnen Sie mit einer Programmdatei und nicht mit dem gesamten Projekt. Vergleichen Sie jeden Kommentar mit dem ursprünglichen Bericht, bevor Sie seine Zuordnung ändern. Ordnen Sie nur Kommentare neu zu, deren beabsichtigte Logik eindeutig ist. Fügen Sie in der Offline-Kopie oberhalb der Beispiel-Logik eine temporäre Test-Rung ein, verschieben Sie eine Beispiel-Rung innerhalb der Datei und kopieren Sie ein Beispiel zwischen Dateien. Beobachten Sie, welche Kommentare mitwandern und welche an ihre Position gebunden bleiben.

Suchen Sie nach jeder Charge nach leeren Kommentaren, doppelten Texten, Kommentaren mit unerwarteten Adressen und Ausgangsadressen, die auf mehreren Rungs verwendet werden. Führen Sie für jeden Anker Querverweise aus. Ein scheinbar eindeutiges Bit kann dennoch durch eine Rücksetzanweisung, eine Verschiebeanweisung, eine Dateioperation oder eine andere Routine geschrieben werden. Wenn die Beziehung unklar ist, lassen Sie den Quellkommentar unverändert und kennzeichnen Sie ihn für einen Steuerungstechniker, der den Maschinenablauf kennt.

Über Software- und Archivgrenzen hinweg validieren

Öffnen Sie die bearbeitete Kopie nach Möglichkeit mit genau der am Standort verwendeten RSLogix-500-Version. Öffnen Sie anschließend die gespeicherte Datei erneut und wiederholen Sie die Testeinfügungen und -verschiebungen. Konvertierungen zwischen Versionen und Datenbankimporte sollten jeweils als eigene Migrationen behandelt werden. Das offizielle Referenzhandbuch zum SLC-500-Befehlssatz bleibt die primäre Quelle für das Verhalten von Anweisungen. Die Zuordnung der Dokumentation ist jedoch ein Verhalten der Software-Datenbank und muss in der installierten RSLogix-Umgebung überprüft werden.

Führen Sie einen Logikvergleich durch, um zu bestätigen, dass eine reine Dokumentationsänderung am Projekt keine ausführbaren Rungs, Datenmengengrößen, Kanal-Konfigurationen oder Prozessoreinstellungen verändert hat. Eine Kommentarreparatur darf nicht zu einer ungeprüften Steuerungsänderung werden. Befolgen Sie die standortspezifischen Sicherungs-, Freigabe- und Download-Verfahren, bevor Sie die Masterdatei ersetzen.

Die Konvention wartbar machen

Nehmen Sie die Zuordnungsregel in den Programmierstandard und die Checkliste für Code-Reviews auf. Fordern Sie mit jeder freigegebenen Änderung ein aktuelles RSS-Archiv und halten Sie Kommentare mit Symbolen, Elektroschaltplänen und HMI-Alarmtexten synchron. Für Maschinen, die weiterhin auf der SLC-Plattform betrieben werden, sollten Sie die Verantwortung für die Dokumentation am übergeordneten Lebenszyklusplan für PLC- und PAC-Systeme sowie an den standortspezifischen RSLogix-500-Verfahren zur Online-Bearbeitung ausrichten.

Der beste Zuordnungsmodus ist derjenige, der die Bedeutung bei den Änderungen bewahrt, die im Werk tatsächlich durchgeführt werden. Eine geprüfte Ausgangsbasis, eindeutige Auswahlregeln, Tests in Chargen und ein Vergleich nach dem Speichern verhindern, dass ein kosmetisches Datenbankproblem zu einer Gefahr bei der Fehlersuche wird.