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 Maschinenprüfung 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 hilft dabei, gezielte Verbesserungen zu planen und zu prüfen.
Abläufe, Zustände und Verriegelungen
Zustandsfolgen, Datenflüsse und definierte Schnittstellen machen die Maschinenlogik verständlich. Jede Änderung wird fachlich klar abgegrenzt.
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 festgelegten 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 geprüft.
Prüfungen und Ergebnisse festhalten
Prüfschritte, Ergebnisse, offene Annahmen und Änderungen werden zusammen mit dem Code festgehalten. Logiktest oder DryRun werden nur dort eingesetzt, wo der konkrete Bestand dafür geeignet ist.
Reale Maschine getrennt prüfen
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.
Dass sich ein Projekt öffnen und bauen lässt, 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
Eigener Entwicklungsstand
Eigene Test- und Simulationsumgebung für gewachsene CODESYS-Projekte.
Ich entwickle eine eigene Test- und Simulationsumgebung für ältere CODESYS-Projekte.
Ich trenne Quellstand, Build, Datenwege, simulierte Ein- und Ausgänge und die spätere Prüfung an der realen Maschine. So kann ich Änderungen früher untersuchen, Testfälle wiederholen und offene technische Fragen festhalten.
- Quellstände ordnen und Build-Schritte dokumentieren
- Hardwarezugriff und Maschinenlogik voneinander trennen
- Nur Testdaten verwenden, deren Herkunft geklärt ist
- Änderungen mit wiederholbaren Fällen prüfen
Die Umgebung ist keine freigegebene Maschinensteuerung und keine veröffentlichte Kundenreferenz. Die Freigabe physischer Ausgänge und die reale Maschinenprüfung bleiben ausdrücklich getrennte Schritte.
Kommerzieller Rahmen: Umfang und Budget werden nach Sichtung des Bestands phasenweise vereinbart. Ob eine vollständige Migration oder Übertragung möglich ist, lässt sich erst nach der Bestandsprüfung einschätzen.
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. Reale Ein-/Ausgänge, Feldbusse, Antriebe, Timing und Prozessverhalten müssen getrennt am passenden Prüfstand oder an der Maschine geprüft werden.
Was bedeutet Repository als führender Quellstand?
Als fachliche Referenz dient der im Repository versionierte Stand. 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 Arbeit an einem unbekannten CODESYS-Bestand?
Zunächst gleiche ich Quellstand, Werkzeugkette, Zielsystem, vorhandene Unterlagen und die konkrete Untersuchungsfrage ab. Erst danach lege ich fest, welche Analyse-, Änderungs- oder Testschritte in einem klar begrenzten Umfang sinnvoll und ohne unnötiges Risiko möglich sind.
Passende Themen
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 Build- und Transferweg aber noch nicht?
Nennen Sie CODESYS-Version, Steuerung beziehungsweise Runtime, verfügbare Projektstände und den betroffenen Maschinentyp. Danach lässt sich ein erster, prüfbarer Arbeitsumfang festlegen.