# OOP in IEC61131-3



## Neals (6 September 2009)

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 (7 September 2009)

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 (4 Dezember 2009)

*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 (4 Dezember 2009)

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 (4 Dezember 2009)

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 (4 Dezember 2009)

@drfunfrock

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


----------



## gravieren (4 Dezember 2009)

Hi


Schau dir doch mal die 3S-Homepage an.

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


----------



## drfunfrock (4 Dezember 2009)

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! (27 Oktober 2010)

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


----------



## Ralle (27 Oktober 2010)

!name! schrieb:


> 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 (27 Oktober 2010)

Ralle schrieb:


> 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 (31 Oktober 2010)

Ralle schrieb:


> 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.




Ralle schrieb:


> 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 (1 November 2010)

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 ...



Ralle schrieb:


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





Ralle schrieb:


> ... 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 (1 November 2010)

bike schrieb:


> 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 (1 November 2010)

*Lernen und immer wieder lernen*



Larry Laffer schrieb:


> 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 ...
> 
> ...



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 (1 November 2010)

@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 (1 November 2010)

@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 (1 November 2010)

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 (1 November 2010)

Larry Laffer schrieb:


> 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. 



Larry Laffer schrieb:


> 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.




Larry Laffer schrieb:


> 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 (1 November 2010)

bike schrieb:


> 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.


----------



## bike (1 November 2010)

Graph&SCL_Freak schrieb:


> 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.



Das höre ich seit Jahren.
Noch? ist die Entwicklung nicht so weit, dass AWL getoted ist.
Da wird noch viel Wasser durch den Lech fliesen, bis dem so ist.

Außerdem ist AWL nicht schlecht, wenn man es kann, so wie bei allem.

bike


----------



## Graph&SCL_Freak (1 November 2010)

Ich brauch AWL nicht, also für mich tot. 

Die konservative Einstellung der meisten SPS-Programmierer verhindert leider moderne Programmieransätze in der SPS Welt. 

Mein Lieblingssatz ist immer 'Machen wir seit Jahren so...', Mahlzeit.


----------



## bike (1 November 2010)

Graph&SCL_Freak schrieb:


> Ich brauch AWL nicht, also für mich tot.
> 
> Die konservative Einstellung der meisten SPS-Programmierer verhindert leider moderne Programmieransätze in der SPS Welt.
> 
> Mein Lieblingssatz ist immer 'Machen wir seit Jahren so...', Mahlzeit.



Das ist deine Meinung. 
Schon einmal darüber nachgedacht, dass konservativ nicht den Fortschritt beeinträchtigen muss?

Es ist toll, dass das Neue als einzig Heilsbringende angeschaut wird.
Wichtig ist das Ergebnis und noch gibt es weder eine vernünftige PLC noch eine entsprechende Entwicklungsumgebung für OOP. 

Bei allem Drang nach Fortschritt darf nie vergessen werden, dass für den Kunden und dessen Nutzen Programme erstellt werden.

Also mir ist Win sehr suspekt, doch haben wir nicht die Macht, jeden Fehler den wir ausliefern als Feature zu verkaufen.  Wir müssen Fehler kostenfrei beheben.

bike


P.S: und ja,  seit über 25 Jahren programmiere ich Hochsprachen, doch in PLC muss nicht sein


----------



## Ralle (1 November 2010)

Graph&SCL_Freak schrieb:


> Ich brauch AWL nicht, also für mich tot.
> 
> Die konservative Einstellung der meisten SPS-Programmierer verhindert leider moderne Programmieransätze in der SPS Welt.
> 
> Mein Lieblingssatz ist immer 'Machen wir seit Jahren so...', Mahlzeit.



Das ist eine der dämlichsten Argumentationen, die hier in diesem Thread bisher kam, dann sag doch besser nichts.

Konservativ sein ist nicht von übel, ich bin konservativ, trotz allem bin ich sehr oft derjenige gewesen, der etwas Neues eingeführt hat oder versucht hat eine gewisse Ordnung herzustellen. Und natürlich sind meine Programme lange nicht so strukturiert, wie ich es eigentlich gerne hätte, denn dann müßte ich alles mal neu aufsetzen und dazu fehlen mit Zeit, Geld (oder Geldgeber) und auch ein wenig der Mut (im Moment). Ich bin auch nicht gegen OOP, weil ich das aus prinzipiellen Erwägungen bin, sondern weil ich weiß, daß dann noch mehr Unsinn in die Welt hineinprogrammiert wird. 

Klar sagt Beckhoff, daß AWL tot ist, denn von dieser Argumentation aus entwickeln die sich ja und leben recht gut davon. Aber mit ist egal, welcher Guru meint, was sagen zu müssen, ich mach das so, wie ich denke, das Optimum erreichen zu können. 

@Larry

Sei nicht böse, aber ich bin schon immer zu doof, Funktion und Daten wirklich zu trennen, geht das denn überhaupt und kann man das durchziehen. Ich kenne diese Paradigmen der OPP, aber ich hab die noch nie verstanden ... 

Wenn man immer die Zeit hätte, eine Maschine so richtig schick durch zu programmieren, wäre das toll. Aber ich will mal sehen, bei wem das klappt, evtl. bei Serienmaschinen, aber im Sondermaschinenbeu? Da wird einem die Anlage unter dem Hintern weg abgebaut und zum Kunden verbracht. Wer kennnt nicht den Spruch "Das Geld ist längst alle!" Wie soll das erst mit OOP werden??? Besser? Das glaubt ihr selbst nicht. Nichts wurde in den letzten 20 Jahren wirklich einfacher besser, leichter. Das haben wir immer gedacht, aber dann kommt immer etwas Neues hinzu und wenn es nur die neue Programmierumgebung unseres Lieblings-SPS-Hersteller ist! 

PS:
Ich bin auch kein großer Freund von Graph, weil es abhängig von Siemens macht, weil ich zu viele schlecht funktionierende Graph-Programme bearbeiten mußte und weil man manchmal einfach nicht genau weiß, was denn nun warum passiert. Eigentlich eine gute und schöne Sache, aber auch nie fehlerfrei und eben mal easy zu handhaben. OOP wird das nicht besser können.


----------



## Graph&SCL_Freak (1 November 2010)

Ralle schrieb:


> Wenn man immer die Zeit hätte, eine Maschine so richtig schick durch zu programmieren, wäre das toll. Aber ich will mal sehen, bei wem das klappt, evtl. bei Serienmaschinen, aber im Sondermaschinenbeu? Da wird einem die Anlage unter dem Hintern weg abgebaut und zum Kunden verbracht. Wer kennnt nicht den Spruch "Das Geld ist längst alle!" Wie soll das erst mit OOP werden??? Besser? Das glaubt ihr selbst nicht. Nichts wurde in den letzten 20 Jahren wirklich einfacher besser, leichter. Das haben wir immer gedacht, aber dann kommt immer etwas Neues hinzu und wenn es nur die neue Programmierumgebung unseres Lieblings-SPS-Hersteller ist!



*ACK*



Ralle schrieb:


> Ich bin auch kein großer Freund von Graph, weil es abhängig von Siemens macht, weil ich zu viele schlecht funktionierende Graph-Programme bearbeiten mußte und weil man manchmal einfach nicht genau weiß, was denn nun warum passiert. Eigentlich eine gute und schöne Sache, aber auch nie fehlerfrei und eben mal easy zu handhaben. OOP wird das nicht besser können.



Leider macht alles, was man bei Siemens programmiert, abhängig von Siemens, weil Siemens halt Siemens ist und sich an eine IEC61131 nicht wirklich hält.http://www.sps-forum.de/showthread.php?p=290303#post290303


----------



## Blockmove (1 November 2010)

Immer diese Glaubenskriege *ROFL*
Katholisch <-> Evangelisch
SCL <-> AWL
Sprungverteiler-Kette <-> Graph
OOP <-> Klassisch

Die Programmiersprache ist ein Werkzeug! Nicht mehr aber auch nicht weniger.
Das eigentliche Programmieren ist das Wenigste an einem Projekt.
Die Aufgabenstellung analysieren, strukturieren und gliedern. Darin besteht die Kunst. Man kann in jeder Sprache und in jedem Dialekt sauber arbeiten.

Gruß
Dieter


----------



## Graph&SCL_Freak (1 November 2010)

Ralle schrieb:


> Konservativ sein ist nicht von übel, ich bin konservativ, trotz allem bin ich sehr oft derjenige gewesen, der etwas Neues eingeführt hat oder versucht hat eine gewisse Ordnung herzustellen. Und natürlich sind meine Programme lange nicht so strukturiert, wie ich es eigentlich gerne hätte, denn dann müßte ich alles mal neu aufsetzen und dazu fehlen mit Zeit, Geld (oder Geldgeber) und auch ein wenig der Mut (im Moment). Ich bin auch nicht gegen OOP, weil ich das aus prinzipiellen Erwägungen bin, sondern weil ich weiß, daß dann noch mehr Unsinn in die Welt hineinprogrammiert wird.



Ist doch prima. Dann tausch ich 'konservativ' gegen 'nicht aufgeschlossen gegenüber Hochsprachen' oder was auch immer. Mich nervt nur dieser AWL-Fanatismuss einiger 'S7-Veteranen'. Und AWL ist für eine OOP IMHO nun wirklich denkbar ungeeignet.


----------



## Graph&SCL_Freak (1 November 2010)

Blockmove schrieb:


> Immer diese Glaubenskriege *ROFL*
> Katholisch <-> Evangelisch
> SCL <-> AWL
> Sprungverteiler-Kette <-> Graph
> ...



*ACK*

Sorry, ich habe damit angefangen. Offtopic-Ende...


----------



## Larry Laffer (1 November 2010)

Ralle schrieb:


> ... Wenn man immer die Zeit hätte, eine Maschine so richtig schick durch zu programmieren, wäre das toll. Aber ich will mal sehen, bei wem das klappt, evtl. bei Serienmaschinen, aber im Sondermaschinenbeu?


 
@Ralle:
Da hast du ganz sicher Recht. Ich bin auch bewußt, dass ich viele Dinge, die ich so programmiere, nicht auf Anhieb so erstellt habe. Wenn aber das gleiche Aggregat das 2. Mal da ist, dann kann man schon mal über Optimierungen nachdenken. Ich brauche auch nicht in erster Linie zeitoptimiert zu programmieren - im Gegenteil ... am Ende ist es entscheidend, wie gut ich die Wünsche der Produktion getroffen habe.

Der Prozess, der bei mir an manchen Stellen zu ein bißchen OOP geführt hat dauert nun schon ein paar Jahre. Da ich aber nun auch ein bißchen was anderes kennen lerne bin ich mir der Vorteile dieser Systematik durchaus im Klaren.

@Graph&SCL Freak:
Für mich ist AWL noch lange nicht tot. Das ist für mich auch kein Widerspruch zu dem bisher gesagten. Strukturierte Programme und Objekt-Orientierung ist nichts, das etwas mit der jeweiligen Programmiersprache zu tun hat ...
Welche Sprache sich für was am Besten eignet ist in erster Linie eine Frage der Anforderung. Addition wird auch nie überholt sein nur weil Multiplikation viel mehr kann - ist das wirklich so ?

In diesem Sinne ...
Gruß
Larry


----------



## Ralle (1 November 2010)

Graph&SCL_Freak schrieb:


> Ist doch prima. Dann tausch ich 'konservativ' gegen 'nicht aufgeschlossen gegenüber Hochsprachen' oder was auch immer. Mich nervt nur dieser AWL-Fanatismuss einiger 'S7-Veteranen'. Und AWL ist für eine OOP IMHO nun wirklich denkbar ungeeignet.



Nö, das ist Unsinn, sieh auf meine HP, ich programmiere durchaus auch Hochsprachen, aber nur da, wo ich es als sinnvoll erachte. Genauso halte ich das mit ST/SCL, AWL usw.


----------

