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

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 27

Thema: Codesys Objektorientiertes Programmieren

  1. #1
    Registriert seit
    08.12.2010
    Beiträge
    62
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo,
    ich arbeite mich gerade ins objektorientierte Programmieren ein.

    Ich möchte z.B. ein FB fbAuto mit verschiedenen Methoden einfügen.
    Im FB Auto deklariere ich:

    VAR
    xAutoFahrberereit : BOOL;
    iAnzahlTueren : INT;
    rLeistung : REAL;
    END_VAR


    Im MAIN-Programm möchte ich darauf zugreifen.
    Ich lege als globale Variablen an
    Autos : Array[0..50] of fbAuto;


    Im Main Programm möchte ich nun die fahrbereiten Autos ermitteln:

    for i:=0 to 50 do

    IF Autos[i].xAutoFahrbereit then
    iAnzahlfahrbereiterAutos := iAnzahlfahrbereiterAutos +1;
    END_IF
    END_FOR



    Man kann jedoch nur auf die MEthoden von Autos zugreifen. Nicht aber auf die Variablen. Ich habe gelesen das es Eigenschaften (Properties) gibt. Müsste ich dann für jede Variable auf die ich von außen zugreifen möchte eine Propertie
    bzw. eine Methode schreiben?
    Zitieren Zitieren Codesys Objektorientiertes Programmieren  

  2. #2
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    745
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard

    Zitat Zitat von toto45 Beitrag anzeigen
    Müsste ich dann für jede Variable auf die ich von außen zugreifen möchte eine Propertie
    bzw. eine Methode schreiben?
    Das ist im Hochsprachenbereich sicher guter OOP-Stil, für Automationsprogramme aber weniger geeignet. Dort kann man bei laufender Maschine meistens keine Breakpoints setzen, sondern ist auf das Beobachten von Variablenwerten bei laufendem Programm angewiesen. Die Ergebnisse von Property Get-Methoden werden allerdings temporär über den Stack zurückgegeben und lassen sich nicht beobachten. Ich bevorzuge deshalb die Standard-IO-Schnittstelle des FB's mit ihren statischen VAR_INPUT/VAR_OUTPUT-Variablen.

  3. #3
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard

    Hallo toto45,

    1. Variablen in VAR .. END_VAR sind grundsätzlich nicht von aussen zugreifbar. Deswegen wie schon von StructuredTrash geschrieben VAR_INPUT oder VAR_OUTPUT-Variablen verwenden.
    2. Properties werden spätestens dann notwendig, sobald man mit Interfaces arbeitet. Properties sind aber Code und per default werden diese nicht gemonitort, denn wenn der Code beim Monitoring einen Seiteneffekt produziert dann könnte das sehr unangenehm sein.
    Wenn man sich sicher ist, dass durch die Ausführung des Properties kein Unsinn passieren kann, dann kann man das Monitoring mit folgendem Attribut einschalten:

    {attribute 'monitoring':= 'call'}
    PROPERTY Dingsbums: INT


    Bernhard
    Bernhard Werner
    3S-Smart Software Solutions (CODESYS)

  4. #4
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    745
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard

    Zitat Zitat von Werner29 Beitrag anzeigen
    Properties werden spätestens dann notwendig, sobald man mit Interfaces arbeitet. Properties sind aber Code und per default werden diese nicht gemonitort, denn wenn der Code beim Monitoring einen Seiteneffekt produziert dann könnte das sehr unangenehm sein.
    Tja, und an der Stelle kann ich eine gewisse Enttäuschung über die OOP-Erweiterungen der V3 nicht verbergen. Der IEC-FB als Basis aller OOP geht mit seinen unterschiedlichen Zugriffsrechten auf seine Variablen (VAR, VAR_INPUT, VAR_OUTPUT) ja schon einen etwas anderen Weg als die Hochsprachen mit ihren von Strukturen abgeleiteten Objekten, und dieser Weg ist in meinen Augen für Automationsaufgaben auch hervorragend geeignet. Ich hätte mir gewünscht, dass dieser Weg bei der Einführung weiterer OOP-Mechanismen fortgesetzt würde. Stattdessen wurden die Erweiterungen nahezu unverändert aus der Hochsprachenwelt übernommen. Wirklich brauchbar ist für mich nur die Vererbung.

  5. #5
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard

    Zitat Zitat von StructuredTrash Beitrag anzeigen
    Tja, und an der Stelle kann ich eine gewisse Enttäuschung über die OOP-Erweiterungen der V3 nicht verbergen. Der IEC-FB als Basis aller OOP geht mit seinen unterschiedlichen Zugriffsrechten auf seine Variablen (VAR, VAR_INPUT, VAR_OUTPUT) ja schon einen etwas anderen Weg als die Hochsprachen mit ihren von Strukturen abgeleiteten Objekten, und dieser Weg ist in meinen Augen für Automationsaufgaben auch hervorragend geeignet. Ich hätte mir gewünscht, dass dieser Weg bei der Einführung weiterer OOP-Mechanismen fortgesetzt würde. Stattdessen wurden die Erweiterungen nahezu unverändert aus der Hochsprachenwelt übernommen. Wirklich brauchbar ist für mich nur die Vererbung.
    Was hättest du dir denn vorgestellt? Ich finde unsere Erweiterungen des FB sehr natürlich. Aber ich bin auch immer offen für Ideen.
    Bernhard Werner
    3S-Smart Software Solutions (CODESYS)

  6. #6
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    745
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard

    Ich hätte es besser gefunden, wenn Methoden und Properties ebenfalls statische Variablen hätten (oder alternativ haben könnten). Sozusagen eine Erweiterung der FB-Datenstruktur, die aber nur in den Methoden sichtbar ist, in denen sie deklariert ist.

  7. #7
    Registriert seit
    15.11.2012
    Beiträge
    41
    Danke
    3
    Erhielt 8 Danke für 8 Beiträge

    Standard

    Zitat Zitat von toto45 Beitrag anzeigen
    Man kann jedoch nur auf die MEthoden von Autos zugreifen. Nicht aber auf die Variablen. Ich habe gelesen das es Eigenschaften (Properties) gibt. Müsste ich dann für jede Variable auf die ich von außen zugreifen möchte eine Propertie
    bzw. eine Methode schreiben?
    Ja, du müsstest für jede Variable ein Property anlegen.
    Wie schon beschrieben, eigenet sich für POUs ohne Interfaces VAR_INPUT und VAR_OUTPUT meistens besser (es sei denn es muss beim Setzen / bei der Abfrage noch Code ausgeführt werden, z.B. eine Umrechnung).


    Zitat Zitat von Werner29 Beitrag anzeigen
    Was hättest du dir denn vorgestellt? Ich finde unsere Erweiterungen des FB sehr natürlich. Aber ich bin auch immer offen für Ideen.
    Ohne über genaue Auswirkungen nachzudenken:
    In Interfaces soll man VAR_INPUT und VAR_OUTPUT angeben können, die die implementierende POU dann besitzen muss.


    Zitat Zitat von StructuredTrash Beitrag anzeigen
    Ich hätte es besser gefunden, wenn Methoden und Properties ebenfalls statische Variablen hätten (oder alternativ haben könnten). Sozusagen eine Erweiterung der FB-Datenstruktur, die aber nur in den Methoden sichtbar ist, in denen sie deklariert ist.
    Für Sonderfälle mit nur einer Instanz: Kennst du VAR_STAT?
    Geändert von Interface (11.03.2014 um 08:34 Uhr)

  8. #8
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard

    Vorsicht: VAR_STAT ist eine global statische Variable, keine Instanzvariable.
    Wir planen allerdings VAR_INST-Variablen für die nächste Version 3.5 SP 5. Sowas wird es aber nie für Inputs von Methoden geben.
    Also die wird man weiterhin in eine Instanzvariable kopieren müssen, wenn es notwendig ist dass die erhalten bleiben.

    Grundsätzlich gilt natürlich, Datenkapselung ist ein wesentliches OO-Prinzip. Man kann nicht sagen wir machen OO, aber ohne Datenkapselung.
    Man arbeitet eben eher mit Methoden und Properties als mit INPUTS und OUTPUTS.
    Das mag zunächst umständlicher wirken, aber nur dadurch kann man zur Laufzeit das eine Objekt gegen ein anderes austauschen,
    weil es eben dieselbe Schnittstelle bietet.

    >Ohne über genaue Auswirkungen nachzudenken:
    >In Interfaces soll man VAR_INPUT und VAR_OUTPUT angeben können, die die implementierende POU dann besitzen muss.

    Es ist tatsächlich technisch bedingt, dass das nicht geht. Wer C++ programmiert, der wird wissen, dass Mehrfachvererbung bei Daten Ärger bedeutet.
    Ich will da nicht auf die Details eingehen, wen's interessiert der findet jede Menge Literatur dazu.
    Modernere OO-Sprachen haben deswegen diese Mehrfachvererbung aufgegeben und stattdessen Interfaces eingeführt.
    Und Interfaces dürfen eben nur Methoden definieren. Man kann daher jetzt von einem FB ableiten, aber beliebig viele Interfaces implementieren.
    Datenzugriffe werden über Properties festgelegt.


    Bernhard Werner
    3S-Smart Software Solutions (CODESYS)

  9. Folgender Benutzer sagt Danke zu Werner29 für den nützlichen Beitrag:

    Interface (11.03.2014)

  10. #9
    Registriert seit
    26.11.2012
    Ort
    Gummersbach
    Beiträge
    502
    Danke
    18
    Erhielt 71 Danke für 69 Beiträge

    Standard

    Hallo,

    Sorry, wenn ich das Thread-Thema ein bisschen biege, aber ich habe das Gefühl hier genau die richtigen Ansprechpartner gefunden zu haben.
    Also: Ich komme aus der "klassischen" SPS-Ecke und habe bisher nur wenige Berührungspunkte mit Hochsprachen gehabt.

    Ich habe bisher viel in AWL, später in FUP programmiert. Dabei wurden mehrfach auftretende Aufgaben einfach in Funktionen gepackt und dann an der entsprechenden Stelle aufgerufen.

    Nun versuche ich mich in V3.5 einzuarbeiten und stoße auf den Begriff Objektorientierung.
    Soweit ich das verstanden habe, würde man nun eine Funktion z.B. Heizkessel definieren und z.B. die Temperaturregelung als Methode dieser Funktion - das ist im Grunde nicht so anders als die Programmierung mit Funktionen früher, nur das nun unterschiedliche Aufgaben, die physikalisch zusammengehören (weil es immer um den selben Heizkessel geht) gruppiert.

    Nun zu meiner Frage:
    Welchen Vorteil bringt es, diese Methoden nun in Schnittstellen nochmal auszugliedern? Ich sehe irgendwie noch nicht, welchen Vorteil dieser Schritt bringt.

    Sorry fürs "auf dem Schlauch stehen", aber ich bin wie schon gesagt blutiger Anfänger in objektorientiertem Programmieren.

    Danke fürs erleuchten!

    Gruß

    Christian
    Ganz kurz ganz hell
    ganz lange ganz dunkel....

  11. #10
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    745
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Morymmus Beitrag anzeigen
    Welchen Vorteil bringt es, diese Methoden nun in Schnittstellen nochmal auszugliedern? Ich sehe irgendwie noch nicht, welchen Vorteil dieser Schritt bringt.
    Wenn Du z. B. mehrere Baugruppen-FBs hast, die bislang über eine einheitliche Datenschnittstelle zum Programm verfügen, könntest Du statt dessen ein einheitliches Interface mit Methoden und Eigenschaften für diese FBs definieren. Dann könntest Du ein Array of Baustein-Interface deklarieren, um die FBs, obwohl sie von unterschiedlichem Typ sind, in einer Schleife aufrufen zu können.
    Ob sich das lohnt, hängt von der Anzahl der FBs ab. Bei meinen Programmen (allgemeiner Maschinenbau) wird die Anzahl der FBs, die ich in einem PRG oder einem anderen FB instanziiere, nur selten zweistellig. Da sehe ich noch keinen Bedarf für Interfaces, sondern schätze beim Debuggen den Vorteil, mit jedem FB per Du zu sein. Bei der Automatisierung grosser Gebäude mit drei- oder gar vierstelliger Anzahl von Räumen kann das aber anders aussehen.

Ähnliche Themen

  1. Antworten: 0
    Letzter Beitrag: 15.10.2012, 09:44
  2. Ablaufsequenz programmieren in CodeSys
    Von ElektoEsel im Forum CODESYS und IEC61131
    Antworten: 2
    Letzter Beitrag: 06.02.2011, 22:13
  3. CoDeSys programmieren
    Von Jumpinjack im Forum CODESYS und IEC61131
    Antworten: 1
    Letzter Beitrag: 15.12.2010, 15:01
  4. Codesys Programmieren
    Von Shierasse im Forum Sonstige Steuerungen
    Antworten: 5
    Letzter Beitrag: 15.12.2009, 09:00

Lesezeichen

Berechtigungen

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