Technik erklärt

SPS programmieren lernen — strukturierter Einstieg für Anfänger

Wie man SPS-Programme sinnvoll aufbaut, welche Denkweise dahinter steckt und welche Fehler man früh vermeiden sollte.

Start  ›  Artikel  ›  SPS programmieren lernen

Von Daniel M. Hochwieser

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 oder ST nur noch verschiedene Schreibweisen für dieselbe Logik.

Genau darin liegt der größte Unterschied zu vielen anderen Programmierbereichen: Es geht nicht in erster Linie um elegante Syntax, sondern darum, dass eine reale Maschine bei Start, Störung, Reset und Wiederanlauf berechenbar reagiert.

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:

Wenn Sie SPS programmieren lernen, lernen Sie daher vor allem:

Ein gutes SPS-Programm ist deshalb nie nur „eine Funktion, die läuft“. Es ist immer auch eine Art Betriebsanleitung in Logikform: Wer darf starten? Was blockiert? Welche Ursache wird gemeldet? Was passiert nach Spannungsrückkehr?

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):

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).

Ein häufiger Anfängerirrtum ist, die Sprachwahl zu überschätzen. In der Praxis sind schlechte Programme selten deshalb schlecht, weil KOP statt ST verwendet wurde — sondern weil die Struktur unklar ist, Zustände fehlen oder Diagnose nicht mitgedacht wurde.

3) Wie „denkt“ eine SPS? Zyklus, Scan, Zustände

Das Kernprinzip ist der SPS-Zyklus (vereinfacht):

  1. Eingänge lesen (Signalbild)
  2. Programm abarbeiten (Logik)
  3. Ausgänge schreiben (Ausgangsbild)
  4. 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:

Gerade dieser Punkt trennt „Code verstanden“ von „Anlage verstanden“. Wer SPS wirklich lernt, versteht irgendwann nicht nur einzelne Anweisungen, sondern den Gesamtfluss einer Anlage über Zeit.

4) Der wichtigste Denkrahmen: Signal → Logik → Wirkung

Wenn Sie SPS programmieren lernen, trainieren Sie am besten dieses Modell:

Das hilft nicht nur beim Programmieren, sondern auch bei der Fehlersuche.

In realen Projekten ist dieser Denkrahmen entscheidend, weil Fehler selten nur „im Code“ liegen. Häufig ist das Signal falsch, ein Sensor ungünstig montiert, ein Analogwert schlecht skaliert oder ein Ausgang aktiv, obwohl der Aktor mechanisch blockiert.

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

In der Praxis ist dieser Block extrem wichtig. Ein formal korrektes Programm hilft wenig, wenn schwankende Signale oder fehlerhafte Sensorwerte direkt ungefiltert in die Logik eingehen.

5.2 Freigaben & Verriegelungen

Viele Ausgänge hängen nicht an „einem Taster“, sondern an einem Bündel von Bedingungen:

Anfänger unterschätzen oft, wie viele dieser Bedingungen später gebraucht werden. Wer sie von Anfang an sauber bündelt, spart sich chaotische Logik und schwer auffindbare Seiteneffekte.

5.3 Zustandsmaschine / Sequenz

Wenn Abläufe mehrere Schritte haben (Starten, Spülen, Füllen, Heizen, …), arbeiten Sie mit Zuständen:

Das ist deutlich wartbarer als „verstreute ifs“.

Gerade in größeren Projekten ist diese Struktur keine akademische Übung, sondern die Voraussetzung dafür, dass andere Personen das Programm später noch verstehen und sicher ändern können.

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?“

Das klingt banal, ist im Alltag aber Gold wert. Spätestens bei einer Störung will niemand zehn verstreute Stellen durchsuchen, nur um herauszufinden, warum ein Ausgang nicht gesetzt wird.

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).

Das klingt nach „späterem Luxus“, ist aber in modernen Anlagen real. Schon kleine Steuerungen hängen heute oft an HMIs, Netzwerken oder übergeordneten Systemen. Wer diese Zusammenhänge ignoriert, baut zwar ein Programm, aber kein belastbares System.

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:

Konzeptuell bedeutet das:

Das ist SPS-Programmierung in Reinform: Zustände definieren, sichere Default-Werte, klare Verriegelung.

In echten Projekten kommt danach noch mehr dazu: Quittierungen, Betriebsarten, Störmeldungen, Wiederanlaufstrategie, eventuell Schütze, Frequenzumrichter oder Sicherheitsbedingungen. Aber genau deshalb ist dieses einfache Beispiel so nützlich: Es zeigt das Grundprinzip in einer Form, die später auf größere Abläufe erweitert werden kann.

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

Stufe B — Systeme verstehen

Stufe C — Diagnose & Wartbarkeit

Der vielleicht wichtigste Punkt: Lernen Sie nicht nur „wie man etwas programmiert“, sondern immer auch wie man später versteht, warum es nicht läuft. Genau diese Perspektive unterscheidet Anfänger von belastbaren Praktikern.

9) Was viele Lernende unterschätzen

SPS-Programmierung wirkt von außen oft wie eine rein technische Fähigkeit. In Wirklichkeit ist sie auch eine Frage von Arbeitsweise und Disziplin.

Viele Anlagen leben deutlich länger als das ursprüngliche Projektteam. Genau deshalb ist wartbare Logik langfristig oft wertvoller als kurzfristig schneller Code.

Kurzfazit

SPS-Programmierung ist am Anfang ungewohnt, weil sie zyklisch und zustandsorientiert ist. Wenn Sie jedoch:

… dann werden SPS-Programme schnell logisch und beherrschbar.

Wer in diesem Bereich besser werden will, sollte deshalb nicht nur „mehr Code“ schreiben, sondern lernen, Anlagen als Zusammenspiel von Signalen, Logik, Kommunikation und realer Wirkung zu lesen.

Passend dazu: Was ist eine SPS? · SCADA und HMI · Industrielle Netzwerke · IT vs. OT · Störungsdiagnose