Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 30

Thema: OOP in IEC61131-3

  1. #11
    Registriert seit
    10.08.2008
    Ort
    Hamburg
    Beiträge
    45
    Danke
    10
    Erhielt 4 Danke für 4 Beiträge

    Daumen hoch


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Ralle Beitrag anzeigen
    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...
    if (ahnung == 0) {read Manuel; use SEARCH; use GOOGLE; } else { use brain; make post; }

  2. #12
    Registriert seit
    03.04.2008
    Beiträge
    6.200
    Danke
    237
    Erhielt 815 Danke für 689 Beiträge

    Standard

    Zitat Zitat von Ralle Beitrag anzeigen
    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.
    Ich würde es als "kundenorientiertes Programmieren" bezeichnen.
    Und das ist doch die Aufgabe von PLC Programmieren.


    Zitat Zitat von Ralle Beitrag anzeigen
    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

  3. #13
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.404 Danke für 2.002 Beiträge

    Standard

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

    Zitat Zitat von Ralle Beitrag anzeigen
    ... denn OOP wird ja nicht selten eher Schlecht als Recht umgesetzt.
    Zitat Zitat von Ralle Beitrag anzeigen
    ... 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

  4. #14
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.404 Danke für 2.002 Beiträge

    Standard

    Zitat Zitat von bike Beitrag anzeigen
    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 ...

  5. #15
    Registriert seit
    09.11.2007
    Ort
    Rhein Main (Darmstadt)
    Beiträge
    663
    Danke
    61
    Erhielt 112 Danke für 80 Beiträge

    Standard

    Zitat Zitat von Larry Laffer Beitrag anzeigen
    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.
    Als Freelancer immer auf der Suche nach interessanten Projekten.
    Zitieren Zitieren Lernen und immer wieder lernen  

  6. #16
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.223
    Danke
    533
    Erhielt 2.698 Danke für 1.950 Beiträge

    Standard

    @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.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  7. #17
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.404 Danke für 2.002 Beiträge

    Standard

    @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

  8. #18
    Registriert seit
    17.07.2009
    Ort
    Am Rande der Ostalb
    Beiträge
    5.487
    Danke
    1.141
    Erhielt 1.243 Danke für 974 Beiträge

    Standard

    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

  9. #19
    Registriert seit
    03.04.2008
    Beiträge
    6.200
    Danke
    237
    Erhielt 815 Danke für 689 Beiträge

    Standard

    Zitat Zitat von Larry Laffer Beitrag anzeigen
    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.

    Zitat Zitat von Larry Laffer Beitrag anzeigen
    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.


    Zitat Zitat von Larry Laffer Beitrag anzeigen
    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

  10. #20
    Registriert seit
    17.09.2006
    Beiträge
    136
    Danke
    0
    Erhielt 7 Danke für 7 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von bike Beitrag anzeigen
    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.

Ähnliche Themen

  1. Konstante in PC Worx, IEC61131
    Von pkh im Forum Sonstige Steuerungen
    Antworten: 2
    Letzter Beitrag: 29.06.2011, 21:39
  2. C++ nach IEC61131
    Von cas im Forum CODESYS und IEC61131
    Antworten: 4
    Letzter Beitrag: 09.06.2011, 14:54
  3. Fehlerhandling nach IEC61131-3?
    Von Snape im Forum Programmierstrategien
    Antworten: 4
    Letzter Beitrag: 27.07.2010, 23:02
  4. Indirekte Adressierung in der IEC61131-3
    Von tahren im Forum CODESYS und IEC61131
    Antworten: 2
    Letzter Beitrag: 24.06.2010, 12:34
  5. STEP 7 ---> IEC61131-3 von CoDeSys
    Von Rayk im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 05.12.2003, 18:32

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •