OOP in IEC61131-3

[Neals]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hey Leute,

habe hier im Forum noch nichts von ObjektOrientierterProgrammierung gelesen.

Mit CoDeSys 3 ist es ja nun möglich und mit TwinCAT 3 soll es auch möglich sein.

Ist die OOP-Erweiterung bereits genormt? Also eine Erweiterung der IEC61131-3? Habe mal was von der 61499 gelesen, weiß aber nicht, ob das die richtige Norm ist.

Ich programmiere viel in Hochsprachen und auch Steuerungsapplikationen in ST. Daher finde ich die neuen Möglichkeiten sehr gut, da sie vieles für mich vereinfachen und ich denke auch, dass allgemein die Software-Qualität dadurch verbessert wird.

Hat jemand von euch bereits Erfahrungen mit den neuen Möglichkeiten gemacht und kann sagen, wie Sinnvoll die umgesetzt wurden?
Wie findet ihr die neuen Möglichkeiten zum Programmieren?
Werdet ihr in Zukunft OOP Programmieren oder bei der sequentiellen Programmierung bleiben?

 

[Werner29]

Hallo Neals,

ich bin von 3S und gleichzeitig bin ich auch in der aktuellen Arbeitsgruppe für die zukünftige Version 3 der IEC 61131-3.
Daher kann ich dir hier voll die Insider Information geben:
1. Diese Änderungen sind (noch) nicht normiert! Es wird aktuell an einer neuen Version der 61131-3 gearbeitet und der aktuelle Entwurf sieht unserer Lösung ziemlich ähnlich. Klar ist jedenfalls: die nächste Version wird OO-Features haben, da sind sich alle Beteiligten einig. Und so richtig anders wie CoDeSys kann das nicht werden. Mit etwas Glück wird das 2010 fertig, das werde ich hier im Forum dann bekanntgeben. Aber das wird auch so nich
2. 61499 ist was ganz anderes. Aber was genau, das habe ich selber noch nicht verstanden.
3. Die Objektorientierte Programmierung spricht vor allem Leute wie Dich an, die Erfahrung mit Hochsprachen haben. Die werden sich schnell heimisch fühlen. Wer auch stark OO-Features nutzt, sind die Steuerungshersteller, die Bibliotheken entwickeln.
Also man kann sagen, dass sich die CoDeSys V3 Nutzer in zwei Klassen aufteilen:
- die die OO-Features exzessiv nutzen (und denen geht alles immer noch nicht weit genug)
- die die OO-Features überhaupt nicht nutzen

Bernhard

 

[RobiHerb]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gibt es mehr füt die Fan Gemeinde?

Ich finde, das sehr interessant aber wo kann man mehr erfahren?

Ich habe über googeln nur das aus Russland gefunden:

www.prolog-plc.ru/3s/uc_07/ucru07_oop.pdf

Habe ja erstmal eine KGB Seite vermutet.

 

[Ralle]

Ehrlich gesagt, weiß ich noch nicht so recht, was ich davon halten soll, muß mir halt auch mal die Zeit nehmen und das genauer ansehen. Aber was ich bisher generell von Informatikern zum Thema Steuerungen gesehen habe, war eher nicht so prickelnd, weil oft der technische Hintergrund von Maschinen, also das Verständnis der mechanischen Gegebenheiten und Limitierungen, bzw. der notwendigen techn. Umsetzung fehlte. Programmtechnisch ist das auch so eine Frage, denn OOP wird ja nicht selten eher Schlecht als Recht umgesetzt. Keine Ahnung, wie genau dann eine hohe Funktionssicherheit gewährleistet wird und wer später noch den Durchblick behält. Daher vermute ich mal, vorläufig wird die Mehrheit weiterhin im "alten" Stil Programmieren, solange sich nicht wirklich einen Notwendigkeit abzeichnet. Sicherlich ist es auch sehr Branchenabhängig, ob ein Umstieg sinnvoll ist.

 

[drfunfrock]

OOP ist für alle gut, wenn es den Betrieb einer SPS nicht stört und das wird es nicht. Mir fallen auf Anhieb diverse Lösungen ein, die damit übersichtlicher zu realiseren werden (ich beziehe mich auf ST).

Immer dann wenn gleiche Einheiten wie Pumpen, Regler, Nachrichten etc. vorkommen, ist OOP praktisch. Ein Beispiel, wäre eine Montrac-Einschienenbahn, wenn das was auf dem Wagen liegt verschiedene Zustände haben kann (Produktart, Teststatus etc) um dann verschiedene Prozesse dafür zu starten, je nach Status. Aber auch ein Drehtisch mit n Prozessen könnte ein Beispiel sein, wenn das Starten der Prozesse und die Übernahme von Statusmeldungen auf diese Weise einfach vereinheitlicht werden kann. Man muss zu allem dem nicht OOP benutzen. Ich finde es aber grundsätzlich übersichtlicher. Allerdings ein FB tut es in vielen Fällen auch.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

@drfunfrock

Ein Beispiel wäre da nicht schlecht, was genau ist denn bei OOP anders, als wenn ein FB eingesetzt wird?

 

[gravieren]

Hi


Schau dir doch mal die 3S-Homepage an.

http://www.3s-software.com/index.shtml?de_OOP

 

[drfunfrock]

Das Beispiel von 3S ist doch wunderschön. Ein und derselbe Name für eine Methode, trotz da es verschiedene Antriebe sind. Selbiges kann man für Ventile, Messgeräte etc machen.

(* antrieb vererbt eigenschaften an Stepper und Servo *)
(* Das Vererben sollte mit Interfaces nicht unbedingt notwendig sein. *)
obj1 : Stepper;
obj2 : Servo;
objarr : ARRAY[1..2] OF antrieb := [obj1,obj2];

BEGIN
    FOR i:=1 TO 2 DO
        objarr[i].Home();
    END_FOR;
END;

Das lässt sich auf alle Teile mit ähnlichen Funktionseigenschaften übertragen. Ob Prozesse, Maschinen, Wagen einer Transportbahn. Das ist denn auch das Ende von Funktionen, die global instanzierte FBs aufrufen oder eine Funktionssammlung die Antriebe steuern. Damit lässt sich dann immer so etwas wie antrieb.fahrzu(x,y) schreiben, anstatt ServoAntrieb_Fahrzu(x,y) und StepperMotor_Fahrzu(x,y). Es entfällt so manche SwitchCase konstruktion.

 

[!name!]

Zuviel Werbung?
-> Hier kostenlos registrieren

schaut mal unter http://stefanhenneken.wordpress.com. Dort findet ihr einige Beispiele und Erklärungen zu OOP mit CoDeSys V3.

 

[Ralle]

schaut mal unter http://stefanhenneken.wordpress.com. Dort findet ihr einige Beispiele und Erklärungen zu OOP mit CoDeSys V3.

Ja ja, das ist alles ganz nett, aber leider noch einige Jahre von der Verwendung entfernt (oder soll ich sagen Gott sei Dank???) Der alltäglich Kampf mit SPS, Hardware Software und Programmierern, die nicht so genau wissen, was sie da eigentlich tun und die Tatsache, daß auch die Instandhalter einer Firma in der Lage sein sollten einfache Fehler zu suchen oder Änderungen im Ablauf vorzunehmen, hat mich etwas "Neuerungsfeindlich" werden lassen. Vielleicht werde/bin ich auch einfach nur zu alt, um jede neue Idee von entwicklungs- /verkaufswütigen Kollegen zu bejubeln. Fakt ist, wenn ich heute ein Delphi- oder C#-Programm schreibe, weiß ich um die echten Interna kaum noch Bescheid. Wenn dann genau da etwas klemmt, ist man so ziemlich aufgeschmissen und das will ich in einer Industriesteuerung nicht haben, obwohl es sich heute schon nicht mehr vermeiden läßt, leider!

 

[Pietpinguin]

Ehrlich gesagt, weiß ich noch nicht so recht, was ich davon halten soll, muß mir halt auch mal die Zeit nehmen und das genauer ansehen. Aber was ich bisher generell von Informatikern zum Thema Steuerungen gesehen habe, war eher nicht so prickelnd, weil oft der technische Hintergrund von Maschinen, also das Verständnis der mechanischen Gegebenheiten und Limitierungen, bzw. der notwendigen techn. Umsetzung fehlte. Programmtechnisch ist das auch so eine Frage, denn OOP wird ja nicht selten eher Schlecht als Recht umgesetzt. Keine Ahnung, wie genau dann eine hohe Funktionssicherheit gewährleistet wird und wer später noch den Durchblick behält. Daher vermute ich mal, vorläufig wird die Mehrheit weiterhin im "alten" Stil Programmieren, solange sich nicht wirklich einen Notwendigkeit abzeichnet. Sicherlich ist es auch sehr Branchenabhängig, ob ein Umstieg sinnvoll ist.

Dem ist nichts mehr hinzuzufügen...*ACK*

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja ja, das ist alles ganz nett, aber leider noch einige Jahre von der Verwendung entfernt (oder soll ich sagen Gott sei Dank???) Der alltäglich Kampf mit SPS, Hardware Software und Programmierern, die nicht so genau wissen, was sie da eigentlich tun und die Tatsache, daß auch die Instandhalter einer Firma in der Lage sein sollten einfache Fehler zu suchen oder Änderungen im Ablauf vorzunehmen, hat mich etwas "Neuerungsfeindlich" werden lassen.

*ACK*Ich würde es als "kundenorientiertes Programmieren" bezeichnen.
Und das ist doch die Aufgabe von PLC Programmieren.

Vielleicht werde/bin ich auch einfach nur zu alt, um jede neue Idee von entwicklungs- /verkaufswütigen Kollegen zu bejubeln. Fakt ist, wenn ich heute ein Delphi- oder C#-Programm schreibe, weiß ich um die echten Interna kaum noch Bescheid. Wenn dann genau da etwas klemmt, ist man so ziemlich aufgeschmissen und das will ich in einer Industriesteuerung nicht haben, obwohl es sich heute schon nicht mehr vermeiden läßt, leider!

Wenn ich in C oder Delphi programmiere kam ich bisher meist ohne OOP aus.
Nahezu jedes Problem konnte ich bisher konventionell lösen.
Bei Java geht es scheinbar nicht mehr. Doch gut muss ich das nicht finden.




bike

 

[Larry Laffer]

Da bin ich nicht so ganz mit einverstanden.
Ich nehme mir hier mal 2 Ausschnitte von unterschiedlichen Beiträge von Ralle als Referenz, da die es m.E. ganz gut treffen ...

... denn OOP wird ja nicht selten eher Schlecht als Recht umgesetzt.

... Der alltäglich Kampf mit SPS, Hardware Software und Programmierern, die nicht so genau wissen, was sie da eigentlich tun und die Tatsache, daß auch die Instandhalter einer Firma in der Lage sein sollten einfache Fehler zu suchen oder Änderungen im Ablauf vorzunehmen ...

Das diese Beiträge mit ihrer (von mir herausgefilterten) Kern-Aussage so ihre Berechtigung haben kann man hier im Forum Tag für Tag nachlesen.

Objekt-orientierte Programmierung ist nicht schlecht - schlecht ist nur, was daraus gemacht wird. Da schreibt z.B. einer einen FB, der teilweise über seine Schnittstelle und teilweise über absolute Zugriffe mit Aussen kommuniziert - ja Hallo !? Das da dann keiner mehr durchblickt ist doch wohl klar.

Nach meiner Ansicht ist auch OOP in der SPS-Programmierung kein No-go - allerdings schon, was so manche daraus machen. Dabei nehme ich allerdings auch die Ersteller der Entwicklungs-Umgebung (für mich Siemens) nicht aus. Auch hier sind viele Dinge nur halbherzig ausgeführt --- und ich rechne da bei dem schönen neuen TIA-Portal auch mit keiner umwälzenden Neuerung ...

Gruß
Larry

 

[Larry Laffer]

Wenn ich in C oder Delphi programmiere kam ich bisher meist ohne OOP aus.
Nahezu jedes Problem konnte ich bisher konventionell lösen.
Bei Java geht es scheinbar nicht mehr. Doch gut muss ich das nicht finden.

Soll ich das jetzt als positiv interpretieren ?
Sorry ... das hört sich für mich nicht nach Fortschritt an ...

 

[RobiHerb]

Zuviel Werbung?
-> Hier kostenlos registrieren

Lernen und immer wieder lernen

Objekt-orientierte Programmierung ist nicht schlecht - schlecht ist nur, was daraus gemacht wird. Da schreibt z.B. einer einen FB, der teilweise über seine Schnittstelle und teilweise über absolute Zugriffe mit Aussen kommuniziert - ja Hallo !? Das da dann keiner mehr durchblickt ist doch wohl klar.

Nach meiner Ansicht ist auch OOP in der SPS-Programmierung kein No-go - allerdings schon, was so manche daraus machen. Dabei nehme ich allerdings auch die Ersteller der Entwicklungs-Umgebung (für mich Siemens) nicht aus. Auch hier sind viele Dinge nur halbherzig ausgeführt --- und ich rechne da bei dem schönen neuen TIA-Portal auch mit keiner umwälzenden Neuerung ...

Gruß
Larry

Man muss einmal das Problem etwas globaler sehen:

Die Maschinen, Anlagen Fahrzeuge werden immer komplizierter. Was man früher noch als Umsetzung einer Maschine auf Relaisbasis auf eine modernere Technik verstehen konnte ist heute oft ein Multi Prozessor System mit suptilen internen Abhängigkeiten und einigen tausend Zeilen Code.

Die Leute, die diesen Code schreiben müssen, haben aber in der Regel nur einige Wochen Schulung (wenn überhaupt) bekommen und sind mit Problemen konfrontiert, die sie nie systematisch erklärt bekommen haben.

Dass die Computer Technik hier schon Jahrzehnte bittere Erfahrung gesammelt hat, ist an der SPS sehr oft unbemerkt vorbei gegangen. Das Erstellen von professioneller Software ist bei den heutigen Anforderungen und Komplexitäten nicht mehr per autodidaktischem Hack und Try per Spagetti Code (AWL) in den Griff zu bekommen.

Das ist aber einem Chef einer Deutschen Maschinenbau Firma weder vom SPS Hersteller (will verkaufen) noch von der eigenen Mannschaft (wer sagt schon gerne, dass er überfordert ist) leicht zu vermitteln.

Diese Situation wird sich ändern müssen oder die Deutsche Industrie wird verschwinden wie die Hersteller von Dampflokomotiven. Der Kunde jedenfalls wird da kaufen, wo die Software betriebssicher läuft.

Wer da meint, die Erfahrungen des Software Engineerings ignorieren zu können, redet wie der Papst von der Sexualität.

 

[Ralle]

@RobiHerb

Hört sich ja toll an, wäre auch ganz schön. Aber wenn ich mir die Betriebssicherheit der Standardprogramme ansehe, die entwickelt werden, nachdem man nun ja immerhin schon "Jahrzehnte bittere Erfahrung gesammelt hat", dann kann ich nur feststellen, daß so etwas in einer Anlage einfach nicht geht und nicht sein darf. (mein Outlook auf dem Laptop stürzt regelmäßig mehrmals am Tag ab) Daher sollte man lieber ab und an mal verinnerlichen, daß ein gewisser Grad an Komplexität automatisch zu Fehlern führen muß (siehe Apolloprogramm und die Betrachtungen zu den Fehlern im Programmcode selbigen Programmes). Also sollten vielleicht alle Beteiligten einfach ab und zu die Kirche im Dorf lassen und lieber mit einfachen, ausreichenden, herkömmlichen Mittel einen soliden Automaten programmieren, als nach den tollen Tools zu schreien, die sie dann weder verstehen, beherrschen, geschweige denn richtig bedienen können. Ich weiß natürlich auch, daß es Fälle gibt, in welchen OOP sehr hilfreich sein könnte. Aber Automaten im Sondermaschinenbau, mit denen ich mich i.A. beschäftige, benötigen das so dringend, wie ich einen zweiten Hals! Bei anderen Anwendungen mag das vielleicht etwas anders sein, das kann ich aber nicht beurteilen.

 

[Larry Laffer]

@Ralle:
Das Grundthema beschreibt doch mehr eine Vorgehensweise ...
Im Grunde könnte ein Beitrag, den ich gerade noch in einem anderen Thread gelesen habe, der richtige Aufhänger sein. Man muß es vielleicht gar nicht an Klassen und Methoden festmachen - es würde schon "strukturiert" reichen. Es muss auch nicht von Vererbung von Eigenschaften die Rede sein - hier wäre schon Kapselung von Funktionen und Aufgaben ganz hilfreich. Wenn man das ein bißchen verfolgt, dann ist man schon auf dem Weg dahin (zur OOP).

Du kannst mir jetzt nicht erzählen, dass dein Baustein, der die Zuführung von Komponente 1 erledigt, noch Funktionen beinhaltet, die eigentlich gar nicht mehr zu der Station gehören - damit fängt es aber schon an.
Ich kenne bei uns aus der Firma Programme (altes Step5-Erbe), da wird die Majorität an Funktionen im FB1 erledigt - dementsprechend ist der riesengroß.

Es zieht sich aber auch schon durch die Elektrotechnik mit durch.
Wer benutzt den z.B. einen Frequenzumrichter um damit die Funktion von Lichtvorhängen zu überwachen ...? Auch das ist aber Kapselung ...

Oder ... um zum Programmieren zurück zu kommen ...
Wenn ich eine bestimmte Berechnung habe, die ich im Zyklus öfter, aber mit unterschiedlichen Grundwerten, benötige ... mache ich mir dann einen FC, der die Berechnung mit den unterschiedlichen Parametern ausführt ... oder schreibe ich den gleichen Code 5x ins Programm ?

Ich denke, wenn man das mal realistisch bei Licht betrachtet, dann ist es vielleicht weniger problematisch als es aussieht.

Gruß
Larry

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich seh das relativ entspannt und behaupte mal, dass mit Multiinstanzen, Trennung von Schnittstelle, statischen und temp. Lokaldaten sowie symbolischer Adressierung eh schon die Grundzüge von OOP vorhanden sind.

Gruß
Dieter

 

[bike]

Soll ich das jetzt als positiv interpretieren ?
Sorry ... das hört sich für mich nicht nach Fortschritt an ...

Nein sollst du nicht. Du magst ja recht haben.
Doch wem ist mit Fortschritt geholfen, wenn das Ergebnis nicht den Anforderungen genügt?
Ich muss am Ende Rede und Antwort stehen, wenn es geknallt hat.

Man muß es vielleicht gar nicht an Klassen und Methoden festmachen - es würde schon "strukturiert" reichen. Es muss auch nicht von Vererbung von Eigenschaften die Rede sein - hier wäre schon Kapselung von Funktionen und Aufgaben ganz hilfreich. Wenn man das ein bißchen verfolgt, dann ist man schon auf dem Weg dahin (zur OOP).

Da gehe ich völlig konform.
Dass in der Vergangenheit das Wissen um ingenieurmäßiges Entwickeln und Strukturierung in der Programmierung in der Automatisierungstechnik nicht oder nur zögerlich angewendet wird bzw wurde, ist ein Versäumnis.
Doch ist bis zu OOP doch noch ein weiter Weg.

Oder ... um zum Programmieren zurück zu kommen ...
Wenn ich eine bestimmte Berechnung habe, die ich im Zyklus öfter, aber mit unterschiedlichen Grundwerten, benötige ... mache ich mir dann einen FC, der die Berechnung mit den unterschiedlichen Parametern ausführt ... oder schreibe ich den gleichen Code 5x ins Programm ?

Damit ist aber nicht OOP beschrieben, sondern vernünftige Planung eines Programmes mit sinnvoller Strukturierung und Kapselung.
OOP ist aber mehr, zumindest erhebt es den Anspruch darauf.
Nach meiner Erfahrung ist auch der Hype um OOP langsam wieder zurück in der Realität.
Nicht alles was theoretisch möglich ist, ist auch in der Praxis sinnvoll.

bike

 

[Graph&SCL_Freak]

Dass in der Vergangenheit das Wissen um ingenieurmäßiges Entwickeln und Strukturierung in der Programmierung in der Automatisierungstechnik nicht oder nur zögerlich angewendet wird bzw wurde, ist ein Versäumnis.

Liegt aber auch an jedem selbst. Bei den meisten S7-Leuten ist AWL immer noch das Mass aller Dinge, weil sie damit begonnen (gelernt) haben und eben nicht - wie wenige andere - von den Hochsprachen kommen. Der Satz "Wir halten AWL für eine tote Sprache" aus einer Beckhoff Veranstaltung letzte Woche zur Vorstellung von TwinCAT 3 spricht mir da aus der Seele.