Beispielsitzung > Kapitel für Anfänger > Was ist eine SPS ?

Es gibt viele Gründe, ein Programm (nicht nur ein SPS-Programm) zu strukturieren. In diesem Abschnitt wird ein Aspekt, nämlich die Vorteile bei der Fehlersuche in fremden Programmen und auch die Probleme, die trotzdem noch auftreten, besonders herausgehoben. Die Bücher zu diesem Thema füllen ganze Regalwände, wir können also wirklich nur die Idee grob umreißen.

Wenn man ein SPS-Programm geschrieben hat, muss irgendwie festgelegt werden, wie dieses Programm von der SPS bearbeitet wird. Um dies zu erläutern, wählen wir hier stellvertretend für SPS im Allgemeinen die Siemens S7. Das Prinzip ist überall das Gleiche und auch, wenn die Namen jeweils verschieden sind, werden Sie sich schnell auf andere SPS umstellen können.

Wenn man das Programm in die SPS überträgt, kann man es in viele Bausteine unterteilen. Unter all diesen Bausteinen ist der Organisationsbaustein 1 (OB1) besonders ausgezeichnet. Nach dem Start der SPS und nachdem einige Vorbereitungen erledigt sind, liest sie die Digital-Eingänge und überträgt sie ins Prozessabbild der Eingänge. Anschließend ruft die SPS den OB1 auf, d.h., sie führt die Befehle, die dort stehen, einen nach dem anderen aus. Wenn sie damit fertig ist, überträgt sie alle Ausgänge des Prozessabbildes auf die entsprechenden Digital-Ausgabe-Baugruppen. Dann ruft sie wieder den OB1 auf. Dieser Vorgang wiederholt sich, bis die SPS gestoppt wird.

Der Programmierer muss also alles, was die SPS tun soll, im OB1 festlegen. Bei komplizierteren Programmen würde dies jedoch zu einem riesigen OB1 führen, der kaum noch zu verstehen und zu warten wäre. Darum gibt es die Möglichkeit, logisch zusammengehörige Teile eines Programmes in einer Funktion oder einem Funktionsbaustein zu schreiben. Im OB1 muss dann nur noch stehen: “Und jetzt führe bitte alle Befehle aus, die in der FunktionX aufgeführt sind”. Sind alle diese Befehle dann ausgeführt, wird die Bearbeitung im OB1 nach diesem Aufruf fortgesetzt. Im Idealfall besteht der OB1 dann nur noch aus einigen Bausteinaufrufen.

Für die Fehlersuche ist dies ungemein hilfreich. Denken Sie sich, sie sollten einen Fehler in der Steuerung einer Ihnen unbekannten Anlage suchen, der im Anlagenteil 2 aufgetreten ist. Sie schließen ihr Programmiergerät an und finden folgenden OB1:

Aufruf Schnittstelle zum Bediengerät

Aufruf Steuerung Anlagenteil 1

Aufruf Steuerung Anlagenteil 2

Wo würden Sie den Fehler suchen? Natürlich im FC 2 und damit ist der Fehler schon einmal auf ein Drittel des Programmes eingegrenzt.

Wenn die Steuerung des Anlagenteils 2 auch wieder sehr umfangreich ist, kann es sein, dass der Programmierer diese nochmals in einzelne Funktionen und Funktionsbausteine untergliedert hat.

Dies ist die grundlegende Idee der strukturierten Programmierung. Jetzt folgt, warum die Fehlersuche in strukturieren Programm nicht ganz so einfach ist, wie es zunächst aussieht.

In der Theorie sollte es also möglich sein, mittels der strukturierten Programmierung übersichtliche und leicht zu verstehende Programme zu schreiben. In der Praxis sieht es leider häufig ganz anders aus. Und dafür gibt es mehrere Gründe:

Zum einen werden die beiden Anlagenteile ja nicht vollkommen unabhängig voneinander funktionieren. Und genauso, wie die wirklichen Anlagenteile z.B. Material austauschen, müssen die Programmbausteine, die für die Steuerung des jeweiligen Anlagenteils zuständig sind, Informationen austauschen. Eine Möglichkeit, dies zu bewerkstelligen sind die Parameter von Funktionen und Funktionsbausteinen, die die benötigten Kommunikationsmöglichkeiten bereitstellen, die aber die Fehlersuche auch dementsprechend schwieriger machen, weil die strenge Trennung der Bausteine und damit des möglichen Fehlerortes, aufgehoben wird.

Zum anderen werden oft die gleichen Bausteine von verschiedenen Stellen im Programm aufgerufen, auch wenn die von der entsprechenden Programmstelle kontrollierten Anlagenteile weit voneinander entfernt sind. Die Schwierigkeiten, die damit verbunden sind, sind