OOP - Debugging- / Inbetriebnahmestrategie

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Genau das kann ja auch von so manchen Maschinenbauer gewollt sein.
Für so jede noch so kleine Störung muss dann der Spezialist ran, über
die Fernwartung oder auch vor Ort. Dieses wird dann teuer bezahlt.

und wenn der Spezialist krank oder in Rente oder tot ist, kannst die Maschine wegwerfen... Schöne neue Welt...

 

[Blockmove]

Das Forum hier ist extrem Siemens lastig und daher ist es natürlich schwer sich OOP von Codesys und Co. vorzustellen.
Und selbst in der Codesys-Welt nutzen nur wenige OOP.
Ich versuche es mal auf Siemens-Basis zu erklären.
Einer der Vorteile von OOP sind Objekte. Diese Code und Daten gemeinsam.
Also erstellen wir einen Multinstanz-FB mit all den notwenigen Daten und dem Basiscode.
Auf die Daten innerhalb soll nicht direkt zugegriffen werden.
Will ich daten Auslesen nutzt man sogenannte Eigenschaften.
Soll etwas ausgeführt werden, dann gibt es Methoden.
Beides kann man sich als Funktionen vorstellen, an die die MultiInstanz als InOut übergeben wird.
Hat man nun eine komplette Anlage so ergibt das letztlich unheimlich tief innereinander verschachtelte Daten- und Bausteinstrukturen.
Für den Programmierer ist es einfach.

St3.Bohren.Ab(300.000) := St2.Teilekontrolle AND St3.Ready

Nur wie die Signale gebildet werden und wo sie herkommen, ist halt nicht einfach erkennbar.
Schließlich können Methoden und Ereignisse über das ganze Programm verteilt sein.
Dazu kommt nun noch das Problem, dass auch das Online-Beobachten nur eingeschränkt funktioniert.

Das war jetzt halt die ganz stark vereinfachte Erklärung. Vielleicht können die Codesys-Kollegen es detailierter erklären und mit ein paar Screenshots zeigen.

Gruß
Blockmove

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nur wie die Signale gebildet werden und wo sie herkommen, ist halt nicht einfach erkennbar.
Schließlich können Methoden und Ereignisse über das ganze Programm verteilt sein.

Gibts dann nen 1000seitiges Handbuch, wo erklärt ist, welche Methoden Objekte Eigenschaften es gibt und was diese tun

 

[Blockmove]

Gibts dann nen 1000seitiges Handbuch, wo erklärt ist, welche Methoden Objekte Eigenschaften es gibt und was diese tun

Ist halt wie mit den berühmten Standard-Bausteinen der einzelnen Lieferanten
Wago macht in seinen neuen Bibliotheken schon recht häufig Gebrauch von OOP.
Wenn es komplexe Dinge sind, dann hat auch hier das OOP-Konzept seine Vorteile.
Du hast nicht einen riesen Baustein mit ellenlangen Parameterlisten, wo du 70% nicht brauchst, sondern kannst es kompakt und modular halten.
Optionale oder ergänzende Funktionen können auch richtig gut gehandelt werden. Es gibt dazu noch so Dinge wie Interfaces, Vererbung usw.

 

[Biiebs]

@Blockmove
Danke! Erstmal gute Beschreibung. Das stimmt, dass Forum ist sehr Siemenslastig und der Gebrauch von den Vorteilen vielen nicht bewusst.
Ich glaube wir sollten mal so eine OOP FAQ starten um hier etwas klarheit zu schaffen

Gibts dann nen 1000seitiges Handbuch, wo erklärt ist, welche Methoden Objekte Eigenschaften es gibt und was diese tun

Nicht ganz ;-)
Wie Blockmove schon erwähnte in der Bibliothekentwicklung wird schon sehr viel OOP verwendet um die Abhängigkeiten zueinander einfach sehr gering zu halten ("Lose Kopplung").
Das gleiche gilt in der Softwareentwicklung der Anlage. Eigentlich ist es ist es prinzpiell so, dass man eigentlich alle Freiheiten besitzt, sprich man hätte theoretisch auch die Möglichkeit aus einem Apfel eine sprechende Himbeere und aus der daraus resultierenden Himbeere einen Hasen zu basteln, je nach Paradigma.
Man beschränkt sich im wesentlichen auf die kleinste Komponente und baut "objektbezogen" diese modular zusammen, mit dem Vorteil, dass man Objekten danach ohne Abhängikeiten und großen änderungen, "Aufgaben" hinzufügen kann oder wegnehmen, da diese intern gekapselt sind.
Eigentlich wenn man es genau nimmt, wendet jeder SPS-Entwickler der strukturiert die Software aufbaut schon passiv OOP an, in Form von FB's und FUN's. Die entsprechend in Massen vorhanden sind.
Der Unterschied zum wesentlichen OOP ist, man beschränkt sich auf eine Klasse (Objekt), die durch die jeweiligen Methoden, eigenständig ihre Aufgabe erledigt und den Status über Properties nach außen gibt (Keine IN_OUT - Durchschleifen die Abhängigkeiten erzwingen etc.). Gibt ein paar schöne Sachen und Designs im OOP, die die Arbeit doch sehr vereinfachen ;-)

Und wie gesagt zeitersparnis durch weniger Coding, flexibel skalierbar durch Vermeidung von Abhängigkeiten aber halt (aktuell noch) zu unübersichtlich für die IBN. In der Bibliothekentwicklung ist OOP 1A einsetzbar

PS: Ein paar Beispiele denke ich könnte ich nächste Woche dann liefern ;-)

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eigentlich wenn man es genau nimmt, wendet jeder SPS-Entwickler der strukturiert die Software aufbaut schon passiv OOP an, in Form von FB's und FUN's

Deshalb verstehe ich vermutlich nicht, was daran neu sein soll...

 

[Blockmove]

Deshalb verstehe ich vermutlich nicht, was daran neu sein soll...

Da du ja recht spezielle Anwendung in Hinsicht auf unterbrechungsfreien Betrieb hast, wirst du sehr wahrscheinlich viel mit Global-DBs arbeiten und mit div. FBs und FCs darauf zugreifen. Bei OOP kannst du nun das alles unter einen gemeinsamen Hut (Objekt) packen. Somit entfallen z.B. viele interne Schnittstellen. Das Durchreichen von Datenstrukturen mit InOut ist so nicht mehr notwendig.
Frag jetzt aber bitte nicht, ob und wie sowas stossfrei, ohne AG-Stop und Reinitialiserung funktioniert

 

[Mrtain]

Hallo,

ich würde hier nachfolgend gerne mal beschreiben, wie das bei Jetter gehandhabt wird.

Für mich sind die Klassen quasi der Ersatz für FB's, da es so was bei Jetter nicht gibt.


Bei Jetter werden folgende OOP-Prinzipen unterstützt:

• Vererbung
  • Keine Mehrfachvererbung. Polymorphie kann über Interface realisiert werden
• Interfaces
  • Interfaces können auch von anderen Interfaces erben
• Propertys
• Kapselung
  • public/protected/private

Erstellung einer Klasse

• Eine Klasse wird innerhalb eine type... end_type; - Blocks erstellt
• Methoden und Propertys werden zwar innerhalb #Klassenname :class ... end_class; - Blocks deklariert,
  die Definition findet aber allerdings außerhalb des type... end_type; - Blocks statt.
• Klassen besitzen einen Konstruktor
• Beispielcode:
  (Ja ich weiß, es ist ein sehr banales Beispiel )
  

  type
  
      // enum / structs eg. for class or interface
      enCountMode :enum(Up,Down);
  
      //------------------------------------------------------------------------------------------------------------------------
  
  
      //-----------------------------------------------------------
      // Interface ICounter
      //-----------------------------------------------------------
      ICounter :interface
   
          #pragma intellisense(off)
          function GetActualCount() :int;
   
          #pragma intellisense(on)
          function Count(viCountValue :int := 1, Mode :enCountMode := enCountMode.Up);
          property ActualCount :int read GetActualCount;
   
      end_interface;
  
      //------------------------------------------------------------------------------------------------------------------------
  
  
      //-----------------------------------------------------------
      // Class clUpCounter
      //-----------------------------------------------------------
      clUpCounter :class(ICounter)
   
          //----------------------------------------
          // Beschreibung:
          // Klasse zum hochzaehlen eniner variable
          //----------------------------------------
   
   
          //---------------------------------------------------
          // Member
       
          protected viActualCount :int;
       
       
          //---------------------------------------------------
          // Other instances
   
   
          //---------------------------------------------------
          //Methods and propertys
       
          #pragma intellisense(off)
          protected function GetActualCount() :int;
       
          // constructor
          protected function clUpCounter(viInitCountValue :int := 0);
   
          #pragma intellisense(on)
          public function Count(viCountValue :int := 1, Mode :enCountMode := enCountMode.Up);
          public property ActualCount :int read GetActualCount;
   
   
      end_class;
  end_type;
  
  
  //-----------------------------------------------------------
  // Constructor
  function clUpCounter.clUpCounter
      // set init value
      this.viActualCount := viInitCountValue;
  end_function;
  
  
  //-----------------------------------------------------------
  // GetActualCount
  function clUpCounter.GetActualCount
      // Getter
      GetActualCount := this.viActualCount;
  end_function;
  
  
  //-----------------------------------------------------------
  // Count
  function clUpCounter.Count
      viActualCount += abs(viCountValue);
  end_function;
  
  // Instanzierung
  var
      objUpCounter01 :clUpCounter();
      objUpCounter02 :clUpCounter(5);
  end_var;

  
  Das ganze sieht dann im Setup-Fenster erstmal so:
  (Da ich das ganze auf der virtuellen CPU getestet habe, werden im SetUp auch die Properties angezeigt. Auf einer realen CPU geht
  das leider nicht)
  
  

Ich kann dazu gerne weitere Infos geben

 

[samus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Einen kleine Erleichterung beim debuggen von Methoden ist, die Variabeln als VAR_INST zu deklarieren. So kann man die Variablen werte in der Onlineansicht sehen. Achtung: Die Werte sind dann aber länger als einen Zyklus gespeichert. Je nach Programmierstil kann das zu unerwünschten Nebeneffekten führen.

 

[malloc]

Die objektorientierten Erweiterungen eignen sich meiner Erfahrung nach am besten für wiederkehrende, standardisierte Objekte (Ventil, Zylinder, komplexere Rechnungen, Parser, ein selbstgeschriebener Regler, ...) in Library-Projekten. Die FB's sollten gut getestet und ausgiebig dokumentiert sein, sodass der Maschinenprogrammierer diese FB's nutzen kann, wie alle anderen Bausteine aus den Standard-Libraries auch. Da debugge ich ja auch nicht hinein.

Irgendwo weiter oben stand noch, dass der OOP-Code schlechter wartbar wäre. Da muss ich widersprechen. Wenn man die Vererbungshierarchie flach hält und klare Module definiert (und dokumentiert!) hat, ist es nicht schwerer oder leichter, die Software zu warten.

Obendrein muss man im Moment auch noch bedenken, dass die Unterstützung von Methods und Properties aus der TwinCAT Visu nur eingeschränkt bis gar nicht vorhanden ist. Das soll zwar mal kommen, dass man auch Methods und Prop's aus der Visu direkt anbinden kann, im Moment ist es aber mit Javascript-Orgien verbunden und selbst dann nicht komplett funktionsfähig.

 

[Gleichrichter1]

Mit Interfaces, Vererbung, Methoden und dann den Pointern "This" und "Super" an Anlagen die jemand fremdes programmiert hat, sind 99,5% der Leute einfach überfordert einen Fehler zu finden.
Der eigendliche Programmierer mag ja wissen was er wo macht (eventuell auch nach 5 Jahren noch) aber jemand fremdes hat hier keine Chance in einem angemessenen Zeitrahmen einen Fehler zu finden, geschweige ein Programm zu erweitern.

Ich bin Instandhalter und traue mir OOP zu, und wenn ich es nicht begreife, dann lerne ich es. (In dem Fall einer von 200 .)
Jedenfalls werde ich mich damit auseinander setzen, und ein paar FB's selber schreiben, den wahrscheinlich komme ich eh nicht darum herum.

Wieso wird immer wieder behauptet das 'klassische Programmierung' immer wartbar ist? Ich habe leider schon zu viele chaotische Programme gesehen, die ich nicht begreife.
Und Spagettiprogramme laufen in der Regel nicht mehr, wenn etwas geändert wird.

Hoffentlich noch viele Diskussionen, das Thema Interessiert mich!
Gruss

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hoffentlich noch viele Diskussionen, das Thema Interessiert mich!

Mich auch.

Interessant wären vor allem mal Beispiele und Vergleiche so dass man mal näher an die Sprache ran kommt und es greifbarer wird. Die Diskussion ob das jetzt brauchbar ist oder nicht bringt einen ja auch nicht weiter.

 

[georg28]

Das erste ist man muss mit Actions oder Methoden in einem FB arbeiten um objektorientierte Sps Programme.erstellen zu können. Einfach einen FB nehmen wollen der bereits besteht und dann Vererbung machen wollen oder andere Sachen funktioniert nicht. Wenn man eine vorhandene Bibliothek klassisch programmiert auf oop umstellen will ist einiges an Arbeit nötig. Der Vorteil ist man hat nicht einen riesigen Codeblock wie bisher innerhalb des FB Aufruf sondern getrennt in mehreren actions und Methoden. Ein Nachteil ist halt mann muss mehr umherspringen zwischen den Codeteilen. Und beobachten ist auch nicht so einfach

 

[ducati]

Naja, vielleicht zeigt hier mal jemand einfach den Code von nem OOP-Motorbaustein...

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich bin Instandhalter und traue mir OOP zu, und wenn ich es nicht begreife, dann lerne ich es.

Klar kann man alles lernen. Und am besten jeden Tag was neues.
Bevor ich OOP in der Industrieautomatisierung einsetzen würde, müssten mir schon wirkliche große Vorteile und keine gravierenden Nachteile aufgezeigt werden. Ansonsten ist es einfach nur ANDERS

 

[Oberchefe]

Ein Kollege von mir hat auch mal gemeint, er muss Methoden anstatt FBs verwenden weil das viel cooler und neuer ist. Ohne Variablen Online beobachten zu können macht die Fehlersuche nicht wirklich Spaß. Und das gehört für mich zu den Grundanforderungen einer SPS.
Ich habe mit den Möglichkeiten von Multiinstanzen und FBs noch nicht wirklich OOP vermisst.

 

[georg28]

Naja, vielleicht zeigt hier mal jemand einfach den Code von nem OOP-Motorbaustein...i

Ich könnte dir etwas zeigen aber das währe so groß dass würde niemand lesen wo es um ds402 für canopen geht. Da ist es so dass 90 Prozent des Protokolls meistens gleich ist aber irgendwo in einem Control oder statuswort war irgendwas doch mal anders. Da war Vererbung oder Methoden überschreiben klasse. Da hat man wirklich nur den spizifischen teil angepasst und Basta. Man hat dann halt auch sofort gesehen wo der Unterschied ist ohne viel Copy Paste Arbeit wie herkömmliche Programmierung. gerade Motorcontroller da kommt es dann halt auch sehr drauf an was für Technologien verwendet werden. Profinet und Ethercat da ist es eh sehr von den Hersteller abhängig was der anbietet. Auch soetwas wie generische Listen usw wo man viel Daten händelt hat oop Methoden und actions und properties auch große Vorteile.
Das sehe ich momentan selbst jeden Tag. Das mit 0815 FBs zu machen und dann noch alles ohne Enums. Wenn ich dies mit Tia müsste programmieren würde ich mich erschießen