SPS-Programmierung #13: Ablaufsteuerungen — Transcript

Als Automatisierungstechniker werdet ihr häufig vor die Aufgabe gestellt, eine Steuerung zu entwerfen, die in einem Prozess oder in einer Anlage eine bestimmte Sequenz von Aktionen ausführen soll.

Ein sehr einfaches Beispiel dafür ist eine Ampel, die also nacheinander die Signale grün, gelb, rot, rot, gelb und dann wieder grün ausgeben soll.

Ein zweites Beispiel ist die Tür in einem Aufzug, die also auf Anforderung aufgefahren werden soll, dann für eine gewisse Zeit auf bleibt und wieder automatisch zugefahren werden soll.

Steuerungen, die also einen solchen Ablauf in einer Anlage realisieren, heißen Ablaufsteuerungen oder ihr kennt es vielleicht auch als Schrittkette.

In diesem Video zeige ich euch erstens, wie man Ablaufsteuerungen Ingenieursmäßig entwirft und zweitens dann implementiert.

Ein Entwurf oder auch Modell einer Ablaufsteuerung ist so etwas wie ein Plan oder ein Konzept, das beschreibt, wie sich diese Steuerung verhalten soll.

Und das Tool, das zum Standard für den Entwurf solcher Steuerung geworden ist, ist das UML-Zustandsdiagramm.

Damit ihr also nachvollziehen könnt, wie solch ein Entwurf funktioniert, werde ich hier auch noch in einem Crashkurs die Notationselemente von UML-Zustandsdiagramm einführen.

So und der Entwurf einer solchen Steuerung ist dann also die Grundlage oder die Basis für die Implementierung.

Man kann also den Entwurf in ST-Code übersetzen und wie diese Übersetzung funktioniert, zeige ich euch hier dann auch.

Wenn ihr vielleicht schon ein paar Vorerfahrungen in SPS-Programmierung habt, würdet ihr sagen, dass strukturierter Text vielleicht nicht die intuitive Wahl für die Implementierung einer Ablaufsteuerung oder einer Schrittkette ist, denn dafür bietet die IEC 61131 eine eigene Sprache an und das ist die sogenannte Ablaufsprache oder kurz AS. Und damit ihr mal einen Vergleich habt zwischen den Implementierungen einer Steuerung in Ablaufsprache oder strukturiertem Text, werde ich das Beispiel, dass ich hier anwende, in beiden Sprachen implementieren und dann einmal vergleichend gegenüberstellen.

So ein UML-Zustandsdiagramm beschreibt also eine Abfolge von Schritten, wobei die Schritte hier jetzt als Zustände bezeichnet werden.

Den Einstiegspunkt in ein Zustandsdiagramm markiert dieser ausgefüllte Kreis. Ausgehend von diesem Kreis zeigt dann ein Pfeil auf den ersten Zustand.

Der Pfeil ist hier im Grunde schon ein Zustandsübergang, aber dazu erkläre ich gleich noch mehr. Schauen wir jetzt erstmal auf die Notation eines Zustands.

Der wird also als so ein Quadrat dargestellt mit einer Kopfzeile, in die der Name des Zustands geschrieben wird.

Das sollte also ein Bezeichner sein, der den Zustand des Systems möglichst gut beschreibt.

Bei einer Ampel könnte das zum Beispiel Phase Grün sein.

In dem Zustand werden dann Aktionen ausgeführt, also zum Beispiel wird die Ansteuerung eines Aktors verändert.

Und den Zeitpunkt der Ausführung dieser Aktion kann man noch genauer eingrenzen, nämlich ob eine Aktion beim Eintreten in den Zustand ausgeführt wird.

Oder während der Zustand aktiv ist oder beim Verlassen des Zustands.

Diese Zeitpunkte werden durch das Voranstellen der Wörter ENTRY, DO bzw. EXIT spezifiziert.

Dahinter kommt dann nach einem Schrägstrich immer der Name der Aktion.

Nachher im Programm werdet ihr sehen, dass eine Aktion so etwas ähnliches wie ein Skript ist.

Also eine Reihe von Anweisungen und diese Aktion kann man also einen Namen geben, den man dann hier im Diagramm einträgt.

Es muss nicht für jede Phase des Zustands eine Aktion definiert werden, es kann ja durchaus Zustände geben, in denen nichts passieren soll.

In den einzelnen Phasen und dann würde man hier im Diagramm eben keine Aktion angeben und die Zeile hinter dem ENTRY, DO oder EXIT eben leer lassen.

So, natürlich besteht ein Zustandsdiagramm nicht nur aus einem Zustand, sondern aus mehreren.

Und zwischen diesen Zuständen gibt es Zustandsübergänge, die durch diese Pfeile hier markiert sind.

Ein Zustandsübergang passiert aber nicht zufällig, sondern wenn eine bestimmte Bedingung eintritt und diese Bedingung wird hier in eckigen Klammern an den Zustandsübergang geschrieben.

So eine Bedingung könnte also sein, dass ein Timer abgelaufen ist oder dass ein Taster betätigt wurde.

Ganz allgemein ist diese Bedingung hier ein logischer Ausdruck und wenn dieser logische Ausdruck den Wahrheitswert TRUE hat, dann erfolgt der Zustandsübergang.

Ein boolscher Wert ist natürlich der einfachste logische Ausdruck, es können aber auch andere Bedingungen formuliert werden, wie Vergleiche mit größer, kleiner, kleiner gleich und so weiter.

Oder logische Verknüpfung mit und, oder und anderen Operatoren.

Das UML-Zustandsdiagramm gibt auch die Möglichkeit, dass bei einem Zustandsübergang Aktionen ausgeführt werden, die dann hier hinter diesem Schrägstrich wieder angegeben werden.

Und hier gilt das gleiche wie bei den Aktionen in einem Zustand, ein Zustand Übergang muss keine Aktion haben.

Und auch nicht jede Implementierungssprache bietet die Möglichkeit, diese Aktion zu implementieren.

Wenn es also keine Aktion gibt bei einem Übergang, wird hier einfach nichts eingetragen.

So, hier seht ihr jetzt zwei Zustände mit einem Zustandsübergang.

Es kann aber auch sein, dass es von einem Zustand aus mehrere Zustandsübergänge zu unterschiedlichen Folgezuständen gibt, wie jetzt hier dargestellt.

Für diese beiden Zustandsübergänge hier muss es natürlich unterschiedliche Bedingungen geben, weil immer nur ein Zustand aktiv sein kann.

Und wenn man jetzt hier dieselbe Bedingung hätte, wäre erstmal unklar, welcher Folgezustand eingenommen werden soll.

So, es müssen also unterschiedliche und unabhängige Bedingungen sein an diesen Zustandsübergängen.

Also zum Beispiel hier Taster gedrückt und da unten Timer abgelaufen.

Es gibt Ablaufsteuerungen, die niemals verlassen werden, wo also immer ein Zustand aktiv ist.

Es gibt aber auch Ablaufsteuerungen, die zu einem Ende kommen, wo also eine bestimmte Sequenz abgearbeitet wurde und die Steuerung dann beendet wird.

Und so ein Ende wird dann durch einen umrandeten Kreis gekennzeichnet.

Okay, das sind also erstmal die wichtigsten Notationselemente, um eine Abfolge von Zuständen zu modellieren.

So, und manchmal ist es noch so, dass in einem System sehr komplexe Zustände auftreten, wo also mehrere Sachen parallel passieren.

Und um solche komplexen Abläufe zu modellieren, gibt es den zusammengesetzten Zustand.

Das ist also ein Zustand, in dem wiederum zwei oder sogar noch mehr eigene Zustandsdiagramme zusammengefasst sind.

Hier in diesem Beispiel seht ihr in dem zusammengesetzten Zustand zwei Bereiche und wenn eben dieser Zustand aktiv wird.

Dann starten sozusagen die Zustandsdiagramme, die hierin eingebettet sind.

Der Übersichtlichkeit halber habe ich jetzt hier keine Bedingungen und Aktionen eingetragen, aber für den Ablauf dieser Zustandsdiagramme gelten dieselben Regeln, die ich gerade schon erklärt habe.

So und wenn dann alle Zustandsdiagramme hierin abgearbeitet sind und jeweils die Endzustände eingenommen werden.

Dann ist auch der zusammengesetzte Zustand abgearbeitet und es kann dann eine Transition, also ein Übergang zu einem nachfolgenden Zustand stattfinden.

Die durch diesen Pfeil hier wieder markiert ist.

So, jetzt habt ihr also einen groben Überblick über die Notationselemente von UML-Zustandsdiagramm bekommen.

Damit ihr aber ein Verständnis davon entwickeln könnt, wie man denn Ablaufsteuerung tatsächlich damit auch entwirft.

Demonstriere ich das mal an einem Beispiel.

Ich nehme dafür ein auf den ersten Blick sehr einfaches Beispiel, nämlich die Steuerung der Tür für einen Aufzug.

Wenn die Steuerung eine Anforderung von außen bekommt, dann sollen die Türen geöffnet werden.

Und dazu muss ein Antrieb eingeschaltet werden.

Sobald die Tür komplett geöffnet ist, wird das zum Beispiel über einen Endlagenschalter erfasst.

Dann wird der Antrieb ausgeschaltet und es wird dann ein Timer gestartet.

Und nach einer bestimmten Zeit soll die Tür dann wieder geschlossen werden.

Dazu muss der Antrieb erneut gestartet werden, aber in die andere Laufrichtung.

Sobald die Türen dann wieder zu sind, wird das auch wieder über einen Endlagenschalter erkannt.

Und der Antrieb wird ausgeschaltet.

Soweit so gut.

Jetzt möchte ich aber noch zwei Erweiterungen einbringen.

Erstens soll es einen Taster geben, mit dem die Tür geschlossen werden kann, noch bevor der Timer abgelaufen ist.

Und zweitens soll nur beim Zufahren der Tür das Signal einer Lichtschranke berücksichtigt werden.

Wenn also während des Zufahrens der Tür diese Lichtschranke durchbrochen wird, soll die Tür sofort wieder aufgefahren werden.

Dann startet der Timer erneut oder es wird eben wieder der Taster zum Zufahren betätigt.

So, das Verhalten ist klar, aber wie beschreibt man das jetzt im UML-Zustandsdiagramm?

Ich starte zunächst einmal mit einem Startknoten, der auf einen Zustand führt, den ich idle nenne.

Die Tür macht hier also erstmal nichts.

Statt idle könnte man den Zustand auch init nennen und dann wird klar, was hier passieren könnte, nämlich irgendwelche Initialisierungen.

Da fällt mir jetzt aber nichts konkretes ein, also passiert hier einfach gar nichts.

Und es wird auf ein Signal bInit gewartet.

So soll jetzt die Tür in einen definierten Zustand überführt werden, indem sie geschlossen ist.

Und dazu muss das Schließen der Tür zunächst einmal eingeleitet werden.

Und das passiert in dem Zustand closing.

In der Aktion driveClose_On wird also der Antrieb zum Schließen der Tür eingeschaltet.

Und es wird darauf gewartet, dass die Endlage erreicht wird.

Diese Endlage wird hier über das Signal bLimitSwitchClosed erfasst.

Wenn also diese Transitionsbedingung wahr ist, dann wird der Zustand closing verlassen.

Aber vor dem Verlassen wird noch die Aktion driveClose_Off ausgeführt, bei der der Antrieb ausgeschaltet wird.

Wenn also dieser Zustandsübergang dann ausgeführt wurde, dann befindet sich das System im Zustand isClosed.

Also die Türen sind jetzt geschlossen.

Wenn dieser Zustand eingenommen wird, soll ein Flag gesetzt werden.

Und das passiert in der Aktion setDoneFlag.

Das ist also nur eine boolsche Variable, die angibt, dass die Tür jetzt wieder ordentlich zugefahren wurde.

Jetzt wird darauf gewartet, dass ein Signal zum Öffnen der Tür kommt und das ist dieses bOpen.

Wenn also diese Anforderung kommt, wird beim Verlassen des Zustands isClosed das Flag in der Exit-Aktion resetDoneFlag zurückgesetzt und das System geht über in den Zustand opening.

Da wird ähnlich wie beim Zustand closing der Antrieb in der Aktion driveOpen_On angeschaltet.

Und wenn der Endlagenschalter bei geöffneter Tür dann anspricht, wird wieder eine Transition ausgeführt.

Vorher wird noch der Motor ausgeschaltet in der Exit-Aktion driveOpen_Off und das System wechselt dann in den Zustand isOpen.

Dort wird dann der Timer gestartet und die Bedingung für das Verlassen des Zustands ist dann, dass der Timer abgelaufen ist.

Oder dass das Signal bClose zum Schließen der Tür kommt.

Das letzte, was im Zustand isOpen noch passiert, ist dann das Zurücksetzen des Timers.

Damit der beim nächsten Mal auch wieder ordentlich gestartet werden kann.

So und dann ist das System wieder im Zustand closing, den ich gerade schon erklärt habe.

Eine Sache habe ich jetzt hier noch nicht im Modell, nämlich das Signal der Lichtschranke.

Wenn ihr beim Schließen der Tür die Lichtschranke durchbrochen wird, soll die Tür sofort wieder aufgefahren werden.

Das ist also ein Zustandsübergang von closing nach opening, der unter der Bedingung ausgeführt wird.

Dass die Lichtschranke durchbrochen ist und das wird eben hier durch das Signal bLightBarrier repräsentiert.

So, ich hoffe, dass ihr jetzt erkennt, dass dieses UML-Zustandsdiagramm zu der Spezifikation der gesteuerten Tür passt, die ich zuvor bildlich erklärt habe.

Dieses Modell ist damit jetzt die Grundlage für die Implementierung der Ablaufsteuerung in ST.

Und das Tolle ist, wie ich finde, dass man dieses UML-Zustandsdiagramm fast Kochrezeptartig in ST-Code übersetzen kann.

Und wie das geht, zeige ich euch jetzt.

Ich starte zunächst einmal damit, einen Aufzählungsdatentypen, also ein Enum anzulegen.

Indem ich nur die Bezeichner der Zustände speichere.

Diesen Datentyp nenne ich E_DcState.

Das E steht für Enum, DC für DoorControl und State ist eben der Zustand.

So die Attribute, die in diesem Enum standardmäßig vorgegeben sind, lasse ich erstmal drin.

Wenn ihr euch fragt, was diese Attribute bedeuten, findet ihr dazu eine Erklärung in dem Video, dass ich hier oben verlinkt habe.

Okay, wie angekündigt, trage ich in diesem Enum also nur die Bezeichner meiner Zustände des Zustandsdiagramms ein.

Das Ganze mache ich, weil ich in meiner Steuerung gleich eine Variable von diesem Enum-Datentypen anlegen werde.

Die sozusagen ein Merker für den aktiven Zustand ist.

So und weil diese Merker-Variable eben keine anderen Werte annehmen kann, als die, die ich in diesem Enum definiert habe.

Kann ich damit sicherstellen, dass sich die Steuerung auch nur in Zuständen befindet.

Die im Zustandsdiagramm vorkommen.

Das Anlegen von diesem Enum ist also ein vorbereitender Schritt.

So, dann beginne ich jetzt mit der eigentlichen Implementierung der Steuerung.

Und dazu lege ich erst einmal einen Funktionsbaustein an, den ich FB_DoorCtrl nenne.

Zuerst deklariere ich jetzt die Ein- und Ausgangsvariablen und die internen Variablen.

Die Eingangsvariablen sind in diesem Beispiel hier jetzt alle Signale, um die Bedingungen an den Zustandsübergängen zu überprüfen.

Also bInit, dann die Signale für die Anforderung zum Öffnen und Schließen der Tür, bOpen und bClose.

Die Endlagenschalter bLimitSwitchOpen und bLimitSwitchClosed und das Signal von der Lichtschranke bLightBarrier.

Als Ausgangssignal definiere ich nur das Flag bDone.

Das also gesetzt wird, wenn die Tür zu ist.

Und sonst aber false ist.

So, vielleicht fragt ihr euch jetzt, was denn mit den Signalen zum Ansteuern des Antriebs ist.

Die müssten ja eigentlich auch Ausgangssignale der Steuerung sein.

Das löse ich jetzt aber anders und zwar füge ich noch eine weitere Eingangsvariable fbDrive hinzu.

Und die ist vom Typ Referenz auf eine Einzelsteuerfunktion, die ich in dem Video erklärt habe, dass hier oben wieder verlinkt ist.

Die Ansteuerung des Antriebs passiert also nicht direkt aus der Steuerung, sondern über diese Einzelsteuerfunktion.

Womit ich also schon ein bisschen eine Unabhängigkeit zwischen dieser Steuerung und der eingesetzten Hardware erreiche.

So und hier kommen jetzt die internen Variablen der Steuerung.

Als erstes brauche ich ein Enum vom Typ E_DcState, den ich eState nenne und in dem also der aktive Zustand der Steuerung gespeichert wird.

Den initialisiere ich auch gleich noch mit dem Wert idle und das entspricht auch dem Zustandsdiagramm, nachdem idle eben der Startzustand ist.

Der TON-Baustein fbTimerOpen wird verwendet zur Bestimmung der Dauer, die die Tür geöffnet ist, bevor sie automatisch wieder zugefahren wird.

Und für die Zeit, die die Tür offen bleiben soll, lege ich auch noch eine Variable tDoorOpen an.

Die Zeit von 3 Sekunden ist von mir jetzt willkürlich gewählt.

Um den Funktionsbaustein der Steuerung noch flexibler einsetzen zu können.

Könnte man diese Zeit auch als Eingangsvariable deklarieren.

Ich habe mich jetzt aber hier für diese Variante mit der fest eingestellten Zeit entschieden.

So, dann gehe ich jetzt zum Anweisungsteil und damit also zur eigentlichen Logik der Ablaufsteuerung.

Und das Interessante ist jetzt hier, wie das UML-Zustandsdiagramm in ST-Code übersetzt wird.

Das Grundgerüst dafür ist diese Case-Anweisung, in der der Zustand eState abgefragt wird.

In dieser Case-Anweisung werden jetzt die einzelnen Zustände mit den Aktionen und den Zustandsübergängen ausprogrammiert.

Ich starte jetzt hier mit dem Zustand idle.

Gemäß dem Zustandsdiagramm gibt es hierin ja keine Aktion.

Also passiert hier auch nichts.

Aber es gibt eine Transition, also einen Übergang in den Zustand closing, der ausgeführt wird, wenn das Signal bInit true ist.

Und diesen Übergang realisiere ich durch diese If-Anweisung.

Hier kann man jetzt schon den Zweck der Variablen eState erkennen.

Wenn also die Bedingung in dem If-Statement erfüllt ist, das heißt also bInit den Wert true hat.

Dann wird der Wert von eState auf closing gesetzt.

Und im nächsten Zyklus der SPS wird dann im Case-Statement der Wert von eState wieder abgefragt.

Und es wird dann eben der Fall closing abgearbeitet.

Die Programmabarbeitung bleibt dann also so lange in dem Fall closing, bis eState wieder auf einen anderen Wert gesetzt wird.

So und um das klarer zu machen.

Mache ich jetzt mit der Implementierung des nächsten Zustands closing weiter.

Hier gibt es eine Aktion, die ich im Zustandsdiagramm driveClose_On genannt habe.

Darin wird also der Antrieb zum Öffnen der Tür eingeschaltet.

Und das realisiere ich durch diesen Aufruf dieser Einzelsteuerfunktion von fbDrive.

Auf diese Weise wird der Antrieb eingeschaltet und es wird eine Fahrtrichtung und eine Geschwindigkeit gewählt.

So, mehr passiert nicht in der Aktion.

Dann kümmere ich mich um die Zustandsübergänge, von denen es in diesem Zustand zwei gibt.

Der erste in den Zustand isClosed, wenn der Endlagenschalter bLimitSwitchClosed aktiv ist.

Und der zweite in den Zustand opening, wenn die Lichtschranke bLightBarrier durchbrochen ist.

Diese Übergänge werden also wieder durch diese If-Statements umgesetzt.

In diesem Beispiel hier ist es eigentlich physikalisch ausgeschlossen, dass beide Bedingungen der If-Statements erfüllt wären.

Denn wenn die Tür komplett geschlossen ist und der Endlagenschalter dies anzeigt, wäre ja kein Platz mehr da, um noch die Lichtschranke zu durchbrechen.

Aber es kann ja andere Beispiele geben, wo es ausgehend aus einem Zustand zwei mögliche Zustandsübergänge gibt.

Deren Bedingungen gleichzeitig erfüllt sein könnten.

Die Frage ist also, welcher der beiden Nachfolgezustände soll eingenommen werden.

Wenn beide Übergangsbedingungen wahr sind.

Und hier müsst ihr als Automatisierer einfach eine Priorität festlegen.

Und das macht ihr durch die Reihenfolge der If-Statements.

In meinem Fall hat der Übergang in den Zustand opening die höhere Priorität.

Würden nämlich beide If-Statements abgearbeitet, würde zunächst eState auf den Wert isClosed gesetzt.

Aber im zweiten If-Statement würde dieser Wert mit opening überschrieben werden.

Und im nächsten Zyklus der SPS wird dann in diesem Case-Statement wieder in den Fall opening gesprungen.

So, der Zustand closing ist aber noch nicht vollständig implementiert.

Denn unabhängig davon, welcher Zustandsübergang erfolgt, ist in dem Zustandsdiagramm noch modelliert.

Dass es eine Aktion driveClose_Off gibt, nämlich wenn der Zustand closing verlassen wird.

Und in dieser Aktion soll der Antrieb ausgeschaltet werden.

Diese Aktion implementiere ich dann also als Anweisung in den If-Statements.

Egal welcher Zustandsübergang erfolgt, wird also diese Aktion einmal ausgeführt und dann wird der Zustand verlassen.

So, auf dieselbe Weise wie diese beiden Zustände werden auch die restlichen Zustände implementiert.

Und da gehe ich jetzt nicht mehr im Detail auf alle Codezeilen ein.

Hier im Zustand isOpen wird in der Aktion runTimer der Timer durch diese Anweisung gestartet.

Und in der Bedingung für den Zustandsübergang in den Zustand closing wird dann also der Ausgang Q des Timers abgefragt.

Und hier seht ihr auch noch ein Beispiel, dass diese Übergangsbedingung eine logische Verknüpfung sein kann.

Denn wenn vor Ablauf des Timers das Signal bClose gesetzt wird, ist durch diese Oder-Verknüpfung die Übergangsbedingung eben auch erfüllt.

Wichtig ist hier jetzt noch, dass in der Ausgangsaktion der Timer zurückgesetzt wird.

Damit dieser das nächste Mal, wenn der Zustand ist Open angenommen wird, eben wieder durch eine steigende Flanke erneut gestartet werden kann.

So, das wäre also die vollständige Implementierung des UML-Zustandsdiagramms in ST-Code.

An einer Stelle habe ich aber ein bisschen geschummelt, nämlich im Zustand isClosed.

Gemäß dem Zustandsdiagramm gibt es hier eine Eingangsaktion setDoneFlag, mit der die Variable bDone auf true gesetzt werden soll.

Das mache ich in meinem Programm auch.

Allerdings nicht nur einmal, wie in der Eingangsaktion definiert ist.

Sondern eben in jedem Zyklus, in dem der Zustand aktiv ist.

Das heißt, ich behandle hier diese Entry-Aktion wie eine Do-Aktion.

In diesem Beispiel hat das keine Auswirkung, aber es ist eben nicht ganz korrekt.

Also ändere ich die Programmierung noch einmal, um euch zu zeigen.

Wie man diese Entry-Aktion korrekt implementieren kann.

Dazu deklariere ich noch eine weitere interne boolsche Variable bEntryAct_isClosed.

Und initialisiere die mit false.

Diese Initialisierung ist zwar nicht zwingend nötig, weil der Default-Wert von Bool-Variablen ohnehin false ist.

Aber ich mache das jetzt, um vollständige Klarheit zu schaffen.

So im Zustand isClosed frage ich dann als erstes ab, ob diese Variable nicht true ist.

Und wenn das zutrifft, dann wird die Aktion setDoneFlag ausgeführt und zusätzlich wird dann diese neue Variable auf true gesetzt.

Das heißt also, wenn der Zustand isClosed eingenommen wird, wird dieses If-Statement nur einmal ausgeführt.

Und damit eben auch alle Anweisungen, die hierin enthalten sind.

Ganz wichtig ist jetzt noch, dass diese Variable bEntryAct_isClosed wieder auf false gesetzt wird, wenn der Zustand verlassen wird.

Denn nur so kann ich ja sicherstellen, dass diese Entry-Aktion das nächste Mal, wenn der Zustand eingenommen wird.

Eben auch wieder ausgeführt wird.

Okay, damit ist also die Steuerung wirklich vollständig implementiert.

Und die setze ich jetzt ein, um euch an meinem Demosystem das Verhalten der gesteuerten Tür praktisch und anschaulich zu demonstrieren.

Dazu habe ich dieses kleine Main-Programm hier geschrieben.

Zunächst deklariere ich hier einige Variablen und Funktionsbausteine.

IDF_Stepper ist eine Einzelsteuerfunktion zur Ansteuerung des Schrittmotors.

Und bStepperEn und nStepperVal sind Variablen, die ich mit den Signalen der Klemme des Motors verbunden habe.

Und das ist eben ein Freigabesignal und die Vorgabe der Geschwindigkeit.

bCallOpen, bCallClose und bCallInit sind die Eingänge in die Steuerung für die Anforderung zum Öffnen und Schließen der Tür bzw. zur Initialisierung.

Und diese Signale habe ich mit diesen Tastern hier verknüpft.

So bLSOpen_sim und bLSClosed_sim sind dann die Signale der Endlagenschalter.

Richtige Endlagenschalter habe ich hier nicht, aber ich nutze hier diese Näherungssensoren dafür.

Und die Tür selber wird durch diesen roten Block dargestellt, der gleich also auf dem Transportband hin und her gefahren wird.

Und dadurch eben das Öffnen und das Schließen der Tür nachahmt.

So und dann gibt's ja noch das Signal der Lichtschranke, das habe ich hier bLB_sim genannt.

Und mit diesem Taster ganz rechts hier verbunden.

bDone_loc ist das Fertigsignal der Steuerung.

Dass ich mit dieser LED hier verknüpft habe.

So und schließlich deklariere ich hier noch den Funktionsbaustein der Steuerung, den ich FB_myDoor nenne.

Im Anweisungsteil rufe ich dann den Funktionsbaustein der Steuerung auf, übergebe die entsprechenden Variablen.

Und mache dann noch die Zuweisung der Signale aus der Einzelsteuerfunktion zu den Signalen der Motorklemme.

Okay, und dann kann die Demo auch starten.

Zu Beginn liegt der Block irgendwo zwischen den beiden Endlagenschalter, was also bedeutet, dass die Tür halb geöffnet ist.

Also einen nicht definierten Zustand hat gemäß dem Zustandsdiagramm.

Dann betätige ich den Taster zur Initialisierung und dann wird die Tür zugefahren.

Der Block also hier nach rechts geschoben, bis die Endlage erreicht ist.

Wenn der Block ganz rechts angekommen ist, leuchtet die LED und zeigt damit an, dass das Signal bDone gesetzt ist.

Und die Steuerung sich im Zustand isClosed befindet.

Jetzt wartet die Steuerung dann auf eine Anforderung zum Öffnen der Tür.

Und die gebe ich durch Drücken dieses Tasters hier.

Dann öffnet sich die Tür, bis die Endlage hinten erreicht ist.

Dann startet der Timer mit der Zeit von 3 Sekunden.

Und dann wird die Tür wieder zugefahren, bis eben wieder die Endlage zu erreicht wird.

So, jetzt öffne ich die Tür noch ein zweites Mal.

Und wenn die Tür dann wieder zufährt, simuliere ich durch Drücken dieses Tasters eine Durchbrechung der Lichtschranke.

Jetzt seht ihr, dass die Tür die Fahrtrichtung wechselt und wieder auffährt.

Und wenn die Tür jetzt ganz geöffnet ist, gebe ich das Signal zum Schließen der Tür.

Jetzt wird die Tür also geschlossen, noch bevor der Timer abgelaufen ist.

Okay, damit habe ich jetzt das Verhalten der Steuerung in allen Zuständen und Zustandsübergängen an dieser Demonstration einmal praktisch gezeigt.

Zu Beginn dieses Videos habe ich ja schon erwähnt, dass die IEC 61131 speziell für die Implementierung von Ablaufsteuerung eine eigene Sprache anbietet, nämlich die Ablaufsprache.

Wie genau ihr in dieser Ablaufsprache programmiert, werde ich hier nicht thematisieren.

Dazu findet ihr in der Literatur oder auch auf YouTube andere Kanäle und Videos, die das ganz gut erläutern.

Ich werde jetzt hier nur einmal die vollständig in der Ablaufsprache implementierte Türsteuerung vorstellen.

Um euch die Analogie zum UML-Zustandsdiagramm zu zeigen.

Für diese zweite Art der Implementierung der Steuerung habe ich im Projektmappen-Explorer wieder einen Funktionsbaustein angelegt und der heißt auch wieder FB_DoorControl, aber mit dem Zusatz _AS.

Und als Sprache für die Implementierung habe ich hier natürlich die Ablaufsprache gewählt.

Okay, der Deklarationsteil dieses FBs ist mit Ausnahme des Namens fast komplett identisch.

Mit dem Funktionsbaustein, den ich zuvor in ST implementiert habe.

Eine interne Variable habe ich jetzt hier aber nicht, die ich bei der Umsetzung in ST hatte.

Nämlich den Merker für den Zustand vom Typ E_DcState.

Aber bezüglich der Ein- und Ausgaben ist dieser Funktionsbaustein also gleich mit der Realisierung in ST.

Was auch gleich noch mal für die Verwendung im Main-Programm wichtig ist.

Jetzt gehe ich auf den Anweisungsteil ein und der ist eben in dieser Blockorientierten Sprache programmiert.

Jeder Block entspricht also einem Zustand aus dem Zustandsdiagramm und die Blöcke haben auch Namen, die mit den Bezeichnungen aus dem Modell übereinstimmen.

Der Block idle hat einen doppelten Rahmen.

Und ist damit als Einstiegszustand definiert.

Die Übergänge zwischen den Zuständen sind durch diese Linien hier markiert.

Und die Bedingungen für die Transition seht ihr an diesen Balken angetragen.

Und diese Bedingungen entsprechen eben auch wieder den Angaben im Zustandsdiagramm.

Bei der letzten Transition hier ganz unten seht ihr dann noch einen Pfeil, das ist eine sogenannte Sprungmarke.

Wenn die Steuerung an dieser Stelle angekommen ist, springt sie also in den hier angegebenen Zustand, also in closing.

Was man aus der Darstellung in der Ablaufsprache nicht unmittelbar entnehmen kann ist, welche Aktion in dem jeweiligen Zustand ausgeführt werden.

Allerdings sieht man, dass Aktionen ausgeführt werden.

Ein E in der linken unteren Ecke eines Zustands bedeutet, dass eine Entry-Aktion ausgeführt wird.

Das X heißt, dass es hier eine Exit-Aktion gibt.

Und diese ausgefüllte Ecke hier oben rechts heißt, dass eine Do-Aktion definiert ist.

Diese Aktionen könnt ihr einem FB hinzufügen, wenn ihr mit Rechtsklick auf den FB klickt.

Und dann hinzufügen Aktionen wählt.

Dann müsst ihr der Aktion einen Namen geben.

Am besten Fall ist das derselbe wie der, den ihr im Zustandsdiagramm gewählt habt.

Und dann könnt ihr wieder auswählen, in welcher Sprache diese Aktion implementiert werden soll.

In meinem Beispiel habe ich da immer die Sprache ST gewählt.

So und wie diese Aktionen bei der Türsteuerung aussehen, zeige ich euch einmal im Schnelldurchlauf.

In closing gibt es also eine Do-Aktion, in der der Motor gestartet wird.

Und in der Exit-Aktion wird der Motor gestoppt.

Wenn die Tür zugefahren ist, gibt es in isClosed eine Entry-Aktion, in der das Done-Flag gesetzt wird.

Und in der Exit-Aktion wird das Flag wieder zurückgesetzt.

Der Zustand opening verhält sich ähnlich wie closing.

Da wird also wieder der Antrieb eingeschaltet.

Und beim Verlassen des Zustands wird der Antrieb ausgeschaltet.

Und in is_Open wird dann der Timer gestartet, um beim Verlassen wieder zurückgesetzt.

So, das ist also die Steuerung in der Ablaufsprache.

Und die kann ich jetzt auch wieder in meinem Main-Programm ganz einfach einbinden.

Weil nämlich die Deklaration der Steuerung hinsichtlich der Ein- und Ausgangssignale identisch ist mit der vorherigen Implementierung in ST.

Daher kann ich jetzt einfach in der Deklaration des FBs in Main den Datentypen ändern.

Und dazu ergänze ich hier ein _AS.

So, das ist auch schon alles.

Auf eine praktische Demo zu dieser Implementierung verzichte ich jetzt aber, weil ihr da überhaupt keinen Unterschied sehen würdet.

Im Vergleich zu dem, was ich euch vorher schon gezeigt habe.

So, mit der Ablaufsprache habe ich euch also eine alternative Möglichkeit für die Implementierung von Ablaufsteuerung aufgezeigt.

Bleibt dann die Frage, welche Sprache man denn jetzt für die Implementierung von Ablaufsteuerung wählen sollte.

Darauf kann man keine allgemeingültige Antwort geben.

Wenn diese Wahl wirklich frei und nicht durch andere Rahmenbedingungen.

Also z.B. aus einem Projekt oder Vorgaben von Kundenseite vorgegeben ist.

Entscheiden die Präferenzen des Programmierers.

Die Ablaufsprache hat den Vorteil, dass man die Struktur der Schrittkette auf einen Blick erfassen kann.

Andererseits sind die Implementierung der Aktion ziemlich verteilt.

So dass man eben nicht so schnell nachvollziehen kann, welcher Code denn wirklich in welchem Zustand abgearbeitet wird.

Das wiederum ist der Vorteil bei der Implementierung in ST.

Hier hat man nämlich die gesamte Implementierung der Steuerung in einer Datei.

Vom Aufzählungsdatentypen mal abgesehen.

Und man hat mehr Freiheiten, um z.B. auch Transitionsabhängige Aktionen zu programmieren.

Die es in der Ablaufsprache nicht gibt.