Viele starten mit SPS-Programmierung falsch: Sie suchen sofort nach „Beispielcode“, klicken sich durch Menüs — und wundern sich, warum das Verhalten der Anlage trotzdem nicht verständlich wird.
SPS-Programmierung ist weniger „Coding“ im Web-Sinn, sondern eher systematisches Denken in Zuständen, Signalen und sicheren Abläufen. Wenn Sie diese Denkweise einmal verstanden haben, werden KOP/FUP/ST nur noch „Schreibweisen“ für dieselbe Logik.
1) Was bedeutet „SPS programmieren“ eigentlich?
Eine SPS (speicherprogrammierbare Steuerung) liest in kurzen Zyklen Eingänge ein, führt Logik aus und setzt Ausgänge. Ziel ist nicht „schöner Code“, sondern:
- Deterministisches Verhalten (gleiches Signal → gleiches Ergebnis)
- Sichere Zustände (bei Fehlern/Stopps darf nichts Unerwartetes passieren)
- Wartbarkeit (Techniker sollen Logik prüfen und Störungen finden können)
- Nachvollziehbarkeit (warum war ein Ventil aus? warum startete ein Motor nicht?)
Wenn Sie SPS programmieren lernen, lernen Sie daher vor allem:
- Signale richtig zu interpretieren (Sensoren, Schalter, Messwerte)
- Logik robust zu formulieren (Verriegelungen, Freigaben, Sequenzen)
- Ausgänge so zu steuern, dass die Anlage real stabil läuft
Grundlage dazu: Was ist eine SPS (PLC)?
2) Welche SPS-Sprachen gibt es — und welche ist „am besten“?
In der Praxis begegnen Ihnen häufig diese Darstellungsformen (IEC 61131-3):
- KOP (Kontaktplan / Ladder) — sehr verbreitet in Wartung & Elektro-nahem Umfeld
- FUP (Funktionsplan / Function Block Diagram) — gut für Signalfluss, Bedingungen, Vergleiche
- ST (Structured Text) — textbasiert, gut für Algorithmen, Schleifen, Datenverarbeitung
Wichtig: Die „beste“ Sprache ist die, mit der Ihr Team Fehler findet und Änderungen sicher macht. Viele Anlagen nutzen gemischte Projekte (z. B. KOP für Grundlogik, ST für Berechnungen).
3) Wie „denkt“ eine SPS? Zyklus, Scan, Zustände
Das Kernprinzip ist der SPS-Zyklus (vereinfacht):
- Eingänge lesen (Signalbild)
- Programm abarbeiten (Logik)
- Ausgänge schreiben (Ausgangsbild)
- Wiederholen (typisch: Millisekunden bis wenige Zehntelsekunden)
Viele Anfängerfehler entstehen, weil man unbewusst „event-basiert“ denkt (wie in Apps), SPS aber zyklisch arbeitet.
Praktisch heißt das:
- Ein kurzer Tastendruck muss oft gespeichert (gelatcht) werden, sonst „verschwindet“ er.
- Zustandswechsel werden häufig als Flanken erkannt (0→1 oder 1→0).
- Sequenzen brauchen ein Zustandsmodell (z. B. Schritt 10/20/30…)
4) Der wichtigste Denkrahmen: Signal → Logik → Wirkung
Wenn Sie SPS programmieren lernen, trainieren Sie am besten dieses Modell:
- Signal: Was ist wirklich am Eingang? (Sensor, Schalter, Messwert)
- Logik: Welche Bedingungen müssen erfüllt sein?
- Wirkung: Was soll physisch passieren? (Motor, Ventil, Aktor)
Das hilft nicht nur beim Programmieren, sondern auch bei der Fehlersuche.
Vertiefung: Störungsdiagnose — Denkmodell · Sensoren und Aktoren
5) Typischer Programmaufbau (robust & wartbar)
Ein gutes SPS-Projekt ist nicht „eine große Logik“. Es ist strukturiert. Ein praxisnahes Muster:
5.1 Signale aufbereiten
- Entprellen / Filtern (falls nötig)
- Grenzwerte prüfen (z. B. Druck > Mindestwert)
- Sensorfehler erkennen (unplausible Werte, Kabelbruchsignale)
5.2 Freigaben & Verriegelungen
Viele Ausgänge hängen nicht an „einem Taster“, sondern an einem Bündel von Bedingungen:
- Not-Halt ok
- Schutztür zu
- Thermoschutz ok
- Druck/Luft ok
- Kein aktiver Störzustand
5.3 Zustandsmaschine / Sequenz
Wenn Abläufe mehrere Schritte haben (Starten, Spülen, Füllen, Heizen, …), arbeiten Sie mit Zuständen:
- Schritt 10: Voraussetzungen prüfen
- Schritt 20: Aktor X an, warten bis Sensor Y
- Schritt 30: Nächster Schritt
Das ist deutlich wartbarer als „verstreute ifs“.
5.4 Aktoren ansteuern
Ausgänge setzen Sie idealerweise am Ende klar und nachvollziehbar. So lässt sich später prüfen: „Welche Logik führt zu Output Q?“
6) Häufige Anfängerfehler (und wie man sie vermeidet)
Fehler 1: „Taster = Motor“ (ohne Speicher)
Ein Momenttaster ist nur kurz aktiv. Wenn Sie den Motor „halten“ wollen, brauchen Sie eine Selbsthaltung (Latch) oder einen Zustand.
Fehler 2: Verriegelungen fehlen
Ohne Verriegelungen starten Motoren bei falschen Voraussetzungen. Das führt zu Störungen, mechanischem Stress oder Sicherheitsproblemen.
Fehler 3: Keine Diagnose-Bits
Wenn eine Anlage nicht startet, ist die wichtigste Frage: Welche Bedingung fehlt? Gute Programme erzeugen Diagnose-Flags („Freigabe fehlt wegen X“).
Fehler 4: Logik ist verteilt
Wenn dieselbe Bedingung an fünf Stellen geprüft wird, entstehen Inkonsistenzen. Besser: zentrale Freigabe-Bits bilden und überall verwenden.
Fehler 5: IT/OT wird ignoriert
Wenn HMI/SCADA, Netzwerke und Benutzerrechte nicht mitgedacht werden, entstehen später schwer erklärbare Effekte (z. B. falsche Bedienzustände, „Ghost“-Signale).
Lesen: IT vs. OT · SCADA und HMI · Industrielle Netzwerke
7) Mini-Beispiel (Start/Stop als Denkübung)
Das Ziel ist nicht „Code“, sondern Logikverständnis. Stellen Sie sich vor:
- Taster Start soll den Motor einschalten.
- Taster Stop soll ihn ausschalten.
- Not-Halt muss alles sperren.
- Nach Stromausfall soll der Motor nicht automatisch anlaufen.
Konzeptuell bedeutet das:
- Ein gespeicherter Betriebszustand (z. B. MotorFreigabe) wird gesetzt/gelöscht.
- Not-Halt löscht den Zustand immer.
- Beim Einschalten der SPS wird der Zustand sicher auf „Aus“ initialisiert.
Das ist SPS-Programmierung in Reinform: Zustände definieren, sichere Default-Werte, klare Verriegelung.
8) Lernstrategie: So werden Sie schnell besser
Wenn Sie SPS programmieren lernen möchten, funktioniert das am zuverlässigsten in drei Stufen:
Stufe A — Grundlagen
- Wie arbeitet eine SPS zyklisch?
- Was sind Eingänge/Ausgänge?
- Was sind Verriegelungen und Freigaben?
Stufe B — Systeme verstehen
- HMI/SCADA und Bedienkonzepte
- Netzwerke und Kommunikationswege
- Sensorik/Aktorik als reale Welt
Stufe C — Diagnose & Wartbarkeit
- Diagnose-Bits und klare Zustände
- Fehlersuche nach Signal → Logik → Wirkung
- Saubere Dokumentation (kurz, aber eindeutig)
Kurzfazit
SPS-Programmierung ist am Anfang ungewohnt, weil sie zyklisch und zustandsorientiert ist. Wenn Sie jedoch:
- Signale sauber aufbereiten
- Freigaben/Verriegelungen klar bilden
- Sequenzen als Zustände modellieren
- Diagnose und Wartbarkeit mitdenken
… dann werden SPS-Programme schnell logisch und beherrschbar.
Passend dazu: Was ist eine SPS? · SCADA und HMI · Industrielle Netzwerke · IT vs. OT · Störungsdiagnose