TC3: Wann nutzt Ihr Methoden und wann "nur" den FB

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich weiß, dass Folgende könnte in einem Religionskrieg ausarten.
Ich möchte mal wissen wann Ihr Methoden nutzt, bzw. die Nutzung für sinnvoll haltet und wann den "nackten" FB. In bin jetzt niemand der unbedingt objektorientiert arbeiten muss, aber wenns hilft, warum nicht.
Ich erstelle gerade ein paar FBs die das Verhalten verschiedener Hardwarekomponenten nachbilden sollen. Einer zum Beispiel das eines Ventils. Bei der Instanziierung lege ich über FB_INIT den Typ (z.B. Monostabil ohne Rückmeldung) fest.
Die Funktionalität (öffnen, schließen, usw.) kann man ja jetzt alles in den FB direkt packen oder man erstellt für jede Funktionalität eine Methode, wobei es da schon wieder schwierig wird mit dem einen Rückgabewert, dann müsste man für jede Methode eine Struktur anlegen mit den möglichen Rückgabewerten oder einen für alle Methoden.
Wie würdet Ihr das machen und warum?

 

[Larry Laffer]

Hallo Oliver,
ich bin jetzt nicht der Beckhoffer - somit hätte ich erstmal die Frage an dich worin sich für dich Methoden und FB unterscheiden ...
Kann man in TwinCat innerhalb eines FB (also Klasse ?) verschiedene Methoden deklarieren ?

Ich könnte mir vorstellen, dass sich diese Frage auch für andere stellt ...

GrußLarry

 

[georg28]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir machen dass so, der FB Aufruf klassisch Case Ablauf, aber wohin in welchen Step der Case Nummern gesprungen wird, wird innerhalb von Methoden des zugehörigen FB zugewiesen. Eventuell werden in den Methoden noch Parameter beim Aufruf gesetzt, z.B. Sollposition, Geschwindigkeit etc.
Ist halt anders wie wenn man Siemens macht. Das ist schon übersichtlich und eine Art wie etwas Objektorientierung in der Automation doch gut eingesetzt werden kann. Wir haben auch bisher 1 Interface im Einsatz, aber das ist echt mehr Spielerei. Vererbung oder Abstract_FB oder andere Sachen der Objektorientierung benutzen wir nicht und denke ich, werden auch nicht benutzt werden.
Wobei sich für mich der Einsatz von Interfaces in der Codesys Welt nicht so ganz erschließt.
In der Hochsprachenwelt ein gutes Feature das man sich echt mal anschauen sollte, aber in der SPS Welt.
Online Beobachtung von Bausteinen mit Interfaces ist nicht so einfach oder ich mache da etwas falsch

 

[JSEngineering]

Hallo,

ich habe mich noch nicht mit OOP in CoDeSys beschäftigt, aber gerade Dein Beispiel mit dem Ventil würde mich einladen, das mit Methoden zu erledigen.

Denn dann kann ich vermutlich auch Methoden überladen. Ich könnte also eine Methode Open() machen und eine Methode Open(p:=50.0). Über die Vererbung würde ich möglicherweise die verschiedenen Ventiltypen abbilden: Monostabil offen/monostabil geschlossen/bistabil/variabel/ mit Dauersignal/Impulssteuerung/Analogsignal jeweils mit einem Endschalter/zwei Endschaltern/Analogsignal und den Endschaltern als NC oder NO..... da gibt es so viele schöne Varianten.

Wenn man das alles an einem FB parametriert, dann hat man einen FB mit 30 Parametern, von denen aber nur 8 effektiv genutzt werden.
Das ist bei einer Anzahl X an Ventilen entsprechend Parametrieraufwand.

Über die OOP würde sich das sicherlich deutlich vereinfachen lassen.

An sich sind ja Methoden da, um zu kapseln: Ich kann von außen nicht auf die Attribute zugreifen. Kann ich mit einem FB auch erreichen, so lange ich mir selbst diese Grenzen auferlege.
Interessant wird es dann, wenn andere damit weiter arbeiten müssen und ggf. wenn ich mit Bibliotheken arbeiten möchte, die ggf. sogar geschützt sein sollen. Dann kann ich natürlich damit den Zugriff auf Attribute verhindern, die eventuell unangenehme Folgen haben. Wo z.B. jemand versucht, an einer Überwachung vorbei etwas zu erledigen.

Also für mich würde es einen Vorteil bringen, wenn

• der Code hinterher übersichtlicher ist
• der Code wiederverwendbar sein soll und ggf. automatische Generierung dahinter steht: Parametrieraufwand
• anderen damit der Code leichter verständlich wird
• ich wichtige Dinge tatsächlich kapseln muß/will

Gruß
Jens

 

[georg28]

Bei uns sind es auch Softwareteile die immer wieder verwendet werden.
Aber Methoden Überschreiben würde ich mir schon schwer überlegen.
Irgendwann kann es sehr unübersichtlich werden.
Hier machen dann Vielleicht Interfaces wieder mehr Sinn
Siehe
https://www.sps-forum.de/codesys-un...ogrammieren.html?highlight=interfaces+Codesys

 

[StructuredTrash]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe mir eine einfache Grundregel auferlegt: Eine Methode muss ihre Aufgabe mit einem einzigen Aufruf komplett erledigen. Alles, was mehrere Zyklen braucht oder gar permanent zyklisch aufgerufen wird, kommt in den FB. Methoden also nur für ereignisgesteuerte Dinge wie z. B. die Stellbefehlsübergabe an einen Antrieb bei einer Schrittketten-Transition.

 

[oliver.tonn]

Hallo Larry,

ich bin jetzt nicht der Beckhoffer - somit hätte ich erstmal die Frage an dich worin sich für dich Methoden und FB unterscheiden ...
Kann man in TwinCat innerhalb eines FB (also Klasse ?) verschiedene Methoden deklarieren ?

Es ist tatsächlich so wie Du vermutest. Ein FB kann verschiedene andere Dinge enthalten, unter anderem Methoden. Aber auch Aktionen, dies sind vereinfacht ausgedrückt Methoden ohne eigene Variablen und Properties mit denen Werte gesetzt (Setter) und gelesen (getter) werden können. Man kann den FB aber auch ohne diese Dinge direkt nutzen.

 

[oliver.tonn]

Hallo Jens,

ich habe mich noch nicht mit OOP in CoDeSys beschäftigt, aber gerade Dein Beispiel mit dem Ventil würde mich einladen, das mit Methoden zu erledigen.

Denn dann kann ich vermutlich auch Methoden überladen. Ich könnte also eine Methode Open() machen und eine Methode Open(p:=50.0). Über die Vererbung würde ich möglicherweise die verschiedenen Ventiltypen abbilden: Monostabil offen/monostabil geschlossen/bistabil/variabel/ mit Dauersignal/Impulssteuerung/Analogsignal jeweils mit einem Endschalter/zwei Endschaltern/Analogsignal und den Endschaltern als NC oder NO..... da gibt es so viele schöne Varianten.

Einer meiner Kunden hat die Vererbung genau für Ventile genutzt, allerdings meine ich ohne Methoden. Die verschiedenen Varianten wurden dann abgeleitet und der allgemeine Teil mit SUPER^() aufgerufen.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein FB kann verschiedene andere Dinge enthalten, unter anderem Methoden. Aber auch Aktionen, dies sind vereinfacht ausgedrückt Methoden ohne eigene Variablen und Properties mit denen Werte gesetzt (Setter) und gelesen (getter) werden können. Man kann den FB aber auch ohne diese Dinge direkt nutzen.

Naja ... das kenne ich von der .Net-Programmierung her ...
Dann müßte (oder könnte ?) ja auch die Überlagerung von Methoden (wie hier schon angesprochen) funktionieren. Ich weiß zwar jetzt im Augenblick hierfür kein Beispiel im Bereich SPS - wenn man allerdings den FB selbst überlagern könnte dann würde mir da schon etwas dazu einfallen ...

 

[Larry Laffer]

Einer meiner Kunden hat die Vererbung genau für Ventile genutzt, allerdings meine ich ohne Methoden. Die verschiedenen Varianten wurden dann abgeleitet und der allgemeine Teil mit SUPER^() aufgerufen.

Vererbung oder Interfaces könnte ich mir für "Standard-Bausteine" gut vorstellen - also z.B. ein FU- oder Servo-Baustein, der "von Aussen" für einen SEW-Regler genauso aussieht wie für einen Bosch-Rexroth - und natürlich in seiner Funktions-Umsetzung auch gleich funktioniert - aslo der eine Baustein 1:1 bei geänderter Perepherie gegen den anderen austauschbar ist ...

 

[oliver.tonn]

Vererbung oder Interfaces könnte ich mir für "Standard-Bausteine" gut vorstellen - also z.B. ein FU- oder Servo-Baustein, der "von Aussen" für einen SEW-Regler genauso aussieht wie für einen Bosch-Rexroth - und natürlich in seiner Funktions-Umsetzung auch gleich funktioniert - aslo der eine Baustein 1:1 bei geänderter Perepherie gegen den anderen austauschbar ist ...

Interfaces gibt es bei TC3 auch, allerdings ist mir nicht klar wofür die verwendet werden.

 

[StructuredTrash]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vererbung oder Interfaces könnte ich mir für "Standard-Bausteine" gut vorstellen - also z.B. ein FU- oder Servo-Baustein, der "von Aussen" für einen SEW-Regler genauso aussieht wie für einen Bosch-Rexroth - und natürlich in seiner Funktions-Umsetzung auch gleich funktioniert - aslo der eine Baustein 1:1 bei geänderter Perepherie gegen den anderen austauschbar ist ...

So etwas habe ich für meine Antriebe gemacht, wobei meine Welt aus EtherCat CoE und dem CanOpen-Antriebsprofil DS402 besteht. Ich setze mittlerweile 5 verschiedene Antriebsfamilien ein, die zumindest auf dem Papier diesem Standard entsprechen, aber eben nur dort. Es gibt viele Detailunterschiede bei Verfügbarkeit oder Inhalt von I/O-Objekten. Ich habe dabei mehrere Lösungsansätze verfolgt:

Die Basisklasse enthält die Grundfunktionalität und ruft für die Detailunterschiede abstrakte Methoden auf, die von jedem konkreten Antriebs-FB überschrieben werden. Habe ich dann aber nicht gemacht, weil die Gesamtfunktionalität dadurch ziemlich "zerpflückt" wird und ein neuer Antrieb vielleicht wieder einen anderen Detailunterschied aufweist. Dann bräuchte ich nicht nur eine weitere Detailmethode in der Basisklasse, sondern müsste sie auch in allen bestehenden FBs nachrüsten.

Die Basisklasse enthält nur abstrakte Methoden. Dann müsste ich aber die komplette Funktionalität in jedem konkreten FB programmieren, obwohl sie doch weitgehend gleich ist. Als Fan der klassischen OOP mit Vererbung statt Interfaces hat mir der Gedanke auch nicht gefallen.

Schliesslich habe ich eine Basisklasse programmiert, die die komplette Funktionalität enthält, wofür ich den meist eingesetzten Antrieb zum Quasi-Standard erhoben habe. Die konkreten FBs brauchen dann "nur" ihre Funktion an diesen Standard anpassen. Im Wesentlichen tun sie das durch hin- und herüberseten zwischen ihren HW-I/Os und virtuellen I/Os der Basisklasse. Damit bleibt die Funktionalität in der Basisklasse gut lesbar, und die Anzahl der von den konkreten FBs zu überschreibenden Methoden hält sich in Grenzen.

 

[StructuredTrash]

Interfaces gibt es bei TC3 auch, allerdings ist mir nicht klar wofür die verwendet werden.

Interfaces sind für Programmierer, die zu faul sind, eine saubere Vererbungshierarchie zu entwickeln.
Im Ernst: Mann kann nicht die gesamte reale Welt durch Vererbung darstellen. Klassisches Beispiel ist die Basisklasse "Fahrzeug", von der die Klassen "Landfahrzeug" und "Wasserfahrzeug" abgeleitet werden. Was ist dann aber mit dem Amphibienfahrzeug? Das müsste vom Land- und vom Wasserfahrzeug erben. So eine Mehrfachvererbung ist sehr aufwändig, meines Wissens gibt es sie im kommerziellen Bereich nur bei C++. Die Interfaces wurden als einfache Alternative dazu eingeführt. Ein Objekt kann beliebig viele Interfaces haben, muss dann aber natürlich auch alle in den Interfaces enthaltenen Methoden implementieren. Damit kann man einem Pferd auch das Fahrrad fahren beibringen, wenn das später mal notwendig wird. Mit Vererbung wäre das schwierig, denn niemand wird auf die Idee kommen, Pferd und Fahrrad im gleichen Zweig einer Vererbungshierarchie unterzubringen.

In TC3 nutze ich Interfaces, um aus einer Hintergrundtask auf FBs in der Steuerungstask zugreifen zu können. Einem Interface ist es nämlich egal, ob der FB, auf den es zeigt, in einer anderen Task läuft. Da ein Interface den Zugriff auf den FB nur mit Methoden ermöglicht, kann man so auch den Zugriff von aussen auf die Daten beschränken, auf die zugegriffen werden darf.

 

[Larry Laffer]

Der Sinn von Interfaces (allerdings unter .Net) kann Reflektion sein. Über die Reflektion kann ich ein Interface finden ohne die Klasse dazu überhaupt zu kennen. Das habe ich untrer .Net zwar auch noch nicht so häufig gemacht - kann aber für Steuerelemente in einer Visualisierung ganz witzig sein ...

Vererbung ist dann wieder so ganz eigenes Ding. Erben kann ich ja nur von einer Klasse. Hier ist es wichtig (aus meiner Sicht), dass man nach Möglichkeit die Basisklasse so auswählt das man eben am Besten keine eingelagerten Methoden überschreiben muss sondern nur ergänzen ...
Ich hatte aber mal einen Mitarbeiter, der für Schrank die Basisklasse Stein genommen hat und das auch noch richtig gut fand - dabei gab es auch noch die Klasse Brett ...

 

[georg28]

Zuviel Werbung?
-> Hier kostenlos registrieren

So etwas habe ich für meine Antriebe gemacht, wobei meine Welt aus EtherCat CoE und dem CanOpen-Antriebsprofil DS402 besteht. Ich setze mittlerweile 5 verschiedene Antriebsfamilien ein, die zumindest auf dem Papier diesem Standard entsprechen, aber eben nur dort. Es gibt viele Detailunterschiede bei Verfügbarkeit oder Inhalt von I/O-Objekten. Ich habe dabei mehrere Lösungsansätze verfolgt:.

Dies ist inzwischen eben auch mehr meine Welt, wobei bei mir eher Array of FB ein Thema ist da viele der gleichen FB mehrmals in der gleichen Maschine verwendet werden. Noch mehr ist objektorientierte Programmierung bei mir ein Thema für Software welche für die Visualisierung der Maschinen und dann Teile davon in anderen Anwendungen eingesetzt werden kann. z. B. TCP Kommunikation

 

[georg28]

Ich habe eher schon FBs gemacht die in der Siemens und Codes Welt zum Einsatz kamen. Da stellt sich dann der Einsatz dieser ganzen Features ohnehin nicht mehr die Frage, aber das ist ja hier auch nicht das Thema

 

[wollvieh]

Habt ihr mal an einer OOP Maschine im Produktionsbetrieb versucht, online Fehler zu finden? Man sieht nur Adressen und Pointer auf Speicherberiche, wenn man Inhalte sehen möchte, nur mit Breakpoint, d.h. die Maschine steht. Sehr geil. Vom Grundgedanken einer einfachen Programmiersprache entfernt man sich, aber das scheint grad trendy?

 

[georg28]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habt ihr mal an einer OOP Maschine im Produktionsbetrieb versucht, online Fehler zu finden? Man sieht nur Adressen und Pointer auf Speicherberiche, wenn man Inhalte sehen möchte, nur mit Breakpoint, d.h. die Maschine steht. Sehr geil. Vom Grundgedanken einer einfachen Programmiersprache entfernt man sich, aber das scheint grad trendy?

Genau und dann bei Beckhoff eine Safety Sps mitdabei, die geht dann weil das normale Programm nicht mehr läuft in Störung :TOOL:


Daher leichte objektorientierte Programmierung in der Sps ja, aber nicht zuviel

 

[StructuredTrash]

Habt ihr mal an einer OOP Maschine im Produktionsbetrieb versucht, online Fehler zu finden? Man sieht nur Adressen und Pointer auf Speicherberiche, wenn man Inhalte sehen möchte, nur mit Breakpoint, d.h. die Maschine steht. Sehr geil. Vom Grundgedanken einer einfachen Programmiersprache entfernt man sich, aber das scheint grad trendy?

Wenn man den OOP-Missionaren von Codesys und Beckhoff glaubt, ist das die Zukunft. Diese Herrschaften kommen vermutlich frisch von der Uni und haben noch nie eine IBN gemacht. Trotzdem halte ich die OOP-Erweiterungen durchaus für sinnvoll. Man muss sie halt mit Augenmass nutzen, und wenn man merkt, dass man es übertrieben hat, auch mal einen Schritt zurück gehen.

 

[georg28]

Die Thematik hier erinnert mich sehr an Diskussionen in anderen Foren c vs. C++ da gibt es in der Embedded Welt haufenweise Grabenkämpfe. Aber da gibt es dann viele andere Dinge zu beachten die man als Sps Programmierer nicht kennt weil die Hersteller der Sps das machen. Aber mit Beckhoff könnte man selbst mit C++ ohne weiteres das Sps Programm machen. Hier ist Beckhoff echt sehr offen. Viele Möglichkeiten um an sein Ziel zu kommen. Aber einfacher wir es halt auch nicht unbedingt. Da ist seitens Siemens öfters der Richtige Weg vorgegeben Beckhoff ist seit neuestem sogar in der Linux Welt mit der CX Baureihe unterwegs. Dies soll noch auf die Leistungsstarken PCs übertragen werden.