Zugriff auf Gerät und Peripherie
Ein-/Ausgänge, Feldbus, Antriebe, gerätespezifische Bibliotheken und Laufzeitabhängigkeiten werden von fachlicher Maschinenlogik unterscheidbar gemacht.
CODESYS 2.3 · CODESYS 3.5
CODESYS-Engineering für gewachsene Steuerungen.
CODESYS-Programmierung für gewachsene Projekte: laufenden Stand verstehen, Abhängigkeiten sichtbar machen, Änderungen versionierbar führen und Tests von der realen Maschinenvalidierung trennen.
Legacy ist ein Systemzustand
Ein CODESYS-Projekt besteht nicht nur aus seinem Quellcode.
Laufzeit, Zielgerät, Bibliotheken, Persistenz, Kommunikation, Visualisierung und reale Peripherie prägen das Verhalten genauso wie die sichtbare Programmlogik.
Bevor geändert oder migriert wird, muss klar sein, welcher Projektstand zur Maschine gehört, wie er gebaut wird und welche Annahmen nur historisch überliefert sind. CODESYS 2.3 und 3.5 werden dabei nicht als austauschbare Dateiformate behandelt.
Beherrschbare Struktur
Technische Grenzen im Projekt sichtbar machen.
Die ideale Trennung lässt sich nicht jedem Legacy-Bestand nachträglich aufzwingen. Sie dient als Prüfmodell für gezielte, risikoarme Verbesserungen.
Abläufe, Zustände und Verriegelungen
Maschinenlogik wird über Zustandsfolgen, Datenflüsse und definierte Schnittstellen nachvollziehbar. Änderungen erhalten einen klaren fachlichen Umfang.
Visualisierung und externe Datenwege
HMI, Meldungen, Parameter, OPC-UA-Daten und weitere Schnittstellen werden als eigenständige Verbraucher und Auslöser der Logik betrachtet.
Repository-geführtes Vorgehen
Vom unbekannten Projektstand zu einer prüfbaren Änderung.
Bestand abgleichen
Vorhandene Projektdateien, Exporte, CODESYS-Version, Zielgerät, Runtime, Bibliotheken und der tatsächlich laufende Stand werden soweit möglich miteinander abgeglichen.
Abhängigkeiten kartieren
Hardwarezugriff, Maschinenlogik, Bedienung, Kommunikation, Persistenz und projektspezifische Werkzeuge werden als technische Beziehungen festgehalten.
Führenden Stand festlegen
Das Repository erhält einen nachvollziehbaren Referenzstand. Der geeignete Export-/Importweg und die Regeln für generierte oder binäre Projektanteile werden für das konkrete CODESYS-Projekt dokumentiert.
Import, Build und Transfer prüfen
Der Weg vom Repository in die passende CODESYS-Umgebung, zum reproduzierbaren Build und zum kontrollierten Transfer wird schrittweise abgesichert.
Tests und Evidence mitführen
Prüfschritte, Ergebnisse, offene Annahmen und Änderungen entstehen parallel zum Code. Logiktest oder DryRun werden nur dort eingesetzt, wo der konkrete Bestand sie belastbar zulässt.
Reale Maschine getrennt validieren
Hardware-, Timing-, Sicherheits- und Prozessverhalten werden in einer eigenen Phase am passenden Prüfstand oder an der Maschine geprüft. Frühe Nachweise ersetzen diese Phase nicht.
CODESYS 2.3 auf 3.5
Konvertierung ist nicht gleich Migration.
Ein öffnendes Projekt oder ein erfolgreicher Build beantwortet noch nicht, ob Laufzeit, Bibliotheken, Gerätezugriff und Maschinenverhalten gleich geblieben sind.
QuellmodellSyntax, Typen, Initialisierung und Struktur
PlattformZielgerät, Runtime und Gerätebeschreibungen
AbhängigkeitenBibliotheken, Kommunikation und Persistenz
VerhaltenTiming, Peripherie, Bedienung und Prozess
Ein konkretes Beispiel für diese Arbeitsweise
Aktueller Praxisstand in einer gewachsenen Maschinensteuerung
In einem laufenden Maschinenbauprojekt arbeite ich an der Aufarbeitung eines gewachsenen CODESYS-2.3/3.5-Bestands.
Legacy-Logik und Abhängigkeiten werden aus vorhandenen Projektständen und Exporten rekonstruiert, schrittweise in einen Repository-geführten Quellstand überführt und gemeinsam mit Dokumentation, offenen fachlichen Fragen und Prüf-Nachweisen weiterentwickelt. CODESYS dient dabei für Import, Build und Transfer. Reale Maschinenvalidierung und physische Ausgänge bleiben getrennte Schritte.
- Aufruf- und Datenflüsse aus vorhandenen Projektständen und Exporten nachvollziehbar machen
- Hardwarezugriff, Bedienung und Maschinenlogik technisch voneinander abgrenzen
- Repository, Import, Build und Transfer als zusammenhängenden Arbeitsweg führen
- DryRun, Prüf-Nachweise, physische Ausgangsfreigabe und reale Maschinenvalidierung klar trennen
Der Ansatz ist an einem konkreten Bestand entstanden. Bei einem weiteren Maschinentyp wird zunächst begrenzt geprüft, welche Teile übertragbar sind und welche projektspezifisch bleiben.
Kommerzieller Rahmen: Phasenweise nach Sichtung des Bestands. Eine automatische Komplettmigration oder Übertragbarkeit ohne Bestandsprüfung wird nicht versprochen.
Fragen und Grenzen
Fragen zu CODESYS und Legacy-Steuerungen
Wird CODESYS 2.3 automatisch vollständig auf CODESYS 3.5 migriert?
Nein. Eine Konvertierung ist nur ein technischer Zwischenschritt. Gerätebeschreibung, Runtime, Bibliotheken, Datentypen, Persistenz, Visualisierung, Kommunikation, Timing und Maschinenverhalten müssen am konkreten Bestand geprüft werden.
Kann ein CODESYS-Projekt ohne Zugriff auf die reale Maschine bearbeitet werden?
Analyse, Strukturierung, Import, Build und geeignete Logikprüfungen können je nach Projektstand außerhalb der Maschine vorbereitet werden. Die abschließende Bewertung realer Ein-/Ausgänge, Feldbusse, Antriebe, Timing- und Prozessverhalten bleibt eine getrennte Validierungsphase.
Was bedeutet Repository als führender Quellstand?
Der nachvollziehbar versionierte und prüfbare Stand im Repository wird zur fachlichen Referenz. Der passende Export-, Import-, Build- und Transferweg hängt von CODESYS-Version, Zielsystem und Projektstruktur ab und wird für den Bestand ausdrücklich festgelegt.
Wie beginnt die Zusammenarbeit bei einem weiteren Maschinentyp?
Der Einstieg wird bewusst auf einen repräsentativen und technisch begrenzten Umfang zugeschnitten. Dabei wird geprüft, welche Teile des Vorgehens übertragbar sind, welche projektspezifisch bleiben und welche Nachweise vor einer Ausweitung fehlen.
Weiter im System
CODESYS fachlich vertiefen
MIGRATIONCODESYS 2.3 auf 3.5Warum Projektkonvertierung, Laufzeitwechsel und reale Verhaltensprüfung getrennte Aufgaben sind.TESTBARKEITSPS-Software testenWelche Aussagen Quellcodeanalyse, Build, DryRun und reale Maschine jeweils erlauben.STEUERUNGSPS-ProgrammierungÄnderungen und Teamunterstützung in gewachsenen Maschinensteuerungen einordnen.
CODESYS-Bestand abgleichen
Projektstand, Zielgerät und gewünschte Änderung sind bekannt – der sichere Weg dazwischen noch nicht?
Nennen Sie CODESYS-Version, Steuerung beziehungsweise Runtime, verfügbare Projektstände und den betroffenen Maschinentyp. Der erste Umfang wird so gewählt, dass seine Übertragbarkeit und Grenzen sichtbar werden.