In vielen Anlagen werden Ein- und Ausgänge direkt im SPS‑Programm angesteuert. Was am Anfang schnell funktioniert, führt in der Praxis oft zu unübersichtlichem Code, langen Stillstandzeiten und hohem Aufwand bei Änderungen. Besonders bei Anlagen mit vielen Zylindern oder Aktoren entsteht schnell ein Chaos aus Signalen, Abhängigkeiten und Abfragen.
Genau hier setzt eine strukturierte Ansteuerung der SPS‑Hardware mit Funktionsbausteinen an.
Typische Fehler/Probleme in der Praxis
- direktes Beschalten der Ausgänge
- unübersichtlicher Code
- Hoher Aufwand bei Erweiterungen
Praxisbeispiel: Ventilansteuerung im TIA Portal
In diesem Artikel zeige ich anhand des Beispiels „Ventilansteuerung im TIA Portal“, wie sich Hardware im SPS‑Programm sauber strukturieren lässt und warum Funktionsbausteine dabei eine zentrale Rolle spielen.
Ausgangssituation
- Doppelwirkender Zylinder
- 2 Ausgänge (5/2 Wege Ventil)
- 2 Eingänge (Endlagensensoren Zylinder)
Das Ventil bzw. der Zylinder erhält den beispielhaften Namen „Greifer Bauteil“ und hat eine Grundstellung (offen) und eine Arbeitsstellung (geschlossen). Die Deklarierung der Ein- und Ausgänge sieht folgendermaßen aus:
An dieser Stelle hören manche SPS-Programmierer auf. Im Gesamten Programm werden zum Bewegen des Zylinders die Ausgänge direkt geschrieben und anschließend die Eingänge abgefragt. Dadurch wird ein SPS-Programm schnell unübersichtlich und unnötig kompliziert. Bei einer Anlage mit 30 oder mehr Zylindern entsteht schnell ein Chaos aus dem Beschalten und Abfragen der verschiedenen Ein- und Ausgänge im Code. So sollte Hardware über eine SPS nicht angesteuert werden, da in solchen Fällen ohne strukturierte SPS-Programmierung die Übersicht und Wartbarkeit einer Anlage deutlich sinken. Die Programmierung im TIA Portal bietet dafür bessere Lösungen.
Erstellung eines Funktionsbaustein
Daher wird ein Ventil Funktionsbaustein mit folgender Schnittstelle erstellt:
Der FB soll nach dem folgenden Prinzip arbeiten:
- Signal „CMD_Base“ wird auf True gesetzt
- Funktionsbaustein schaltet Ausgang „Valve_Base“ ein und „Valve_Work“ aus
- Zylinder fährt in Grundstellung
- Mit Erreichen des Sensors für Detektion der Grundstellung, wird der Ausgang „State_Base“ eingeschaltet
- Baustein schaltet Signal „CMD_Base“ aus
Ein zugehöriger Datentyp und Ventil Datenbaustein sieht dann folgendermaßen aus:
Aufruf des Funktionsbausteins
Für eine sehr einfache Wiederverwendbarkeit des Funktionsbausteins und somit eine gute Skalierbarkeit des SPS-Programms auf große Anlagen, gehen wir für den Aufruf folgendermaßen vor.
Nach der Erstellung der Anwenderkonstanten „BauteilGreifer“ (Datentyp INT mit Wert = 1) wird eine Ventil Funktion (FC) erstellt und der Funktionsbaustein wie folgt aufgerufen:
Durch diesen gut strukturierten Aufruf kann innerhalb einer Minute ein Aufruf für einen weiteren Zylinder hinzugefügt werden.
Durch diese Struktur befinden sich alle Ventile sehr übersichtlich in einem Datenbaustein. Wenn nun ein Ventil in einem Automatik Ablauf betätigt und anschließend abgefragt werden soll, dann wird immer der gleiche Datenbaustein verwendet. Es wird nur die entsprechende Anwenderkonstante benötigt, anstatt unter etlichen SPS Ein- und Ausgängen die richtigen auszuwählen.
Zentrales Fehlerhandling im Funktionsbaustein
An jeder Stelle im SPS-Programm, in dem ein Ventil betätigt und anschließend abgefragt wird, ist ein Fehlerhandling notwendig. Dieses soll zentral vom Ventil Funktionsbaustein übernommen werden. Dadurch kann das aufwendige Erzeugen einer Fehlermeldung an verschiedenen Stellen im SPS-Programm vermieden werden. In der Praxis reduziert dieses Vorgehen nicht nur den Programmieraufwand, sondern auch Stillstandszeiten und Fehleranfälligkeit im Betrieb erheblich. Mit dem Setzen eines CMD Eingangs des Funktionsbaustein wird ein Timer gestartet. Wenn innerhalb der Ventilüberwachungszeit, nicht die richtige Rückmeldung vom Sensor anliegt, dann soll ein Fehler erzeugt werden. Dafür wird die Schnittstelle des Funktionsbaustein wie folgt erweitert:
Die Ventilüberwachungszeit kann ein globaler Parameter sein oder für jedes Ventil separat definiert werden. Der Ausgang für die Störmeldung muss in das globale Fehlerhandling integriert werden.
Aktive Freigabe der Kommandos
Eine weitere sinnvolle Funktion ist das Sperren bzw. aktive Freigeben der Kommandos. In vielen Anlagen gibt es mehrere pneumatische Funktionen, die mechanisch voneinander abhängig sind. Zum Beispiel wenn Zylinder C nur bewegt werden darf, wenn sich Zylinder A in Grundstellung und Zylinder B in Arbeitsstellung befindet. Dafür wird der Ventil Funktionsbaustein um 2 Freigabe Eingänge erweitert. Die Kommandos für Base und Work werden nur noch angenommen, wenn die entsprechende Freigabe TRUE ist. Die Schnittstelle und der Aufruf des Funktionsbausteins sehen dann folgendermaßen aus:
Diese Funktion schafft mit einfachen Mitteln Schutz vor unbeabsichtigten Maschinenschäden. Vor allem in der Inbetriebnahme Phase, den ersten Automatik Testläufen oder im Handbetrieb kann diese Funktionen den ein oder anderen Schaden an der Anlage verhindern. Bei Bedarf kann der Funktionsbaustein noch um eine Fehlermeldung erweitert werden. Diese wird ausgegeben, wenn ein Kommando ohne entsprechende Freigabe eingeschaltet wird.
Trennung von Hand- und Automatikfunktionen
Nun gilt es das Ventil auch im Handbetrieb der Anlage bedienbar zu machen ohne Handbetrieb und Automatik Funktionen zu vermischen. Dafür wird der Ventil Funktionsbaustein um Signale für Tasten erweitert. Diese Signale können direkt mit Tasten auf dem HMI gekoppelt werden. Außerdem muss die aktuelle Betriebsart an den Funktionsbaustein übergeben werden, um die Funktion der Tasten nur im Handbetrieb freizugeben. Alternativ können auch separate Freigabe Signale für den Handbetrieb erstellt werden, zur Trennung von Hand- und Automatik Funktionen.
Zusammenfassung
Alle TIA-Funktionsbausteine die Hardware direkt ansprechen, sollten möglichst viele Aufgaben direkt übernehmen, wie am Beispiel des Ventil Funktionsbaustein gezeigt:
- Beschalten der Ein- und Ausgänge
- Fehlerhandling
- Betriebsarten abhängiges Steuern
- Kollisionsschutz Handling mit anderen Funktionen
Erweiterungen und Best Practices
Der Ventil Funktionsbaustein kann auch noch um einige Funktionen erweitert werden, z.B:
- Verschiedene Ventilarten (5/3er oder 3/2er Ventil)
- Entprellzeit für Zylinder Sensoren
- Nutzen von Zeiten statt Endlagensensoren
- mehrere Zylinder mit einem Ventil steuern
Fazit
Zusammenfassend lässt sich sagen, dass alle TIA-Funktionsbaustein, die Hardware direkt ansprechen nach dem folgenden Prinzip arbeiten sollten:
- Der Funktionsbaustein bekommt ein Kommando oder einen Start Befehl inklusive eines Parameter Satzes von einer Ablauf Steuerung etc.
- Die Hardware wird durch den Funktionsbaustein gestartet und der Befehl wird abgearbeitet
- Wenn der Befehl abgearbeitet wurde, gibt der Funktionsbaustein entweder eine „Fertig“ Meldung oder eine Fehler Meldung zurück
- Danach meldet der Funktionsbaustein Bereitschaft für den nächsten Befehl
In der Praxis zeigt sich immer wieder:
Nicht die Anzahl der Ein- und Ausgänge entscheidet über die Komplexität einer Anlage, sondern die Struktur im SPS‑Programm.
Eine saubere Ansteuerung der Hardware über Funktionsbausteine sorgt für stabile Abläufe, eine schnellere Fehlersuche und deutlich einfachere Erweiterungen.
Gerade bei wachsenden Anlagen ist das ein entscheidender Faktor für Produktivität und Verfügbarkeit.
Wenn Sie Ihre SPS‑Programme strukturieren oder bestehende Anlagen optimieren möchten, unterstütze ich Sie gerne.