Der zentrale Punkt ist eine tiefe Diagnose des Systemstatus. Allerdings machen SPS-Programmierer oft den Fehler, sich zuerst auf die Funktion des Systems zu konzentrieren und erst danach die Fehlerbehandlung zu implementieren. Dies hat zur Folge, dass das Fehlerdiagnosesystem nicht vollständig ist. Die Maschine wird laufen. Wenn jedoch spätere Komponenten aufgrund von Verschleiß nicht mehr richtig funktionieren oder Einstellungen vorgenommen werden, die so nicht funktionieren können, stoppt das System ohne Fehler oder die angezeigte Meldung führt zunächst in die falsche Richtung. Darüber hinaus geht Zeit bei der Inbetriebnahme einer weiteren Maschine verloren, weil das Debugging im Quellcode erneut erforderlich ist, und das obwohl die Software eigentlich funktionieren sollte.
Das Herzstück jeder automatisierten Maschine
Wo gibt es Potenzial für Verbesserungen?
Als Entwickler konzentrieren wir uns auf die Funktion. Was wird derzeit benötigt? Wie ist der Prozess?
Um schnell einen Fortschritt präsentieren zu können, wird die Fehlerbehandlung und die Möglichkeit von erweiterten Funktionen oft vernachlässigt. Der scheinbare Vorteil hat jedoch nicht ganz unerhebliche Nachteile:
- Erst die Konzentration auf die Funktion gibt uns einen vollständigen Überblick über alle unerwarteten Störungen. Dieses tiefe Verständnis kehrt nicht mehr zurück, wenn der Ablauf abgeschlossen ist.
- In diesem Moment sehen wir auch am besten alle Möglichkeiten, die diese Funktion zusätzlich bieten kann. Später wird es schwierig werden, weitere zu implementieren. Aber am Ende des Projekts wird der Kunde aber vielleicht genau diese Anforderung haben wollen.
Nächste Stufe: Objektorientierte Programmierung
Oh ja, für viele SPS-Programmierer ein Albtraum. Völlig unbegründet!
Um dies zu verstehen, müssen wir eine kurze Reise in die Vergangenheit machen. Ältere Steuerungssysteme wie die des Marktführers Siemens (S3 und S5) unterstützen keine objektorientierte Programmierung. Mit der S7-300/400 AG’s wurde es möglich, wenn auch noch sehr eingeschränkt. Allerdings hatte sich der S5-Programmierstil bei vielen Programmierern durchgesetzt. Wiederverwendbare Funktionen wurden nur auf der untersten Ebene verwendet. Wenn es identische Maschinenteile gab, wurden die Programmteile stur kopiert. Dazu gab es im Editor Funktionen wie „Umverdrahten“, um die Programmteile voneinander zu entkoppeln. Bis heute unterstützt der Marktführer Siemens die echte Objektorientierung nicht bis ins Detail. Auch im TIA-Portal besteht noch großer Nachholbedarf bei der Hardware-Anbindung.
Daher ist es nicht überraschend, dass viele SPS-Programmierer oft noch Vorbehalte gegen die Objektorientierung in der SPS haben.
Mit der richtigen Entwicklungsstrategie sparen wir eine Menge Zeit. Im Idealfall sollte jede Funktion nur einmal programmiert und dann so oft wie möglich wiederverwendet werden. Moderne SPS-Entwicklungstools unterstützen sogar Vererbung, Eigenschaften, Methoden und Aktionen. Selbst die Verbindung zur Hardware durch direkte Verknüpfung mit der Instanz macht die Programmierung einfacher und effizienter. Mit genau der gleichen Stategie kann man auch das HMI mit anbinden.
Das Bild, das Sie sehen können, ist ein einfacher Entwurf, was Objektorientierung eigentlich bedeutet. Im Idealfall kann es mehrdimensional erweitert werden. Zum Beispiel über folgende Ebenen: Maschine, Anlagenteil, Betriebsartenbereich, Funktionsgruppe, Funktion, Komponententreiber. Mit dieser Struktur ist es dann sehr einfach, eine Modularität wie hier. beschrieben zu integrieren.
Das können Sie erwarten
Möchten Sie ein Projekt besonders kosteneffizient und flexibel realisieren?
Wollen Sie sich es selbst überzeugen? Lassen Sie uns über ein Projekt sprechen.
Setzen Sie sich mit uns in Verbindung.