roboticBeet
Level-2
- Beiträge
- 543
- Reaktionspunkte
- 240
-> Hier kostenlos registrieren
Würde mich auch interessieren, wie du das Pattern verwendest.
OOP - Debugging- / Inbetriebnahmestrategie
- Ersteller Biiebs
- Erstellt am
-> Hier kostenlos registrieren
Ich kann deine Beispiele nicht Nachvollziehen...
Also ich habe schon vor 15 Jahren in Javascript OOP programmiert (mit vererben...)
Die können doch auch vererbt und polymorph verwendet werden. Was soll daran nicht OOP sein?
Ok. Reines Linq wäre nicht OOP. Aber damit kann ich ja nicht ein komplettes (abgeschlossenes) Programm machen. Ist in C# halt ein "Werkzeugkasten".
Javascript war doch schon immer Objektorientiert. Oder?
Also ich habe schon vor 15 Jahren in Javascript OOP programmiert (mit vererben...)
-> Hier kostenlos registrieren
Records sind halt keine klassische Klasse die Datenhaltung und Manipulationen dieser in der Klasse zusammenfassen.
Die können auch vererbt Werden sind halt readonly wenn Werte zugewiesen wurde. In Javascript ist alles ein Datenobjekt solange es keinen numerische Werte oder String zugewiesen bekommen hat. Aber klassische Klassen ala Java oder C# ist erst seit einiger Zeit möglich. Wo exakt OOP anfängt kann man unendlich Diskutieren. In der SPS stellt ein FB ja auch schon soetwas wie ein Objekt dar
Das stimmt. Wobei ich mal behaupte wenn von OOP gesprochen wird, normalerweise Vererbung und Polymorphie gemeint wird.
Ansonsten wäre jede SPS mit FBs OOP.
Genau.
Das sind im Prinzip auch Klassen, die instanziert werden.
Man kann halt (zumindest bei Siemens) nicht vererben, und der Zugriff von außen und innen kann nicht angepasst werden.
Der objektorientierte Grundgedanke kann aber auch in der SPS (ohne OOP) umgesetzt werden.
Man kann z.b. anstatt Vererbung, Komposition verwenden. (Basis FB in Spezial FB Aufrufen, anstatt zu vererben).
Ich denke viele hier programmieren auch nach dem objektorientierte Grundgedanke, es ist ihnen nur nicht bewusst.
Noch eine Anmerkung zur Komposition:
Es stellt sich jetzt natürlich die Frage, für was benötige man dann Vererbung, wenn man das gleiche auch mit Komposition erreichen kann.
Das stimmt so nicht. Vererbung ist viel flexibler.
Bei der Vererbung habe ich den Vorteil, das ich einen bestimmten Teil (Methode, Eigenschaft) "überschreiben" kann.
Das kann ich bei einer Komposition nicht. Dort müsste ich dann irgendwie, drumherum programmieren.
Es stellt sich jetzt natürlich die Frage, für was benötige man dann Vererbung, wenn man das gleiche auch mit Komposition erreichen kann.
Das stimmt so nicht. Vererbung ist viel flexibler.
Bei der Vererbung habe ich den Vorteil, das ich einen bestimmten Teil (Methode, Eigenschaft) "überschreiben" kann.
Das kann ich bei einer Komposition nicht. Dort müsste ich dann irgendwie, drumherum programmieren.
- Beiträge
- 15.297
- Reaktionspunkte
- 3.690
-> Hier kostenlos registrieren
Dazu mal eine Anmerkung von mir :
Bei Vererbung kann man natürlich auch mal eine Methode oder Eigenschaft überschreiben - das sollte aber nicht die Regel sein. Der Sinn einer Vererbung (für mich) ist, dass man die Basisklasse um zusätzliche Funktionen etc. erweitert. Also nicht als Basis "Stein" nehmen um dann "Brett" daraus zu machen ...
Bei Vererbung kann man natürlich auch mal eine Methode oder Eigenschaft überschreiben - das sollte aber nicht die Regel sein. Der Sinn einer Vererbung (für mich) ist, dass man die Basisklasse um zusätzliche Funktionen etc. erweitert. Also nicht als Basis "Stein" nehmen um dann "Brett" daraus zu machen ...
Mrtain
Level-3
- Beiträge
- 1.449
- Reaktionspunkte
- 871
Wobei mir die Kapselung von Daten deutlich wichtiger wäre als die Vererbung / Polymorphie - zumindest in der SPS - Welt
Da hast du absolut recht.
Ich finde das kann man nicht verallgemeinern.
Vor allem bei Verwendung von abstracten Klassen, müssen die Sachen ja "überschrieben" werden. Da ist es die Regel.
-> Hier kostenlos registrieren
Ob OOP der große Wurf ist Frage ich mich inzwischen generell. Im SPS Bereich in wenigen Fällen für GUi Programmierung super und Datenobjekte darzustellen aber sonst
Staubsauger
Level-2
- Beiträge
- 85
- Reaktionspunkte
- 21
Als hauptsächlicher Nutzer von Siemens Steuerungen wäre das ja schon ein riesiger Fortschritt.
Ich durfte vor kurzem mal ein kleines Projekt in Codesys realisieren. Da gab es ein zwei Sachen, die ich wesentlich besser fand.
-> Keine Instanz-DBs
-> Private Methoden eines FBs.
-> Man kann die Instanzdaten auf privat setzen
Würde die Programme wesentlich übersichtlicher machen, da nicht überall n Haufen iDBs und FCs/FBs rumliegen, die eigentlich ausschließlich in einem FB genutzt werden.
MFreiberger
Level-3
- Beiträge
- 3.377
- Reaktionspunkte
- 980
Kann ich zwar ein bisschen verstehen, aber es liegt ja auch in der Hand des Programmierers für Übersicht zu sorgen.
Immerhin kann man ja Ordnerstrukturen aufbauen und z.B. die iDBs und FCs/FBs in einen Unterordner packen, so, dass sie nicht "überall als Haufen rumliegen".
Staubsauger
Level-2
- Beiträge
- 85
- Reaktionspunkte
- 21
-> Hier kostenlos registrieren
Geb ich dir recht. Ein guter Handwerker bringt auch auch mit schlechtem Werkzeug gute Ergebnisse.
Man muss es ja aber nicht schwerer machen als nötig.
Das sind nur ein paar Sachen wo Codesystem kann enums sind ebenfalls eine feine Sache. Codesys ist von den Features schon mächtiger als Siemens. Nur bleibt Siemens halt mehr gefragt
Staubsauger
Level-2
- Beiträge
- 85
- Reaktionspunkte
- 21
Die gibt es bei Siemens zwischenzeitlich auch. Man bleibt sich seinem Motto allerdings treu und mach es etwas anders als die andern.
ENUMS nennen sich "Named Datatypes" und sind nur in Softwareunits verfügbar
-> Hier kostenlos registrieren
Wieder eine dieser Siemens Krücken
- Beiträge
- 3.741
- Reaktionspunkte
- 1.071
Du kannst doch in einem FB weitere FBs im statischen Bereich instanzieren.. so mache ich das immer
Ich glaube ich komme langsam hinter das OOP-Konzept. Bitte korrigiert mich wenn ich falsch liege.
Beispiel:
Ich habe eine Maschine mit einer Sicherheitszelle, diese Sicherheitszelle hat mehrere Stationen (z.B. Einfördern, Bearbeitung, Ausfördern)
Im Prozedur-Konzept tendiert man dazu alles zu verschachteln:
Im OOP-Konzept ist alles mehr auf einer Ebene:
Vorteile:
Habe ich das so richtig verstanden? Beim OOP wird man mehr oder weniger dazu "gezwungen" weil man Instanzen von Interfaces nicht verschachteln kann. Auch Siemens limitiert das mit der begrenzten Verschachtelungstiefe.
Aber auch hier: Das Konzept kann man natürlich auch ohne OOP programmieren.
Beispiel:
Ich habe eine Maschine mit einer Sicherheitszelle, diese Sicherheitszelle hat mehrere Stationen (z.B. Einfördern, Bearbeitung, Ausfördern)
Im Prozedur-Konzept tendiert man dazu alles zu verschachteln:
C-ähnlich:
FUNCTION_BLOCK FB_Station
fbAktor1(i_bTuWas := astAktoren[1].bLosJetzt, o_bFertig => astAktoren[1].bFertig);
fbAktor2(i_bTuWas := astAktoren[2].bLosJetzt, o_bFertig => astAktoren[2].bFertig);
fbAblaufSchrittkette(...);
...
FUNCTION_BLOCK FB_Zelle
fbStation1(io_astAktoren := astAktorenStation1);
fbStation2(io_astAktoren := astAktorenStation2);
...Im OOP-Konzept ist alles mehr auf einer Ebene:
C-ähnlich:
FUNCTION_BLOCK FB_Schrittkette IMPLEMENTS I_Schrittkette
VAR_INPUT
i_iAktor1 : I_AktorBefehle+Status;
i_iAktor2 : I_AktorBefehle+Status;
...
END_VAR
-------------------------------------------------------------------
FUNCTION_BLOCK FB_Station IMPLEMENTS I_Station1Handshake, I_Station1
VAR_INPUT
i_iAktor1 : I_AktorFreigabe;
i_iAktor2 : I_AktorFreigabe;
...
i_iStation2 : I_Station2Handshake;
END_VAR
-------------------------------------------------------------------
FUNCTION_BLOCK FB_Zelle
iAktor1Befehle := iAktorFreigabe := fbAktor1();
iAktor1Befehle := iAktorFreigabe := fbAktor2();
iStation1 := fbStation1(i_iAktor1 := iAktor1Befehle, ...);
iStation2 := fbStation2(i_iAktor1 := iAktorXYBefehle, ...);
iSchrittkette1 := fbSchrittkette(i_iAktor1 := iAktorFreigabe, ..., iStation1 );Vorteile:
- Kapselung: Jeder FB erhält nur die Funktionen die er auch wirklich braucht
- Ultra flexibel: Wenn man für ein genormtes Interfaces z.B. von einer Basis-Klasse für alle Aktoren-Typen nimmt, ist Schrittketten FB egal welcher Aktor tatsächlich an der Schrittkette beschaltet ist. Am Ende muss nur der Befehl zum Aktor passen.
- Die Wartbarkeit/Erweiterbarkeit des Codes erhöht sich
- Der FB_Zelle wird ziemlich lang
Habe ich das so richtig verstanden? Beim OOP wird man mehr oder weniger dazu "gezwungen" weil man Instanzen von Interfaces nicht verschachteln kann. Auch Siemens limitiert das mit der begrenzten Verschachtelungstiefe.
Aber auch hier: Das Konzept kann man natürlich auch ohne OOP programmieren.
HauDraufWieNix
Level-2
- Beiträge
- 26
- Reaktionspunkte
- 7
-> Hier kostenlos registrieren
Da möchte ich noch eine andere Möglichkeit in den Raum werfen.
Ich habe bei mehreren Kunden Umsetzungen gemacht die nur durch die Objektorientierung möglich
war und es ermöglicht das die Programme für die Kundenmaschinen aus einer Bibliothek heraus
generiert werden können. Ist ein etwas spezieller Ansatz aber sehr flexibel.
Einfach erklärt geht es darum das die Maschinen sehr modular aufgebaut sind. Kunden können
sich aus einer Liste an Funktionalität ihre Konfiguration zusammenstellen. Danach wird die
Elektroplanung gemacht.
Aus Schaltplan und Funktionen wird dann ein XML erstellt das die Maschine definiert. Ein kleines
Kommandozeilentool generiert daraus dann die Applikation die anschließend auf die CPU geladen
werden kann.
Einfach beschrieben (da steckt natürlich mehr dahinter):
Es gibt eine Basisklasse Modul mit den Methoden Command, Cycle und State die jeweils von
den konkreten Klassen überschrieben werden.
Über Command können definierte Kommandos an das jeweilige Modul gesendet werden. Was
das Modul damit macht definiert die Implementierung in der abgeleiteten Klasse
Cycle wird vom System automatisch aufgerufen. Wenn ein Modul zyklisch etwas arbeiten will
kann es die Methode überschreiben. Wir haben aber auch einige Funktionen bei denen ein
Kommando ausreicht.
Im Ablauf (Cycle) des eigentlichen Maschinenprogramms wird dann zum jeweiligen Zeitpunkt ein
Befehl an das jeweilige Modul gesendet.
z.b.
SendCommand( Regler1, EINSCHALTEN ) oder
SendCommand( Klemmung, GRUNDSTELLUNG )
usw.
State kann von anderen Module aufgerufen werden um den Status zu erfragen.
if GetState(Klemmung) = GRUNDSTELLUNG then
....
Diese Vorgehensweise wird sicher nicht für alle gleich gut funktionieren. In dem Fall ist es aber
eine sehr feine Lösung die wiederverwendbaren, lesbaren und erweiterbaren Code erzeugt.
Außerdem sind die Funktionen komplett unabhängig testbar.
Dabei haben wir ganz bewusst auf die Verwendung von Interfaces und Properties verzichtet um
das Debugging einfacher zu gestalten und die Komplexität zu verringern. Bei einem Interface
müsste der Anwender alle Methoden implementieren. In der obigen Variante muss der Anwender
nur die Methoden verwenden die er benötigt, der Rest wird durch die Basisklasse abgedeckt.
Ich habe bei mehreren Kunden Umsetzungen gemacht die nur durch die Objektorientierung möglich
war und es ermöglicht das die Programme für die Kundenmaschinen aus einer Bibliothek heraus
generiert werden können. Ist ein etwas spezieller Ansatz aber sehr flexibel.
Einfach erklärt geht es darum das die Maschinen sehr modular aufgebaut sind. Kunden können
sich aus einer Liste an Funktionalität ihre Konfiguration zusammenstellen. Danach wird die
Elektroplanung gemacht.
Aus Schaltplan und Funktionen wird dann ein XML erstellt das die Maschine definiert. Ein kleines
Kommandozeilentool generiert daraus dann die Applikation die anschließend auf die CPU geladen
werden kann.
Einfach beschrieben (da steckt natürlich mehr dahinter):
Es gibt eine Basisklasse Modul mit den Methoden Command, Cycle und State die jeweils von
den konkreten Klassen überschrieben werden.
Über Command können definierte Kommandos an das jeweilige Modul gesendet werden. Was
das Modul damit macht definiert die Implementierung in der abgeleiteten Klasse
Cycle wird vom System automatisch aufgerufen. Wenn ein Modul zyklisch etwas arbeiten will
kann es die Methode überschreiben. Wir haben aber auch einige Funktionen bei denen ein
Kommando ausreicht.
Im Ablauf (Cycle) des eigentlichen Maschinenprogramms wird dann zum jeweiligen Zeitpunkt ein
Befehl an das jeweilige Modul gesendet.
z.b.
SendCommand( Regler1, EINSCHALTEN ) oder
SendCommand( Klemmung, GRUNDSTELLUNG )
usw.
State kann von anderen Module aufgerufen werden um den Status zu erfragen.
if GetState(Klemmung) = GRUNDSTELLUNG then
....
Diese Vorgehensweise wird sicher nicht für alle gleich gut funktionieren. In dem Fall ist es aber
eine sehr feine Lösung die wiederverwendbaren, lesbaren und erweiterbaren Code erzeugt.
Außerdem sind die Funktionen komplett unabhängig testbar.
Dabei haben wir ganz bewusst auf die Verwendung von Interfaces und Properties verzichtet um
das Debugging einfacher zu gestalten und die Komplexität zu verringern. Bei einem Interface
müsste der Anwender alle Methoden implementieren. In der obigen Variante muss der Anwender
nur die Methoden verwenden die er benötigt, der Rest wird durch die Basisklasse abgedeckt.
IBFS
Level-3
- Beiträge
- 4.276
- Reaktionspunkte
- 1.015
BOSCH Nexeed zusammen mit TwinCat V3.X ist 100% PURES OOP, so wie man sich das besser kaum wünschen kann!
Seit 2018 nutze ich permanent Nexeed und kann damit sehr komplexe Programme machen die gut zu pflegen sind.
Das liegt aber auch daran, weil der Nexeed Projekt Rahmen mit all den Objekten sehr clever aufgebaut ist.
