# OOP - Debugging- / Inbetriebnahmestrategie



## Biiebs (29 Juli 2022)

Hallo Community,

ich bin schon relativ lange passiver Mitleser im Forum und ich weiß, dass ich mit dem Thema OOP wieder eine sehr große Diskussion auslösen werde, aber wir schauen mal wo die Reise hinläuft. 
Vllt. wird sich die Thematik auch minimal mit meinem Vorgänger Post ("Inbetriebnahme Zeiten verkürzen") überschneiden, aber ich bezieh mich wahrscheinlich auf einen anderen Thematikschwerpunkt, andernfalls pass ich mich natürlich an. 

Zu meinem ursprünglichen Problem:

Wir haben endlich die Möglichkeit bekommen eine Neuentwicklung einer Anlage mit einem OOP Ansatz zu programmieren. (Kleine Randnotiz: Die Prinzipien sind uns bekannt, an den Strategien und Architektur sind wir jedoch noch ein bisschen am Lernen) 
Nun haben wir den ersten Anlagentyp ausgeliefert und die IBN gestartet. OOP im Softwareentwicklungsprozess ist kein Problem, OOP bei der IBN der Anlage wurde bei uns zu einem großen Problem. Das Problem dabei ist einfach, dass die für den SPSler üblichen Beobachtungswerte in den einzelnen Methoden etc. zur Nachverfolgung fehlten und wir das Programm leider nicht mit Breakpoints zukleistern konnten...

Im Großen und Ganzen reden wir hier von CODESYS bzw. von TwinCAT 3, jedoch sind die prinzipiellen Strategien wohl auch auf andere Hersteller portierbar.
Ich weißt, dass folgende Möglichkeiten bei CODESYS, TwinCAT 3 vorhanden sind:

Eigenschaften (Properties): Attribut {attribute 'monitoring' := call}
Methoden: Debugging Möglichkeit mit "Flow Control" --> Nachteil: Laufzeitvergrößerung ?
Interfaces: ??? (Hier ist mir nichts bekannt)

Wie macht Ihr das bei euch mit einem OOP Ansatz wenn  es in Richtung Debugging Prozess geht vor allem mit Interfaces, Methoden und Eigenschaften und ohne Beobachtungswerte ist es doch eher unmöglich eine Anlage in Betrieb zu nehmen oder?

Vielen Dank im Voraus.

Gruß,

Biiebs


----------



## Blockmove (29 Juli 2022)

Interessantes Thema  
Ich hab mir OOP mal mit eCockpit auf Wago angeschaut und fand das Thema Debugging auch nicht gerade gut gelöst.
Bin auch auf Meinungen, Tipps und Tricks gespannt.


----------



## ioStart (29 Juli 2022)

OOP ist eine tolle Sache.
Das Testen der Funktionen bei der Inbetriebnahme ist mit allerdings zu riskant (weil zeitintensiv). Daher versuche ich immer im Vorfeld möglichst viel abzufangen und durch Tests zu bestätigen. Das verschafft dann den Vorteil, dass man die Architektur mit größerer Sicherheit definieren kann und das Debuggen idealer-weiße ganz entfällt.


----------



## Ralle (29 Juli 2022)

Ich denke, man kann mit OOP genz schöne Programme schreiben, die dann allerdings, wie vom TE beschrieben, schlecht in Betrieb zu nehmen und noch viel schlechter zu warten sind. Da muß man sich genau fragen, welche Vorteile der OOP-Ansatz gegenüber einem "herkömmlichen Programm" mit Struktur durch FB ubd FC, eigene Standard-FB und mit vernünftigen definierten Schnittstellen (IN/OUT/INOUT) hat. Ich persönlich kann das nicht sehen, vielleicht liefert jemand ein paar Argumente?


----------



## Biiebs (29 Juli 2022)

@ioStart 
Könntest du deinen Ansatz etwas genauer beschreiben?

Klar, je nach Kapselung und Architektur des OOP-Projekts lassen sich die einzelnen Methoden und Klassen über Unit-Testframeworks (z.B. TcUnits (Twincat) / cfunit (CODESYS)) wunderbar testen, aber wir reden hier von den kleinsten zu prüfenden Programmteilen auf unterster Ebene. Erst im weiteren Prozess werden diese modular zusammengefügt. Dann ist das Testen mit Unit-Testframeworks zu aufwendig, da wir hier schon von Integrations- oder Systemtests sprechen, die in der SPS Welt leider nur durch aufwändige Emulationen oder Simulationen geprüft werden können. In anderen Hochsprachen sieht dieser (fast automatisierte) Prozess jedoch wiederum komplett anders aus.

Und genau hier liegt der Unterschied zwischen SPS und Hochsprachenentwicklung. In der SPS-Welt muss leider über einen steinigen langen Weg gegangen werden bis der Entwickler sich erstmal alles "von Hand" zusammenprogrammiert hat. In der Hochsprachenentwicklung gibt es unzählige Frameworks dafür.



> Das Testen der Funktionen bei der Inbetriebnahme ist mit allerdings zu riskant (weil zeitintensiv)



Aber genau das ist ja der wichtigste Punkt bei der Inbetriebnahme der Anlage... Wir programmieren ja genau auf dieses Ziel hin. Wie setzt du denn i Vorfeld deine Überlegungen hierfür um?

@Ralle 
Genau für den Punkt "Inbetriebnahme und Wartung" versuch ich mit diesem Thread ja evtl. Lösungsansätze "zu diskutieren", da auch mir hierfür komplette Ansätze fehlen. Natürlich müssen wir davon ausgehen, dass die OOP Prinzipien auch dem Inbetriebnehmer und dem Wartungstechniker bekannt sind und er solche Programmarchitekturen auch versteht. Natürlich ist dies in der realen Praxis noch nicht wirklich der Fall, aber ich denke in dem Post sollten wir einfach mal die Annahme machen, dass dies der Fall wäre


----------



## ducati (29 Juli 2022)

Biiebs schrieb:


> Genau für den Punkt "Inbetriebnahme und Wartung" versuch ich mit diesem Thread ja evtl. Lösungsansätze "zu diskutieren", da auch mir hierfür komplette Ansätze fehlen. Natürlich müssen wir davon ausgehen, dass die OOP Prinzipien auch dem Inbetriebnehmer und dem Wartungstechniker bekannt sind und er solche Programmarchitekturen auch versteht. Natürlich ist dies in der realen Praxis noch nicht wirklich der Fall, aber ich denke in dem Post sollten wir einfach mal die Annahme machen, dass dies der Fall wäre


Ja Ihr geht halt falsch herum an die Sache heran.
Richtig wäre zu überlegen, wie muss die Struktur aussehen, damit ne Anlage ordentlich in Betrieb gesetzt werden kann und 20 Jahre lang ordentlich erweitert und am Leben erhalten werden kann.
Wenn das mit OOP nicht geht, dann nutzt halt einfach eine der seit Jahrzehnten bewährten Programmierstile. Und versucht nicht OOP so zu verbiegen, das nicht gleich jeder die Hände über dem Kopf zusammenschlägt 

Sicherlich muss man aber auch Unterschiede zw. Serienmaschinen und Sonderanlagen machen...

Unsere Sonderanlagen leben über Jahrzehnte und werden ständig im laufenden Betrieb mehr oder weniger groß umgebaut/erweitert...


----------



## Biiebs (29 Juli 2022)

ducati schrieb:


> Richtig wäre zu überlegen, wie muss die Struktur aussehen, damit ne Anlage ordentlich in Betrieb gesetzt werden kann und 20 Jahre lang ordentlich erweitert und am Leben erhalten werden kann.
> Wenn das mit OOP nicht geht, dann nutzt halt einfach eine der seit Jahrzehnten bewährten Programmierstile. Und versucht nicht OOP so zu verbiegen, das nicht gleich jeder die Hände über dem Kopf zusammenschläg


Jaein... klar sollte eine Anlage mind. 20 Jahre funktionieren. Natürlich hat sich die klassische SPS-Programmierung ebenfalls die letzten 20 Jahre  absolut bewährt, vor allem im Anlagenbau... Aber da wir ausnahmsweise mal die Gelegenheit haben etwas neues (OOP) auszuprobieren und zu evaluieren ob sich dies für unsere Firma / Branche bewährt würde ich schon gern beim Thema OOP bleiben, manch andere Firma haben mittlerweile Anlagenbau komplett auf OOP umgestellt.


----------



## ioStart (29 Juli 2022)

@ioStart


Biiebs schrieb:


> Könntest du deinen Ansatz etwas genauer beschreiben?


OOP bedeutet für mich, dass es beispielsweise einen Baustein für ein Pneumatikventil gibt. Da ist Störbehandlung und Meldungsausgabe enthalten. Je nach Anzahl an Ventile/Zylindern gibt es halt entsprechend viele Instanzen. 

Die Instanzen kann ich notfalls auch bei der Inbetriebnahme anlegen und die variablen Werte über die Schnittstelle übergeben. Allerdings möchte ich nicht bei der Inbetriebnahme eine Baustein für Ventile, Motoren, Servos, Hydraulik.... entwickeln


----------



## ducati (29 Juli 2022)

ioStart schrieb:


> @ioStart
> 
> OOP bedeutet für mich, dass es beispielsweise einen Baustein für ein Pneumatikventil gibt. Da ist Störbehandlung und Meldungsausgabe enthalten. Je nach Anzahl an Ventile/Zylindern gibt es halt entsprechend viele Instanzen.
> 
> Die Instanzen kann ich notfalls auch bei der Inbetriebnahme anlegen und die variablen Werte über die Schnittstelle übergeben. Allerdings möchte ich nicht bei der Inbetriebnahme eine Baustein für Ventile, Motoren, Servos, Hydraulik.... entwickeln


OK, dann hab ich OOP schon vor 20 Jahren eingesetzt. 
Solange man keine Multiinstanz-DBs verwendet geht das auch im laufenden Betrieb einfach zu erweitern. Zumindest bei Siemens 

PS: ist doch wahr 😂 hat ja Ralle weiter oben auch schon angesprochen


----------



## Blockmove (29 Juli 2022)

Ich würde das Thema gerne auf Codesys und "richtiges" OOP beschränken und Siemens aussen vor lassen.
Siemens und Codesys entspricht etwa C und C++.
Und @Biiebs meint hier wirklich die Möglichkeiten von Codesys / Twincat und nicht die vergleichsweise einfachen Siemens Multiinstanzen.



ioStart schrieb:


> OOP ist eine tolle Sache.
> Das Testen der Funktionen bei der Inbetriebnahme ist mit allerdings zu riskant (weil zeitintensiv). Daher versuche ich immer im Vorfeld möglichst viel abzufangen und durch Tests zu bestätigen. Das verschafft dann den Vorteil, dass man die Architektur mit größerer Sicherheit definieren kann und das Debuggen idealer-weiße ganz entfällt.



Beim Online-Test sehe ich aktuell auch noch das Thema. Wenn ich selbst ein Programm schreibe, dann bin ich mit den Eigenschaften und Methoden vertraut. Komme ich als Fremder / Instandhalter an ein OOP-Programm dann ist es (für mich) schwer die Abhängigkeiten zu finden.
Wenn ich eine Anlage überhaupt nicht kenne, dann suche ich vom Aktor rückwärts bis ich die fehlenden Bedingungen finde. Und bei dieser Vorgehensweise tu ich mich bei OOP schwer.


----------



## ducati (29 Juli 2022)

Blockmove schrieb:


> Komme ich als Fremder / Instandhalter an ein OOP-Programm dann ist es (für mich) schwer die Abhängigkeiten zu finden.
> Wenn ich eine Anlage überhaupt nicht kenne, dann suche ich vom Aktor rückwärts bis ich die fehlenden Bedingungen finde. Und bei dieser Vorgehensweise tu ich mich bei OOP schwer.


Wenn man den Programmierstil nicht schnell durchschauen kann, führt jede Änderung/Erweiterung welche nicht durch den ursprünglichen Programmierer gemacht wird, zur parallelen Einführung eines zweiten Programmierstils in der gleichen Steuerung...


----------



## SPS-Bitschubser (29 Juli 2022)

Bißchen out off topich....
Was ich mich frage was sind die Vorteile von OOP zu der jetzigen Programmierung?
Wie lange dauert Änderungen? Richtig Dokumentieren etc.
Wie schaut es aus mit der Migration auf andere Systeme? 
S5 AUF s7 AUF TIA...
Meiner Meinung  nach setzen die Firmen auf OOP die wo die letzten 20 Jahre keine richtigen Schnittstellen zur Visualisierung geschaffen haben. 
Ähnlich ca. Das industrie 4.0 Thema. Nach 15 Jahren meinen manche Firmen könnte alles besser machen als andere andern die das schon 20 jahre davor umgesetzt haben.


----------



## Blockmove (30 Juli 2022)

@SPS-Bitschubser 

Vorneweg zum Verständnis:
Richtige OOP gibt es bei Siemens bislang eigentlich nicht.
Multiinstanz kann man vielleicht als Vorstufe betrachten.
Codesys ist hier ein gutes Stück weiter und hat das OOP-Konzept deutlich weiter umgesetzt.
Du hast hier z.B. Eigenschaften, Methoden, Interfaces, Vererbung ...
Das hat durchaus Vorteile für den Programmierer. Du bekommst ein sehr klar strukturiertes Programm mit guter Lesbarkeit.
Visu, Überwachung und Diagnose lassen sich gut und ohne viel Aufwand integrieren. Der Programmieraufwand sinkt deutlich.

Was aber jetzt noch nicht so ausgereift ist, sind die Tools für Inbetriebnahme und Online-Fehlersuche.
Bei S5 konntest du auf Adressebene Fehler suchen. Hast du die beteiligten E/A Adressen gekannt, konntest du dich durchhangeln.
Bei S7, TIA, Codesys 2.x kamen dann schon Instanzen dazu. Wenn jemand unsauber programmiert und schlecht dokumentiert, dann wird's schwierig. Bei Codesys 3.x kommen Methoden und Eigenschaften dazu. Eigentlich ist das im Prinzip noch eine weitere Abstraktionsschicht, die noch weiter von der Hardware weg ist. 

Um es etwas mit Siemens zu vergleichen:
Bei S7-Classic war der Zugriff auf Instanz-Daten eigentlich schlechter Stil.
Mit TIA hat sich das geändert. Zuerst wurden HMI-Daten Bestandteil der Instanzen.
Mittlerweile habe ich schon FBs gesehen, bei denen nicht mehr über die Schnittelle (In, Out, InOut) zugegriffen wird, sondern direkt in den Static-Bereich geschrieben wird. OK die Querverweisfunktionen von TIA sind nun deutlich besser, aber als Instandhalter muss man mit sowas erstmal zurecht kommen.

Schau mer mal was die Entwicklung noch bringt  

Gruß
Blockmove


----------



## holgermaik (30 Juli 2022)

Ich denke OOP wird sich in der klassischen Anlagen- / Maschinensteuerung nicht durchsetzen.
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.
Die Ersparnis beim Programmieren zahlt der Endkunde doppelt & dreifach drauf.


----------



## Blockmove (30 Juli 2022)

@holgermaik
Ich sehe es nicht so pessimistisch.
Es hängt ganz viel an den Tools / der Entwicklungsumgebung.
Mit einem vernünftigen Online Objektbrowser und guten Online-Status kann es schon was werden


----------



## rostiger Nagel (30 Juli 2022)

holgermaik schrieb:


> Die Ersparnis beim Programmieren zahlt der Endkunde doppelt & dreifach drauf.


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.


----------



## Biiebs (30 Juli 2022)

Blockmove schrieb:


> Und @Biiebs meint hier wirklich die Möglichkeiten von Codesys / Twincat und nicht die vergleichsweise einfachen Siemens Multiinstanzen.


Wir unterscheiden hier einfach 2 komplett unterschiedliche Welten mit Siemens und Codesys / Twincat und deren Werkzeuge, aber die Thematik wird im Forum ja schon Jahrelang diskutiert . Und ich mein in meinem Post auch nur die Codesys / Twincat Welt. 


Blockmove schrieb:


> Beim Online-Test sehe ich aktuell auch noch das Thema. Wenn ich selbst ein Programm schreibe, dann bin ich mit den Eigenschaften und Methoden vertraut. Komme ich als Fremder / Instandhalter an ein OOP-Programm dann ist es (für mich) schwer die Abhängigkeiten zu finden.
> Wenn ich eine Anlage überhaupt nicht kenne, dann suche ich vom Aktor rückwärts bis ich die fehlenden Bedingungen finde. Und bei dieser Vorgehensweise tu ich mich bei OOP schwer.





holgermaik schrieb:


> Ich denke OOP wird sich in der klassischen Anlagen- / Maschinensteuerung nicht durchsetzen.
> 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.


Ihr habt zum Teil recht, aber ist das aktuell nicht egal ob jetzt in "klassischer" Programmierung oder OOP? Wenn ein Inbetriebnehmer das Programm und die Strukutur nicht kennt, ist leider der Weg sehr mühselig von unterster Aktor/Sensorebene sich bis nach oben durchzuarbeiten. Gegenüberstellen würd ich es eher so:

Klassische Programmierung:
* Je nach Strukturt / Architektur und Programmiersprache (AWL, FUP,...) kann aber muss das Programm nicht unbedingt leserlich sein. Es kommt hier ebenso auf die Programmierskills des Entwicklers an (Spaghetticode ist genauso unübersicht)
* Debugging / IBN ist aufjedenfall machbar, da alles sich über globale Variablenlisten oder Funktionsbausteinen geschieht, wodurch der aktuelle Beobachtungswert immer verfügbar ist. (Aber auch hier gilt... reine Funktionen haben ebenfalls kein Gedächtnis, also auch keinen Beobachtungswert)

OOP:
* Je nach Struktur / Architektur kann es zu erheblichen Zeitersparnis in der Entwicklung der Software kommen, da durch einige Prinzipien (Vererbung etc.) einiges an Quellcode eingespart werden kann und dadurch, je nach einwandfreier Dokumentation, das Programm um ein vielfaches kleiner und übersichtlicher wirkt.
* Der Vorteil liegt hierbei ebenfalls bei der Skalierbarkeit der Software, da hier im Gegensatz zu dauerhaftem IN_OUT durchgeschleife, so gut wie keine Abhängigkeiten zwischen den einzelnen Bausteinen besteht, was einen erhebliche Zeitersparnis bei einer Erweiterung zur Folge hat (Vorausgesetzt die Basisstruktur stimmt)
* Der Nachteil liegt hier eben bei der Inbetriebnahme der Anlage, da wir hier Methoden, Eigenschaften und Interfaces benutzen, die im Gegensatz zur Basisklasse (Bausteininstanz), genauso wie Funktionen kein Gedächtnis besitzen und der aktuelle Beobachtungswert mit "???" angezeigt wird. _Und genau das würde ich hier gerne etwas genauer analysieren ob es hier nicht Möglichkeiten gibt wie man in diesem Use-Case der Inbetriebnahme dieses Problem lösen könnte.  _

Mir ist bekannt, dass einige größere Firmen und  Hersteller schon komplett auf OOP umgestellt haben, wäre hier jedenfalls mal interessant zu wissen, wie diese das Problem in den Griff bekommen.

_(Ich weiß OOP lässt schnell die Möglichkeit zum Abschweifen _


____
Offtopic:

Da hier die OOP Thematik doch sehr viel Interpretationsspielraum zulässt und einige doch etwas interessierter der Thematik entgegen schweifen. Hätte ich mal den Vorschlag, was haltet ihr davon, wenn wir einfach mal gemeinsam Post erstellen, indem wir evtl. mal die OOP Thematik, speziell in der SPS-Welt, in einem "FAQ / Tutorial / Ansätze" und vllt. Beispielprojekt auf klassischer Programmierung und dem versch. OOP Ansätze (z.B. Vererbung, Dekoration u. Delegation, Design Pattern) entgegen stellen um hier dem ein oder anderen in diese Thematik den Sprung zu erleichtern? Vllt. wird dem ein oder anderen auch etwas klarer was die Vorteile und Nachteile hierüber sind? 

(Die Idee hiervon kommt eigentlich daher, da hier im Forum, sowie im Codesys-Forum, jeder mal den Sprung in Richtung wagen möchte, die Beiträge hierfür jedoch nur in einer sehr geringer Anzahl vorhanden sind und das OOP Thema durch fehlendes Wissen wieder sein gelassen wird. In anderen Sprachen funktionieren diese Prinzipien ja auch. Klar kann dies nicht 1:1 auf die SPS-Welt portiert werden, aber genau hier ist ja das Problem, dass viele nicht lösen können/wollen)


----------



## ducati (30 Juli 2022)

Biiebs schrieb:


> Wenn ein Inbetriebnehmer das Programm und die Strukutur nicht kennt, ist leider der Weg sehr mühselig von unterster Aktor/Sensorebene sich bis nach oben durchzuarbeiten.


Dann ist das ganze für die Industrieautomatisierung ungeeignet bzw. gaaanz unsauberer Programmierstil...



Biiebs schrieb:


> Programmierskills des Entwicklers an (Spaghetticode ist genauso unübersicht)


naja... solange der code nicht total verworren ist, kann man bei Spaghetticode zumindest mal hinten was anfügen 



Biiebs schrieb:


> (Aber auch hier gilt... reine Funktionen haben ebenfalls kein Gedächtnis, also auch keinen Beobachtungswert)


Also bei Siemens kann man FCs online beobachten...



Biiebs schrieb:


> OOP:
> * Je nach Struktur / Architektur kann es zu erheblichen Zeitersparnis in der Entwicklung der Software kommen, da durch einige Prinzipien (Vererbung etc.) einiges an Quellcode eingespart werden kann und dadurch, je nach einwandfreier Dokumentation, das Programm um ein vielfaches kleiner und übersichtlicher wirkt.
> * Der Vorteil liegt hierbei ebenfalls bei der Skalierbarkeit der Software, da hier im Gegensatz zu dauerhaftem IN_OUT durchgeschleife, so gut wie keine Abhängigkeiten zwischen den einzelnen Bausteinen besteht, was einen erhebliche Zeitersparnis bei einer Erweiterung zur Folge hat (Vorausgesetzt die Basisstruktur stimmt)


wieso und warum spar ich denn da soviel Zeit gegenüber einer Ordentlichen Struktur mit mehrfach verwendbaren Bausteinen beim Siemens???

Ich stell mir so grad Supermonsterspezialbausteine vor, welche dann aber trotzdem bei ner neuen Anlage nicht das abdecken, was ich grade brauch...

Wir haben einen sehr schlanken Programmierstil mit sehr rudimentären Grundbausteinen, welche aber dafür immer passen, schon seit Jahrzehnten... Die Spezialsachen werden drumherum programmiert...

Ich hab schon viel gesehn, aber der Programmierstil in meiner aktuellen Firma ist das, was mir in den letzten 30 Jahren am besten gefallen hat...


----------



## ducati (30 Juli 2022)

Blockmove schrieb:


> Vorneweg zum Verständnis:
> Richtige OOP gibt es bei Siemens bislang eigentlich nicht.
> Multiinstanz kann man vielleicht als Vorstufe betrachten.
> Codesys ist hier ein gutes Stück weiter und hat das OOP-Konzept deutlich weiter umgesetzt.
> ...


kann man denn in diesen ganzen Eigenschaften, Methoden, Interfaces, Vererbung irgendwas im laufenden Betrieb also stoßfrei und ohne Aktualdatenverlust ohne CPU Stopp Ändern/Erweitern? Wenn Nein, dann fällt das für uns sowieso schon raus...

Das ist beim Siemens mit den Multiinstanzen ja schon ein No-Go... erstrecht beim TIA...


----------



## ducati (30 Juli 2022)

Biiebs schrieb:


> Da hier die OOP Thematik doch sehr viel Interpretationsspielraum zulässt und einige doch etwas interessierter der Thematik entgegen schweifen. Hätte ich mal den Vorschlag, was haltet ihr davon, wenn wir einfach mal gemeinsam Post erstellen, indem wir evtl. mal die OOP Thematik, speziell in der SPS-Welt, in einem "FAQ / Tutorial / Ansätze" und vllt. Beispielprojekt auf klassischer Programmierung und dem versch. OOP Ansätze (z.B. Vererbung, Dekoration u. Delegation, Design Pattern) entgegen stellen


ja gerne...


----------



## ducati (30 Juli 2022)

rostiger Nagel schrieb:


> 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 (30 Juli 2022)

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 (30 Juli 2022)

Blockmove schrieb:


> 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 (30 Juli 2022)

ducati schrieb:


> 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 (30 Juli 2022)

@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   



ducati schrieb:


> 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 (30 Juli 2022)

Biiebs schrieb:


> 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 (30 Juli 2022)

ducati schrieb:


> 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 (8 August 2022)

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 (15 August 2022)

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 (26 August 2022)

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 (26 August 2022)

holgermaik schrieb:


> 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 (26 August 2022)

Gleichrichter1 schrieb:


> 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 (26 August 2022)

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 (26 August 2022)

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


----------



## ducati (26 August 2022)

Gleichrichter1 schrieb:


> 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 (26 August 2022)

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 (26 August 2022)

ducati schrieb:


> 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


----------

