[TwinCat3] Frage zu objektorientiertem Programmieren

drfunfrock

Level-1
Beiträge
934
Reaktionspunkte
72
Zuviel Werbung?
-> Hier kostenlos registrieren
So nach 2 Tagen wälzen von INFOSYS, sind noch Fragen übriggeblieben:

Ich hab ein Interface für einen Antrieb definiert und dazu einen FB1 der alles vom Interface implementiert. Dann habe ich einen FB2, der alles von FB1 erbt.

Das Vererben bräuchte ich mit dem Interface-Konzept doch eigentlich nicht, wenn ich jeweils das Interface implementiere? Denn

ADR(FB1)^.MoveTo(1)

wird genauso ausgeführt wie

ADR(FB2)^.MoveTo(1)

???

Vererben ist schöner, aber ich frag, wegen um Missverständnisse zu vermeiden.

Der Hintergrund ist der, das ich für eine Anlage verschiedene Antriebe verwenden will, aber diese nicht per Kompilieren fest verdrahten will. Dh. dachte ich mir, nur den Pointer auf einen Antriebs-FB zu übergeben.

Wenn dann alle Antriebs-FB nur das Interface implementieren, aber aber keine gemeinsame Oberklasse haben, welchen Typ muss dann der Pointer haben? Der muss dann ein POINTER TO I_AntriebInterface sein?
 
Zuletzt bearbeitet:
Die Instanz eines Interfaces ist bereits ein Pointer. Dies ist ein häufiges Missverständniss und in die IEC 61131-3 3rd Edition meines Erachtens schlecht umgesetzt:

Du definierst das Interface (I_A) inklusive der Methoden. Dann definierst du einen Funktionblock (FB_A), welcher dieses Interface implementiert.
Nun erzeugst du eine Instanz vom Funktionsblock (fbA) und kannst diese einem Interface-Pointer zuweisen:

Code:
VAR
    fbA : FB_A;
    ipA : I_A;
END_VAR

ipA := fbA; // Eigentlich ipA := ADR(fbA);

ipA.MoveTo(x); // Eigentlich ipA^.MoveTo(x);

Nun könntest du einen zweiten Funktionsblock (FB_A2) erzeugen, welcher auch das Interface implementiert.
Wenn du einen der beiden Bausteine an einen anderen Funktionsblock übergeben möchtest, verwende einfach den Interface-Pointer als VAR_INPUT.

Code:
FUNCTION_BLOCK FB_Use
VAR_INPUT
    ipA : I_A;
END_VAR

ipA.MoveTo(x);
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke!

Nachdem ich dann noch ein bisschen gespielt habe, stellte ich dann fest, dass es nur eine Oberklasse geben kann, weil auf die Variablen immer mit

SUPER^.<var>

zugegriffen werden muss. Dh. klassisches OOP funktioniert nicht so einfach. In jedem Fall erfordert es eine genaue Planung, wie das Interface aussehen soll, sonst fliegt einem alles um die Ohren, weil jede Änderung im Interface auch massive Änderungen in den Klassen nach sich zieht. Ich bin mir im Augenblick nicht wirklich sicher, ob OOP hier wirklich einen Vorteil bringt. Mit OOP würde ich daran arbeiten Antriebe als FB mit Methoden zu formulieren, die alles abdecken, so dass ich eine Bibliothek für die Wiederverwendung hätte. Es kann aber nur eine Oberklasse geben, die dann genau ausgearbeitet werden muss und die Gefahr, dass man hier an allen möglichen Enden flicken muss, ist nicht klein.
 
Zurück
Oben