Vererbung und die Kunst des Schachtelns?

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

@the_muck

Bevor du dich in Details stürzt, muss die Strukturierung klar sein.
Damit steht und fällt im Prinzip alles.
Es gibt die 2 Ansätze Top-Down (Vom Großen zum Kleinen) oder Buttom-Up (Vom Kleinen zum Großen).
Macht ihr z.B. Intralogistik / Fördertechnik dann ist Top-Down eine gute Möglichkeit. Du hast eine ganze Fertigungslinie und zergliederst diese in einzelne Abschnitte, Heber, Pufferstrecken, ...
Macht ihr kleinere Anlagen und jede ist anders, dann ist Buttom-Up besser.
Eine Anlage besteht aus einzelnen Aktoren (Zylinder, Motoren, Achsen, ...). Diese setzen sich zu Funktionsgruppen und diese wiederum zu Stationen.
Bei Buttom-Up muss man aber aufpassen, dass es nicht zu kleingliedrig wird.
Es ist nicht verkehrt, wenn sich im SPS-Programm auch die eigentliche Projektstruktur (Mechanik, Hardwarepläne, ...) wiederfinden lässt.
Es macht keinen Sinn, wenn du eine komplett andere Struktur aufbaust als die anderen Gewerke. Also am Besten vorher abstimmen.
Bevor du also an Dinge wie Vererbung oder Polymorphie gehst, erst mal Abstraktion und Kapselung abarbeiten.
Das geht auch mit ganz normaler SPS-Programmierung. Bei Siemens hast du auch fast keine weiteren Möglichkeiten.

 

[roboticBeet]

OOP

Definiere mal, was für dich OOP ist. Prinzipiell kann man das Konzept der FBs ja bereits als Kapselung und damit als eine Säule der OOP betrachten. TIA kann ja auch nichts anderes. Es gibt sogar ein Buch "OOP im TIA Portal", welches im Prinzip nichts anderes beschreibt. In meinen Augen ist das aber lediglich die ganz normale Verwendung von FBs. Entspricht aber bereits in Teilen des Kapselungskonzepts.

Deklariert ihr die IOs im FB oder in den IO Karten. Sammelt ihr die Ausgänge in einem Baustein?

Mehr oder weniger ja. Genauer gesagt haben wir eigene FBs für IOs. Also bspw. einen FB_DigitalInput und einen FB_DigitalOutput. Darin ist das jeweilige Signal mit AT%I* bzw. AT%Q* deklariert und wird entsprechend gemappt. Ich würde dies aber noch nicht als OOP bezeichnen, sondern als Best Practice für die Programmierung mit TwinCAT oder Codesys.

ich habe hier zumindest mal für mich nette Erklärungen zu verschiedenen Themen gefunden.

Stefan Henneken

Chief Spaghetti Coder

stefanhenneken.net

Das ist wirklich ein guter Blog, geht aber hinsichtlich der Entwurfsmuster auch wirklich in die Tiefe! Vor allem, wenn es um die Übersetzung dieser Alltagsbeispiele in konkrete Anwendungen in Maschinenanwendungen geht.

Wie schon von mir und @Blockmove geschrieben, ist Dokumentation und Vorüberlegung / Strukturierung essentiell, wenn man ernsthaft mit OOP Mitteln arbeiten möchte. Die notwendigen Strukturen und Überlegungen schüttelt man sich nicht aus dem Ärmel, wenn man mit dem PG neben der Maschine sitzt und eventuell sogar zeitlicher Druck da ist.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Definiere mal, was für dich OOP ist. Prinzipiell kann man das Konzept der FBs ja bereits als Kapselung und damit als eine Säule der OOP betrachten. TIA kann ja auch nichts anderes. Es gibt sogar ein Buch "OOP im TIA Portal", welches im Prinzip nichts anderes beschreibt. In meinen Augen ist das aber lediglich die ganz normale Verwendung von FBs. Entspricht aber bereits in Teilen des Kapselungskonzepts.

Im besten Fall überträgst du die Kapselung auf die anderen Gewerke.
Dann hast du ein einheitliches, durchgängiges Gesamtprojekt. Alle reden vom Gleichem.
Die eigentliche Programmierung ist dann der letzte Schritt.
Ob dann weitere OOP-Möglichkeiten sinnvoll sind, siehst du ja dann.

 

[Larry Laffer]

TIA kann nicht wirklich OOP - jedenfalls nicht so, wie es z.B. Codesys oder TwinCat kann.
Man kann in TIA also nicht wirklich Baustein 1 als Basis für Baustein 2 hernehmen - ich halte dieses Verfahren allerdings in SPS-Umfeld für nicht ganz ungefährlich (es ist wenigstens für den Endnutzer meißt undurchsichtig und unverständlich - also fast schon eine Art Kopierschutz). Ich habe allerdings auch schon Inbetriebnahmen erlebt bei denen der Programmierer (der hatte es wirklich erstellt und war nicht der Inbetriebnehmer) durch sein eigenes "Gewurschtele" nicht mehr durchgestiegen ist - das kann also auch passieren ...

Nach meiner Meinung sollte man das absolut OOP-Mögliche aus der SPS herauslassen und bei den PC's lassen, da man dort auch wesentlich bessere Debugging-Möglichkeiten hat.

 

[DerOnkel]

Nach meiner Meinung sollte man das absolut OOP-Mögliche aus der SPS herauslassen und bei den PC's lassen, da man dort auch wesentlich bessere Debugging-Möglichkeiten hat.

Dem stimme ich nicht zu. OOP ist für höhere Funktionen ideal und robust, da durch das Interface nur definierte Zustände ermöglicht werden.
Aber ein Negativ Beispiel möchte ich gerne nennen, wenn man eine Basisklasse anlegt wie ein Behälter mit Füllstand, nächstes Extend Füllstand mit Ablassventil, nächstes Extend Füllstand mit Ablassventil und Abreinigung usw… Das macht es extrem unübersichtlich und gnade dem der dort etwas sucht.

Debugging ist nicht ganz so trivial, wenn man keine Tools integriert hat. Hat man allerdings ein Trace integriert, wird die Fehlersuche erleichtert, besonders wenn es sich um Pseudofehler handelt.

Nach meiner Erfahrung bläht sich der Code um einen großen Faktor auf. Ich hatte letztens ein Trocknerband(Erweiterung), das war an sich nichts großes, zuvor mit 900 Zeilen AWL jetzt knapp 4000 Zeilen in ST ohne OOP da noch mit Codesys 2.3 geschweißt wurde, mit OOP wäre da noch einiges dazu gekommen.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

@DerOnkel
Irgendwie interessant ... Du stimmst Larry zwar nicht zu, nennst aber eigentlich die gleichen Argumente wie er.

Ein definiertes Interface ist auf jeden Fall ein Vorteil. Ganz klar.
Extend bzw. Vererbung sind die Dinge, die wachsen müssen.
Wenn man Anlagen / Maschinen aus einem Baukasten zusammensetzen kann und mit gepflegten Bibliotheken arbeitet, dann ok.
Entsteht das SPS-Programm zu 70% auf der Baustelle, dann eher nein.

 

[georg28]

Für Datenaufbereitung/ Handling ist OOP in der SPS nicht schlecht. Für den Steuerungteil eher nicht, Siehe der TwinCat Eventlogger für Meldungen. Der ist schon ein ziemliches Monstrum und bietet auch viele Möglichkeiten, aber den für den Zweck zu gebrauchen dass auch ein Instanthalter Fehler innerhalb des Programms findet ohne das er ganz tief in der Struktur des Programms drin ist gar nicht einfach. Auch Beobachten von Werten innerhalb des Programms gehen oft verloren

 

[DerOnkel]

@DerOnkel
Irgendwie interessant ... Du stimmst Larry zwar nicht zu, nennst aber eigentlich die gleichen Argumente wie er.

Ein definiertes Interface ist auf jeden Fall ein Vorteil. Ganz klar.
Extend bzw. Vererbung sind die Dinge, die wachsen müssen.
Wenn man Anlagen / Maschinen aus einem Baukasten zusammensetzen kann und mit gepflegten Bibliotheken arbeitet, dann ok.
Entsteht das SPS-Programm zu 70% auf der Baustelle, dann eher nein.

Das stimmt da habe ich mich verlesen. Für mich klang das so „ absolut OOP aus der SPS herauslassen“, mein Fehler.

Ich glaube wenn 70% auf der Baustelle entstehen, ist mit einer großen Bibliothek das Arbeiten leichter, denn der Ablauf wird dadurch immer abstrakter. Aber praktische Erfahrungen habe ich damit nicht, da unsere Technologen gut planen.
Ändert sich bei dir die Hardware oder der Ablauf?

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde behaupten, dass wenn der Großteil eines Programms auf der Baustelle (also beim Kunden) entsteht dann ist das Ergebnis eher "unterste Schublade" - sorry ... das habe ich bislang ohne Ausnahme so kennengelernt ...

Ändert sich bei dir die Hardware oder der Ablauf?

Die Hardware eigentlich nicht, dass bei der finalen Inbetriebnahme aber festgestellt wird, dass ein Ablauf von einem Aggregat (nicht der Anlage selbst) modifiziert werden muss ist eigentlich keine Seltenheit und passiert nach meiner Meinung auch bei bester Planung schon mal ...

 

[Blockmove]

Ich glaube wenn 70% auf der Baustelle entstehen, ist mit einer großen Bibliothek das Arbeiten leichter, denn der Ablauf wird dadurch immer abstrakter. Aber praktische Erfahrungen habe ich damit nicht, da unsere Technologen gut planen.
Ändert sich bei dir die Hardware oder der Ablauf?

Sagen wir mal so: Es gibt Bibliotheken und Bibliotheken
Mit manchen sind Änderungen kein Problem und bei wieder anderen hast du keine andere Möglichkeit als zu improvisieren (oder hart gesagt zu pfuschen). Da spielt es keine Rolle ob OOP oder herkömmlich programmiert. Das sind einfach Themen rund um Software-Design und Firmenphilosophie.

 

[mgl]

Sagen wir mal so: Es gibt Bibliotheken und Bibliotheken
Mit manchen sind Änderungen kein Problem und bei wieder anderen hast du keine andere Möglichkeit als zu improvisieren (oder hart gesagt zu pfuschen). Da spielt es keine Rolle ob OOP oder herkömmlich programmiert. Das sind einfach Themen rund um Software-Design und Firmenphilosophie.

Bei OOP hast du die Möglichkeit von dem Zu-optimierenden-Bibliotheksbaustein zu erben und Methoden zu überschreiben die Dir nicht passen. vorausgesetzt die Schnittstellen passen.

Bei dem Thema zu nicht nachvollziehbaren Events:
Man kann seinen Prozeduralen Code ohne OOP auch so verwursteln, dass man nicht mehr weiß woher die Quelle kommt. Das hängt eben ganz von der Implementierung wie eben bei OOP auch ab.

Was OOP mit TIA Portal betrifft, bin ich zweigeteilter Meinung. Ja man kann sich eine Art von OOP in TIA-Portal basteln. Bei der Kapselung hört es aber auf, auch wenn man sich die Daten als "Privat" markiert, kann man dennoch von überall auf den Instanz-DB zugreifen und darin herum pfuschen.