Ein SPS-Programm konvertieren heißt in der Praxis: Die Logik wandert, das Drumherum muss neu gedacht werden. Verknüpfungen, Selbsthaltungen und Vergleiche lassen sich zuverlässig von KOP nach SCL oder Strukturiertem Text übertragen. Adressierung, Timer-Verhalten, Datentypen und Systembausteine unterscheiden sich zwischen Herstellern so stark, dass eine vollautomatische Konvertierung ohne Bericht nicht ehrlich wäre.

LADX Convert schreibt ein Programm als IEC 61131-3 Strukturierten Text, Siemens SCL, Rockwell-Neutraltext oder PLCopen XML aus und markiert dabei jedes Element: sauber übertragen, übertragen mit inhaltlichem Unterschied oder Entscheidung nötig. Wir zeigen, warum dieser Bericht wichtiger ist als die Konvertierung selbst.

Warum Konvertieren schwieriger ist, als es aussieht

Eine Selbsthaltung sieht in jedem KOP-Editor gleich aus. Darunter liegen unterschiedliche Modelle. Siemens adressiert Speicherbereiche wie %I0.0, ältere Allen-Bradley-Steuerungen adressierten Dateien und Steckplätze, ControlLogix arbeitet nur noch mit Variablennamen. Timer haben je nach Plattform andere Mitglieder und andere Aktualisierungsregeln. Auf der S7-1500 werden Ausgänge eines IEC-Timers bei jedem Zugriff aktualisiert, bei Rockwell fragen Sie .DN, .TT und .ACC ab.

ElementSiemens (TIA Portal)Rockwell LogixIEC 61131-3 ST
Adressierungsymbolisch, optional absolutnur Variablennamensymbolisch
EinschaltverzögerungTON als IEC-Timer (Q, ET)TON mit .DN, .TT, .ACCTON (Q, ET)
FlankenauswertungR_TRIG oder P-KontaktONSR_TRIG
BausteinaufrufFC, FB mit Instanz-DBJSR auf RoutineFUNCTION, FUNCTION_BLOCK

Dazu kommen Datentypen, Aufgabenmodelle und Bibliotheken. Rockwell beschreibt das eigene Austauschformat im Handbuch Logix 5000 Controllers Import/Export. Wer dort einmal nachgelesen hat, versteht, warum ein Konverter für jedes Plattformpaar schnell an seine Grenzen kommt.

Ein Zwischenformat statt eines Konverters für jedes Paar

LADX konvertiert nie direkt von Marke zu Marke. Jedes Programm wird in eine Zwischendarstellung auf Basis von PLCopen TC6 gelesen und aus ihr heraus geschrieben. Das hat einen praktischen Grund: Jeder neue Ausgang steht sofort für alle Eingänge zur Verfügung, und die vier Zielformate entstehen aus derselben Quelle, sodass sie nicht auseinanderlaufen. PLCopen beschreibt das XML-Austauschformat für IEC 61131-3 als offene Schnittstelle, die neben Text auch grafische Informationen wie die Lage und Verbindung von Funktionsbausteinen überträgt. Aktuell ist die Version 2.01 der Spezifikation.

LADX Convert mit einem KOP-Programm links und dem erzeugten Strukturierten Text samt Konvertierungsbericht rechts
LADX Convert: Jede Konvertierung kommt mit einem Bericht, was sauber übergegangen ist und was nicht (ladx.ai).

Eine Einschränkung nennt LADX selbst: Herstellerprojekte wieder einzulesen, also etwa eine L5X-Datei oder ein TIA-Archiv, ist die Hälfte, die noch nicht gebaut ist. Heute konvertiert Convert Programme, die Sie in LADX gezeichnet, erzeugt oder gespeichert haben. Ganze Projektformate wie .ACD oder .ap1x brauchen künftig eine Desktop-Brücke und Ihre eigene, lizenzierte Entwicklungsumgebung.

Was ein ehrlicher Konvertierungsbericht zeigt

  • Sauber übertragen: Kontakte, Spulen, Vergleiche, MOV und Arithmetik, deren Bedeutung auf allen Plattformen gleich ist.
  • Übertragen mit inhaltlichem Unterschied: etwa Timer, deren Aktualisierung sich unterscheidet. Diese Stellen sollten Sie lesen, bevor Sie testen.
  • Entscheidung nötig: Elemente ohne Entsprechung bleiben als kommentierter Platzhalter stehen. Nichts wird stillschweigend weggelassen oder umgedeutet.
  • Abgelehnt und erhalten: Netzwerke mit Brücken zwischen parallelen Zweigen haben keine Reihen-Parallel-Form und werden nicht angenähert.

Für Sie als Auftraggeber oder Prüfer ist dieser Bericht die eigentliche Arbeitsliste. Er sagt, wo ein Ingenieur hinschauen muss, statt eine Datei zu liefern, die übersetzt, sich aber anders verhält. Die Konvertierung läuft vollständig im Browser, das Programm wird nicht hochgeladen. Das ist bei Kundencode oft die Voraussetzung, überhaupt ein Werkzeug einsetzen zu dürfen.

PLCopen The Need for Software Structuring

PLCopen

Dieses Video wird von YouTube bereitgestellt. Beim Abspielen werden Inhalte von Google geladen, und es können Cookies gesetzt werden.

Auf YouTube ansehen
PLCopen erklärt, warum strukturierte Software die Voraussetzung für Wiederverwendung und Portierung ist (englisch).

Praxisablauf: Bandsteuerung von KOP nach SCL und ST

Ein typischer Fall: Eine Bandsteuerung mit Start, Stopp, Schutztürüberwachung und Nachlaufzeit soll auf einer S7-1500 und auf einer CODESYS-Steuerung beim Endkunden laufen. So gehen wir vor:

  1. Logik in LADX Ladder zeichnen oder erzeugen und mit dem Simulator prüfen, bis die Abläufe stimmen.
  2. In Convert nacheinander SCL und Strukturierten Text erzeugen und beide Berichte speichern.
  3. Alle Stellen mit inhaltlichem Unterschied und alle Platzhalter einzeln bewerten und im Bericht entscheiden.
  4. SCL im TIA Portal als externe Quelle einfügen, den Strukturierten Text in CODESYS übernehmen und in beiden Umgebungen übersetzen.
  5. Beide Programme gegen dieselben Testfälle laufen lassen, im TIA Portal etwa mit PLCSIM.
  6. Abweichungen, Entscheidungen und Testergebnisse dokumentieren.

Schritt 5 ist der wichtigste. Wie ein Software-in-the-Loop-Test mit der virtuellen S7-1500 aussieht, beschreiben wir im Beitrag zu PLCSIM Advanced. Die Sprachen selbst ordnet der Beitrag IEC 61131-3 Programmiersprachen ein. Die Norm ist übrigens im Mai 2025 als IEC 61131-3:2025 in der vierten Ausgabe erschienen, unter anderem mit UTF-8-Zeichenketten.

Vier Elektronikmodule des Siemens-Peripheriesystems SIMATIC ET 200S nebeneinander auf einem Maßstab
E/A-Baugruppen wie diese ET-200S-Module bleiben bei einer Konvertierung meist unverändert. Es ändert sich der Code, der sie anspricht, etwa in SCL oder Strukturiertem Text nach IEC 61131-3.

Stolpersteine, die wir bei Konvertierungen regelmäßig sehen

Die meisten Probleme zeigen sich nicht beim Übersetzen, sondern erst im Test. Vier Punkte prüfen wir in jedem Projekt gezielt, bevor wir überhaupt Testfälle schreiben:

  • Remanenz: Welche Zähler, Merker und Sollwerte müssen einen Spannungsausfall überleben? Siemens, Rockwell und CODESYS legen das an unterschiedlichen Stellen fest, und keine Konvertierung kann wissen, was der Anlagenbetreiber erwartet.
  • Datentypen: Ein INT auf der einen Plattform ist auf der anderen oft ein DINT. Vergleiche, Überläufe und Kommunikationsschnittstellen zu HMI oder Leitsystem verhalten sich dann anders, obwohl die Logik identisch aussieht.
  • Zyklus und Tasks: Ein Programm, das bisher im freien Zyklus lief, landet auf der Zielplattform vielleicht in einer periodischen Task. Flanken, Zeitglieder und Schrittketten reagieren darauf empfindlich.
  • Zeichenketten und Meldetexte: Umlaute in Störmeldungen sind ein Klassiker. Die neue Ausgabe der IEC 61131-3 bringt UTF-8-Zeichenketten, aber nicht jede Steuerung und jedes HMI unterstützt sie schon.

Unsere Faustregel: Planen Sie für das Lesen des Berichts und das Bewerten der markierten Stellen mindestens so viel Zeit ein wie für das Testen. Wer diese Arbeit überspringt, findet die Unterschiede später an der Maschine, im ungünstigsten Fall beim Kunden während der Abnahme.

Wann Sie eine Konvertierung lieber vergeben

Für einzelne Bausteine und Lernzwecke reicht ein Werkzeug. Eine plattformübergreifende Migration einer ganzen Maschine ist dagegen ein Projekt mit Bestandsaufnahme, Zielarchitektur, Test und Dokumentation. Für Siemens-Bestandsanlagen gibt es mit dem TIA Portal einen eigenen Weg, den wir unter S7-300 Migration auf S7-1500 beschreiben. Für den Wechsel zwischen Herstellern übernimmt Wartens die Arbeit als Paket im Automatisierungs-Engineering.

Nächster Schritt: Probieren Sie Convert mit einem kleinen eigenen Netzwerk auf ladx.ai aus. Steht eine Migration zwischen Plattformen an, senden Sie uns Programmauszug und Zielplattform über die Kontaktseite.