# OOP in Twincat3, Hilfe bei Programmstruktur/Vererbungshierarchie



## HansPeter789 (6 Juni 2019)

Servus, 

ich habe mir in meinem jetzigen Projekt die OOP Option von Twincat3 zu Nutzen gemacht und mein Programm nach einer klassischen Vererbungshierarchie aufgebaut.

  Einzelne Motoren mit dazugehörigen Sensoren erweitern die Basisklasse Motor, je nachdem ob und welche Sensoren der Motor hat. Mehrere dieser Funktionsblöcke werden in einen Programm initialisiert und gemeinsam gesteuert.
  Nun zu meinem Problem, es gibt einen spielverkehrten Aufbau dieses Roboters der im Prinzip gleich angesteuert wird jedoch leicht andere Parameter (wie Masse und co.) hat, welche ich einfach als solche von Oben bis nach Unten zum Motor in der Vererbung weitergereicht werden. Aber durch den inversen Aufbau müssen auch teils Methoden abgeändert werden obwohl das meiste gleich bleiben sollte.
  Wie würdet Ihr das angehen? Ich bin noch relativ neu bei programmieren und hatte noch kaum Erfahrung mit SPS.


----------



## HansPeter789 (6 Juni 2019)

meine dereitige Lösung ist, dass ich eine Boolean Varibale als Input durchreiche und in der Methode eine IF-Abfrage prüft, ob es sich um den linken oder rechten Roboter handelt. Aber vlt gibt es ja eine elegantere Lösung. Mir ist zudem aufgefallen, dass die Vererbungsmethode einem es schnell komplieziert macht, wenn doch nicht alle Teile die man in einer Klasse zusammengefasst hat identisch sind (wie anfangs angenommen, bzw. weil neue Anforerungen an das Programm gestelt wurden). Gibts es evtl. bessere Ansätze als diesen?


----------



## StructuredTrash (10 Juni 2019)

Du wirst wohl noch konkretere Informationen zu Deinem Projekt geben müssen, um hier Antworten zu erhalten. Wie sieht die Vererbungshierarchie im Detail aus, wie werden die Antriebs-FBs zu einem Roboter zusammengefasst und wo liegen die Unterschiede zwischen linkem und rechtem Roboter?
Allgemein kann man nur Folgendes sagen: Wenn die einzelnen Methoden Deiner Antriebs-FBs wissen müssen, ob sie in einem linken oder rechten Roboter arbeiten, hast Du vielleicht zuviel Funktionalität dort hineingepackt.


----------



## HansPeter789 (11 Juni 2019)

Ein Gelenk = Motor + Sensor. Gelenek 1-3 haben ein anderes Setup (SDOs) und wurden daher einzeln zusammengefasst. Jedes Gelenk hat seinen eigenen Regler, der mittels vorgegebenen werten und den Sensormessdaten eine Regelgröße ausgibt. Regler für rechts und links sind mathematisch identisch jedoch muss die Regelgröße bei machen, nicht allen, Geleneken invertiert bzw. sensordaten modifiziert werden.
Alle Gelenke wurden in "Arm" zusammengefasst und dort wird der Ablauf von Initialisierung der Gelenke bis zur Regelung durchgeführt. Das Interface Array ermöglich Aufrufe einzelner Methoden und Eigenschaften in einer for Schleife.


So sieht der ganze Spaß als UML aus. ARM gibt hautsächlich die gemessenen Winkel und vor Beginn eingebene Konstanten an die Gelenke weiter und diese dann die Regelgröße zuruck (bzw. davor auch die Sensorlage). Generell ist rechts und links spiegelverkehrt aufbaut und zumit dergehen sich einige, nicht alle Motoren anders herum und die sensoren sind auch teils invertiert. ist aber von gelenk zu gelenk unterschiedlich.


----------



## StructuredTrash (11 Juni 2019)

Wie wäre es, die Möglichkeit einer Invertierung von Soll-und/oder Istwertsystem von vornherein im Gelenk-FB vorzusehen und nur einmalig bei der Initialisierung auszuwählen, z. B. als Multiplikator +1.0 oder -1.0? Dann wäre es unabhängig von links/rechts und Du kannst Dir den entsprechenden BOOL-Input bei den Methoden sparen.


----------



## HansPeter789 (12 Juni 2019)

Hmm ja da habe ich mich wohl missverständlich ausgedruckt . Also natürlich wird die Regelgröße mit einem Faktor für jeden Motor einzeln übergeben und mittels eines negativen Werts der Strom invertiert.
Nunja aber das Problem liegt eher in den Sensoren, bei den die Daten rechts und links teils invertiert werden jedoch beide Seiten noch einen gleichen Offset erhalten. Solche Anforderungen an die Sensordaten wurden nach und nach gestellt. Jedesmal einen Faktor vom untersten FB bis in den oberste FB durchzuschleifen war immer mit sehr viel Aufwand verbunden und zudem hatte dann die Klasse zig Parameter die im MAIN Programm an die Klasse Arm übergeben werden mussten.
Eine Funktionserweiterung war so leider nicht so einfach möglich wie anfangs angedacht, gerade wenn man nur mal kurz eine neue Funktion testen möchte. Also mathematisch ist hier eher nicht das Problem.
Ich weis nicht ob die Struktur meines Programms verständlich rüber kam, aber meine Frage dazu ist eher ob die Objektorientierung schon der "richtige" (gängige) Weg ist oder ob das eher keine übliche Pragrammstruktur im SPS-Bereich ist, gerade bei Prototypen. Ich weis, dass bei TwinCAT2 der Ansatz der Objetkorientierung noch nicht möglich war.


----------



## StructuredTrash (12 Juni 2019)

Ob Objektorientierung der richtige Weg ist, hängt sicher von der Anwendung ab. Ich selbst arbeite im Maschinenbau und halte die OOP dort schon für den richtigen Weg. Eine Produktionslinie hat mehrere Maschinen, jede Maschine wiederum mehrere Baugruppen. Alle diese Einheiten erledigen ihre Aufgabe weitgehend selbständig und erfordern nur geringen Datenaustausch mit den höheren/niedrigeren Ebenen oder Nachbareinheiten. Das sind Objekte, wie sie im Buche stehen. Wie weit man dabei die in CodeSys/TwinCat 3 hinzugekommenen OOP-Techniken nutzt, muss jeder selbst entscheiden. Diese Techniken wurden weitgehend unverändert aus der Hochsprachenwelt übernommen und eignen sich vor allem für ereignisgesteuerte Vorgänge. Jede Maschine hat aber auch zyklisch zu bearbeitende Funktionalität, und dafür ist der IEC-FB mit seiner statischen VAR_INPUT/VAR_OUTPUT-Schnittstelle wesentlich besser geeignet als Methoden mit ihrer temporären Datenübergabe. Es wäre deshalb in meinen Augen dumm, die traditionelle SPS-Programmierweise komplett durch OOP-Hochsprachenstil ersetzen zu wollen.


----------

