Warum ein Logik-Editor in einer Simulationssoftware?
Wer Materialflusssimulation betreibt, kennt das Problem: Die Simulation zeigt, dass ein Engpass entsteht — aber nicht, warum die SPS-Steuerung an einer Station den Takt verschleppt. Zwischen dem abstrakten Simulationsmodell und dem realen SPS-Programm klafft eine Lücke, die in der Praxis zu wochenlangen Inbetriebnahme-Verzögerungen führt.
Mit Phase 9 von FactoryLine Pro schließen wir diese Lücke. Der neue Component Logic Editor ermöglicht es, für jede Station in der Fabrik eine vollständige Steuerungslogik zu definieren — direkt in der Simulationsumgebung, ohne TIA Portal öffnen zu müssen. Die Logik wird nach IEC 61131-3 modelliert, kann als SCL exportiert werden und lässt sich im integrierten Debugger Schritt für Schritt nachvollziehen.
Zwei Darstellungen, ein Modell
Eine der ersten Designentscheidungen war fundamental: Unterstützen wir FBD (Funktionsbausteindiagramm), KOP (Kontaktplan) oder beides? Die Antwort wurde schnell klar. In der DACH-Fertigungsindustrie arbeiten manche Inbetriebnahme-Ingenieure bevorzugt mit FBD, andere schwören auf KOP. Beide Darstellungen gleichzeitig zu unterstützen war kein Nice-to-have — es war eine harte Anforderung.
Die Lösung: Ein einziges Datenmodell im Backend, das beide Sichten bedient. Jedes Netzwerk besteht aus Elementen (Kontakte, Spulen, Funktionsbausteine) und Verbindungen zwischen ihnen. Die FBD-Ansicht rendert diese als React-Flow-Canvas mit frei positionierbaren Blöcken. Die KOP-Ansicht übersetzt dasselbe Modell in klassische Sprossen mit Stromschienen, Reihenkontakten und Parallelzweigen.
Der Wechsel zwischen FBD und KOP geschieht per Klick — ohne Datenverlust, ohne Neuberechnung. Was man in FBD ändert, sieht man sofort in KOP und umgekehrt.
27 Standard-Bausteine nach IEC 61131-3
Der Editor bringt eine vollständige Bibliothek an IEC-konformen Funktionsbausteinen mit, aufgeteilt in logische Kategorien:
Das allein wäre für eine generische SPS-Entwicklungsumgebung ausreichend. Aber FactoryLine Pro ist kein generisches Tool — es ist eine Simulationssoftware für Fertigungslinien. Deshalb haben wir fünf eigene Funktionsbausteine entwickelt, die typische Maschinensteuerungen auf einen Baustein reduzieren.
| Kategorie | Bausteine | Anwendung |
|---|---|---|
| Logik | AND, OR, NOT, XOR | Grundverknüpfungen |
| Bistabil | SR, RS | Speicherglieder |
| Flanke | R_TRIG, F_TRIG | Flankenauswertung |
| Timer | TON, TOF, TP | Zeitsteuerung |
| Zähler | CTU, CTD, CTUD | Stückzählung, Batchkontrolle |
| Vergleich | CMP_GT, CMP_LT, CMP_EQ, CMP_GE, CMP_LE | Schwellwertüberwachung |
| Arithmetik | ADD, SUB, MUL, DIV | Berechnungen |
| Daten | MOVE, SEL, MUX | Wertübertragung, Auswahl |
Fünf Custom-Bausteine für die Fertigung
Wer schon einmal eine Pneumatikzylinder-Steuerung in FBD programmiert hat, weiß: Für eine saubere Implementierung mit Endlagenerkennung, Timeout-Überwachung und Fehlerbehandlung braucht man schnell 15–20 Bausteine und ein halbes Dutzend Netzwerke. Unser CYLINDER_CTRL-Baustein kapselt diese Logik in einem einzigen Block mit sechs klar definierten Zuständen: Idle, Extending, Extended, Retracting, Retracted und Error.
Jeder dieser Bausteine ist direkt an die Physik-Engine von FactoryLine Pro angebunden. Ein CYLINDER_CTRL-Baustein steuert nicht nur virtuelle Signale — er bewegt tatsächlich den simulierten Zylinder mit realistischen Verfahrzeiten.
- SEQUENCE verwaltet Schrittabläufe mit N Schritten und konfigurierbarem Timeout pro Schritt — der häufigste Anwendungsfall in der Stationssteuerung
- CYLINDER_CTRL modelliert pneumatische Zylinder als Zustandsautomat mit Endlagensensoren, Timeout und Fehlerbehandlung
- HANDSHAKE implementiert das klassische Station-zu-Station Teileübergabe-Protokoll mit Request/Acknowledge/Complete
- MOTOR_CTRL steuert Motoren mit Hochlauframpe, Drehzahlüberwachung und Störungsbehandlung
- SENSOR_DEBOUNCE entprellt Sensorsignale mit konfigurierbarer Entprellzeit — unverzichtbar bei Lichtschranken in vibrationsintensiven Umgebungen
Der Compiler: Von Netzwerken zu ausführbarer Logik
Ein visueller Editor ist nur die halbe Miete. Die eigentliche Herausforderung war der LogicCompiler — das Modul, das die visuelle Darstellung in eine ausführbare Sequenz übersetzt.
Das Kernproblem: In einem FBD-Netzwerk können Bausteine beliebig verbunden werden, auch zirkulär. Damit die Auswertungsreihenfolge deterministisch und korrekt ist, verwenden wir den Kahn-Algorithmus für topologisches Sortieren. Der Compiler traversiert den Verbindungsgraph, erkennt Zyklen (und meldet sie als Fehler) und erzeugt eine flache, geordnete Liste von Auswertungsschritten.
Das Ergebnis: `LogicRuntime.execute_cycle(dt_ms)` wertet pro Simulationstakt alle Netzwerke einer Komponente aus — Eingänge lesen, Kontakte und Bausteine evaluieren, Spulen schreiben. Optional synchronisiert die Runtime über die SignalTable mit der SimPy-Simulation, sodass Logikausgänge direkt physikalische Aktoren ansteuern.
SCL-Export: Direkt ins TIA Portal
Einer der am häufigsten gewünschten Features in unserem Beta-Feedback war: "Kann ich die Logik auch in mein TIA Portal übernehmen?" Die Antwort ist jetzt ja.
Der SCL-Generator erzeugt aus dem visuellen Modell vollständig kompilierbaren Structured Control Language-Code, kompatibel mit TIA Portal V17. Jedes Netzwerk wird in einen eigenen REGION-Block übersetzt. Kontakte werden zu IF/AND/OR-Ausdrücken, SEQUENCE-Bausteine zu CASE-Anweisungen, Funktionsbausteine zu Instanzaufrufen mit Parameterübergabe.
Das Ergebnis ist kein Prototyp-Code, der noch manuell überarbeitet werden muss — es ist produktionsfertiger SCL-Code mit korrekten VAR_INPUT/VAR_OUTPUT/VAR-Deklarationen, den man direkt in einen TIA-Funktionsbaustein einfügen kann.
Step-Debugger: Logik nachvollziehen, Fehler finden
Der integrierte Step-Debugger war das Feature, bei dem die Entwicklung am meisten Spaß gemacht hat — und am meisten Kopfzerbrechen bereitet hat. Die Anforderung klingt einfach: Breakpoints auf einzelne Elemente setzen, Schritt für Schritt durch die Logik gehen, Signalwerte live beobachten.
Die Umsetzung war alles andere als trivial. Der Debugger musste in die SimPy-Zeitschleife integriert werden, ohne den Simulationstakt zu blockieren. Die Lösung: Ein dedizierter Debug-Modus, in dem die Runtime nach jedem Auswertungsschritt pausiert und den aktuellen Zustand über WebSocket an die React-UI sendet. Die UI zeigt dann ein visuelles Overlay: aktive Elemente leuchten grün, inaktive sind ausgegraut, und neben jedem Baustein stehen die aktuellen Werte der Ein- und Ausgänge.
Dazu kommt eine Watch-List für beliebige Signale und Variablen sowie ein Zyklen-Zähler, der mitzählt, wie viele SPS-Zyklen seit dem Start vergangen sind. In Kombination mit dem bereits vorhandenen Signal-Trace (dem Oszilloskop-artigen Signalrekorder aus Phase 4) entsteht ein Debugging-Erlebnis, das erstaunlich nah an die Realität der TIA-Portal-Diagnosewelt herankommt.
Vorlagen: Nicht bei null anfangen
Sechs mitgelieferte Logik-Vorlagen decken die häufigsten Maschinentypen ab:
Jede Vorlage ist ein vollständiges, lauffähiges Logikmodell, das sofort simuliert werden kann. Man wählt die Vorlage beim Erstellen einer neuen Maschinenlogik aus und passt sie an die eigenen Anforderungen an. Das reduziert die Zeit von der leeren Leinwand zum laufenden Stationsprogramm von Stunden auf Minuten.
- CNC_BASIC — Spannen, Bearbeiten, Lösen: der Dreitakter für CNC-Maschinen
- PRESS_BASIC — Spannzyklus plus Presshub mit Sicherheitsverriegelung
- ASSEMBLY_STATION — Mehrstufige Montagesequenz mit Teileübergabe
- CONVEYOR_CONTROL — Motorsteuerung mit Sensorlogik für Förderbänder
- ROBOT_CELL — Pick-and-Place-Sequenz mit Greifer- und Positionssteuerung
- EMPTY — Leere Vorlage als Ausgangspunkt für eigene Logik
Die Architektur dahinter
Technisch basiert der Logic Editor auf einer klaren Trennung der Verantwortlichkeiten:
Das gesamte Modul ist durch über 200 Tests abgesichert — vom einzelnen Funktionsbaustein über die Compiler-Logik bis zur API-Integration. Rückwärtskompatibilität ist dabei nicht verhandelbar: Jede Erweiterung muss bestehende Konfigurationen unverändert lassen.
- Python-Backend (`logic/model.py`) definiert das Pydantic-Datenmodell: Netzwerke, Elemente, Verbindungen, Variablen
- Funktionsbausteine (`logic/function_blocks.py`, `logic/custom_blocks.py`) implementieren die IEC-Bausteine mit `evaluate()`-Methoden
- Runtime (`logic/runtime.py`) führt die kompilierte Logik aus und bindet an die SignalTable
- SCL-Export (`logic/scl_export.py`) generiert TIA-kompatiblen Code
- React-Frontend rendert FBD als React-Flow-Canvas und KOP als strukturiertes Sprossendiagramm
- WebSocket-API (`api/logic_api.py`) verbindet Frontend und Backend für Speichern, Laden, Kompilieren und Debuggen
Was das für die virtuelle Inbetriebnahme bedeutet
Mit dem Logic Editor schließt sich der Kreis in FactoryLine Pro. Man kann jetzt eine komplette Fertigungslinie von der Planung über die Simulation bis zur SPS-Logik in einem einzigen Tool abbilden:
Dieser geschlossene Kreislauf spart nicht nur Zeit in der Inbetriebnahme — er verändert den gesamten Entwicklungsprozess. Steuerungslogik wird nicht mehr erst geschrieben, wenn die Maschine auf dem Hallenboden steht, sondern parallel zum mechanischen Engineering, validiert durch Simulation.
- Layout im 2D-Editor erstellen und in 3D visualisieren
- Materialfluss simulieren und Engpässe identifizieren (Mode A)
- Steuerungslogik pro Station im Logik-Editor definieren
- SCL-Code exportieren und in TIA Portal übernehmen
- SPS-Programm via PLCSIM Advanced zurück in die Simulation bringen (Mode B/C)
- Timing-Abweichungen zwischen Physik-Modell und SPS-Programm im Debugger analysieren
Ausblick
Der Logic Editor ist seit Phase 9 verfügbar und wird aktiv weiterentwickelt. Auf der Roadmap stehen unter anderem die direkte TIA-Openness-Integration für bidirektionalen Code-Austausch, erweiterte Validierungsregeln für sicherheitsrelevante Logik und eine KI-gestützte Logikgenerierung, die aus der Simulationsanalyse automatisch Optimierungsvorschläge für die Steuerung ableitet.
Der Logik-Editor ist über F7 erreichbar — einfach eine Maschine im Layout auswählen und loslegen.