Einleitung: Zykluszeit als kritische Kennzahl
Die Zykluszeit einer S7-1500 ist nicht nur eine technische Kennzahl – sie ist ein Spiegel der Programmqualität. Ein schlecht optimiertes Programm kann eine S7-1516 genauso in die Knie zwingen wie eine overprovisioned S7-1511 mit minimalem Code brillieren kann. Dieser Artikel zeigt systematisch, wo Zykluszeit-Ressort verloren geht und wie Sie gezielte Optimierungen vornehmen.
Zykluszeit messen und analysieren
Bevor Sie optimieren, messen Sie. Im TIA Portal finden Sie unter Online → Zykluszeit-Überwachung die aktuellen Werte. Noch detaillierter ist der Weg über den Diagnosepuffer und den Systembaustein OB_CYCLIC_INT. Für eine kontinuierliche Messung empfiehlt sich die Trace-Funktion im TIA Portal (Online → Trace). Zeichnen Sie die Systemvariable %MW... (Cycle_Time) oder besser die Variablen aus dem SFB "RUNTIME" auf.
Orientierungswerte für S7-1500:
- S7-1511: typisch 1–3 ms pro 1000 Anweisungen
- S7-1515: typisch 0,5–1,5 ms pro 1000 Anweisungen
- S7-1518: typisch 0,2–0,8 ms pro 1000 Anweisungen
Häufigste Ursachen für Zykluszeit-Probleme
1. Ineffizienter DB-Zugriff
Der klassischste Performance-Killer. Viele Programmierer greifen auf DB-Variablen mit der vollständigen Adressierung zu: "MeinDB".MeineVariable. Bei häufigem Zugriff auf denselben DB ist es deutlich schneller, den DB am Anfang des Bausteins in eine lokale Instanz zu kopieren oder mit ANY-Zeigern und SFC20 BLKMOV zu arbeiten.
Noch schlimmer ist indirekter DB-Zugriff: DB[i].DBW[j]. Dieser Zugriff verhindert die Vorkompilierung und kostet 3–5-fache Laufzeit gegenüber direktem Zugriff. Wo immer möglich, auf strukturierte Datentypen und direkte Adressierung umstellen.
2. OB1-Überlastung durch falsche Bausteinarchitektur
Ein häufiger Fehler ist, zu viele Aufgaben im OB1 zu bündeln. Besser ist die Nutzung zyklischer Interrupt-OBs: OB30 (5 ms), OB31 (2 ms), OB32 (1 ms) für zeitkritische Regelungen. OB1 sollte primär Zustandsmaschinen und Sequenzen abwickeln, während schnelle Regelkreise in kürzere OBs verschoben werden. Achten Sie aber auf die Gesamtauslastung: Wenn OB30 mehr Zeit braucht als sein Intervall, startet er sofort neu und verdrängt OB1.
3. PROFINET-Kommunikationslast
PROFINET-Kommunikation läuft im Hintergrund, belastet aber den Prozessor. Zu viele IO-Devices mit kurzen Update-Zeiten können 20–40% der Zykluszeit kosten. Optimierungen:
- PROFINET-Update-Zeiten an tatsächlichen Bedarf anpassen (nicht immer 1 ms notwendig)
- IO-Devices mit wenig Daten zu einem Device consolidieren (Netzwerk-IO vs. Einzelmodule)
- Konsistente Datenbereiche mit
DPRD_DAT / DPWR_DATfür große Datenpakete nutzen
4. Schleifen ohne Laufzeitbegrenzung
FOR-Schleifen über große Arrays sind Zykluszeit-Fallen. Eine Schleife über 10.000 Elemente kann leicht 5–10 ms kosten. Lösungsansätze:
- Schleifen auf mehrere Zyklen verteilen (Statemaschinenansatz mit Fortsetzungszeiger)
MOVE_BLK_VARIANTstatt manueller Schleifen für Blockkopien- Sortierfunktionen außerhalb des kritischen Pfads verlagern
5. Überladene Diagnose-Bausteine
Siemens-Standard-Diagnosefunktionen wie DeviceStates oder ModuleStates sind ressourcenintensiv. Rufen Sie diese nicht in jedem Zyklus auf, sondern nur bei Bedarf (flankengesteuert oder mit Zeitverzögerung). Ein häufiger Fehler: 50 Module × DeviceStates in OB1 = 2–3 ms verschenkte Zykluszeit pro Zyklus.
Optimierungswerkzeuge im TIA Portal
Profiling mit Laufzeitmessung
Im TIA Portal V16+ können Sie mit der Laufzeitmessung einzelne FC/FB-Aufrufe direkt messen. Fügen Sie vor und nach dem verdächtigen Baustein die Systemfunktion SFC64 "TIME_TCK" ein und bilden Sie die Differenz. So lokalisieren Sie den genauen Verursacher innerhalb weniger Minuten.
Optimized Block Access
Aktivieren Sie für alle DBs die Option "Optimierter Bausteinzugriff" (Properties → Attributes → Optimized block access). Diese Option aktiviert den symbolischen Zugriff und ermöglicht der CPU, Variablen optimal im Speicher zu platzieren. Warnung: Nach der Aktivierung sind absolute DB-Adressierungen (DBW0, DBD4) nicht mehr möglich – prüfen Sie bestehenden Code vorher.
Hardware-Konfiguration prüfen
Überprüfen Sie in der Hardware-Konfiguration die Zykluszeit-Überwachung (Properties der CPU → Zyklus/Taktsynchronität). Ein zu hoher Überwachungszeitwert (Standard: 150 ms) verbirgt sporadische Zykluszeit-Überschreitungen. Setzen Sie den Wert auf 120% Ihres gemessenen Maximalwerts, um echte Anomalien zu erkennen.
MOVE_BLK und strukturierte Optimierungen
Für die Übertragung großer Datenpakete ist MOVE_BLK (SFC20) deutlich schneller als manuelle Schleifen. Syntax:
CALL SFC20 "BLKMOV"
SRCBLK := P#DB1.DBX0.0 BYTE 100
RET_VAL := MW100
DSTBLK := P#DB2.DBX0.0 BYTE 100Für S7-1500 mit TIA Portal V15+: Verwenden Sie besser MOVE_BLK_VARIANT, das mit variablen Längen und ANY-Typen umgeht und zusätzliche Fehlerbehandlung bietet.
Indirektes Adressieren richtig einsetzen
Indirektes Adressieren ist manchmal unvermeidbar, kann aber optimiert werden. Statt DB[MyDBNum].DBW[MyOffset] empfiehlt sich die Verwendung von ARRAY-DBs mit direktem Index-Zugriff: "ArrayDB".Data[i]. Der Compiler kann bei symbolischen Arrays besser optimieren als bei vollständig indirekter Adressierung.
Praxistipp: Zykluszeit-Budget anlegen
Erstellen Sie ein internes Dokument, das die Zykluszeit-"Budgets" jedes OB aufschlüsselt. Beispiel: OB1 = max. 8 ms, OB30 = max. 1,8 ms. Messen Sie regelmäßig (z.B. monatlich oder bei Programmänderungen) gegen diese Werte. Zykluszeit-Verschlechterungen sind oft schleichend – ein Baustein, der bei der Inbetriebnahme 0,2 ms kostete, kann nach einem Jahr durch Datenmenge-Anstieg 1,5 ms verbrauchen.
Fazit
TIA Portal-Performance-Probleme sind fast immer auf einige wenige, gut bekannte Ursachen zurückzuführen: ineffizienter DB-Zugriff, falsche OB-Verteilung, zu viele PROFINET-Devices mit kurzen Update-Zeiten, und unkontrollierte Schleifen. Mit den richtigen Messwerkzeugen lassen sich Engpässe innerhalb von Stunden lokalisieren und beheben. Eine regelmäßige Performance-Überprüfung gehört zur professionellen SPS-Entwicklung dazu.