Das Herzstück jeder automatisierten Maschine

Kann eine SPS die Benutzererfahrung unterstützen? Glauben Sie nicht? Sie kann es hervorragend!

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.

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.
Eine umsichtige Programmierung zahlt sich am Ende aus. Für einen Moment mag es scheinen, dass es keine nennenswerten Fortschritte gibt. Aber am Ende erhöht sich die Arbeitsgeschwindigkeit enorm. Das Debugging wird immer weniger notwendig. Zusätzliche Anforderungen können schneller umgesetzt werden. Das Beste ist jedoch, dass das typische „Schwimmen“ des Programmierers in der letzten Phase des Projekts vermieden werden kann.

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.

Image by AndGra on Pixabay

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

Verbesserte Benutzererfahrung

Wir legen mehr Wert auf die Diagnose, was die Ausfallzeiten einer Anlage reduziert. Der Fehler wird schneller gefunden. Dies verkürzt oft auch die Inbetriebnahmezeit einer Anlage und ein Software-Entwickler ist nicht immer notwendig.

Die Erweiterung der Maschine wird einfacher

Die objektorientierte Software-Entwicklung ermöglicht eine sehr einfache und schnellere Instanzierung einer weiteren bereits vorhandenen Komponente. Außerdem ist der Wiedereinstieg in bestehende Software für die beabsichtigte funktionale Erweiterung schneller möglich.

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.