# TC3: Wann nutzt Ihr Methoden und wann "nur" den FB



## oliver.tonn (29 Januar 2021)

Hallo,
ich weiß, dass Folgende könnte in einem Religionskrieg ausarten.
Ich möchte mal wissen wann Ihr Methoden nutzt, bzw. die Nutzung für sinnvoll haltet und wann den "nackten" FB. In bin jetzt niemand der unbedingt objektorientiert arbeiten muss, aber wenns hilft, warum nicht.
Ich erstelle gerade ein paar FBs die das Verhalten verschiedener Hardwarekomponenten nachbilden sollen. Einer zum Beispiel das eines Ventils. Bei der Instanziierung lege ich über FB_INIT den Typ (z.B. Monostabil ohne Rückmeldung) fest.
Die Funktionalität (öffnen, schließen, usw.) kann man ja jetzt alles in den FB direkt packen oder man erstellt für jede Funktionalität eine Methode, wobei es da schon wieder schwierig wird mit dem einen Rückgabewert, dann müsste man für jede Methode eine Struktur anlegen mit den möglichen Rückgabewerten oder einen für alle Methoden.
Wie würdet Ihr das machen und warum?


----------



## Larry Laffer (29 Januar 2021)

Hallo Oliver,
ich bin jetzt nicht der Beckhoffer - somit hätte ich erstmal die Frage an dich worin sich für dich Methoden und FB unterscheiden ...
Kann man in TwinCat innerhalb eines FB (also Klasse ?) verschiedene Methoden deklarieren ?

Ich könnte mir vorstellen, dass sich diese Frage auch für andere stellt ... 

GrußLarry


----------



## georg28 (29 Januar 2021)

Wir machen dass so, der FB Aufruf klassisch Case Ablauf, aber wohin in welchen Step der Case Nummern gesprungen wird, wird innerhalb von Methoden des zugehörigen FB zugewiesen. Eventuell werden in den Methoden noch Parameter beim Aufruf gesetzt, z.B. Sollposition, Geschwindigkeit etc.
Ist halt anders wie wenn man Siemens macht. Das ist schon übersichtlich und eine Art wie etwas Objektorientierung in der Automation doch gut eingesetzt werden kann. Wir haben auch bisher 1 Interface im Einsatz, aber das ist echt mehr Spielerei. Vererbung oder Abstract_FB oder andere Sachen der Objektorientierung benutzen wir nicht und denke ich, werden auch nicht benutzt werden.
Wobei sich für mich der Einsatz von Interfaces in der Codesys Welt nicht so ganz erschließt.
In der Hochsprachenwelt ein gutes Feature das man sich echt mal anschauen sollte, aber in der SPS Welt.
Online Beobachtung von Bausteinen mit Interfaces ist nicht so einfach oder ich mache da etwas falsch


----------



## JSEngineering (29 Januar 2021)

Hallo,

ich habe mich noch nicht mit OOP in CoDeSys beschäftigt, aber gerade Dein Beispiel mit dem Ventil würde mich einladen, das mit Methoden zu erledigen.

Denn dann kann ich vermutlich auch Methoden überladen. Ich könnte also eine Methode Open() machen und eine Methode Open(p:=50.0). Über die Vererbung würde ich möglicherweise die verschiedenen Ventiltypen abbilden: Monostabil offen/monostabil geschlossen/bistabil/variabel/ mit Dauersignal/Impulssteuerung/Analogsignal jeweils mit einem Endschalter/zwei Endschaltern/Analogsignal und den Endschaltern als NC oder NO..... da gibt es so viele schöne Varianten.

Wenn man das alles an einem FB parametriert, dann hat man einen FB mit 30 Parametern, von denen aber nur 8 effektiv genutzt werden.
Das ist bei einer Anzahl X an Ventilen entsprechend Parametrieraufwand.

Über die OOP würde sich das sicherlich deutlich vereinfachen lassen.

An sich sind ja Methoden da, um zu kapseln: Ich kann von außen nicht auf die Attribute zugreifen. Kann ich mit einem FB auch erreichen, so lange ich mir selbst diese Grenzen auferlege.
Interessant wird es dann, wenn andere damit weiter arbeiten müssen und ggf. wenn ich mit Bibliotheken arbeiten möchte, die ggf. sogar geschützt sein sollen. Dann kann ich natürlich damit den Zugriff auf Attribute verhindern, die eventuell unangenehme Folgen haben. Wo z.B. jemand versucht, an einer Überwachung vorbei etwas zu erledigen.

Also für mich würde es einen Vorteil bringen, wenn 

der Code hinterher übersichtlicher ist
der Code wiederverwendbar sein soll und ggf. automatische Generierung dahinter steht: Parametrieraufwand
anderen damit der Code leichter verständlich wird
ich wichtige Dinge tatsächlich kapseln muß/will

Gruß
    Jens


----------



## georg28 (29 Januar 2021)

Bei uns sind es auch Softwareteile die immer wieder verwendet werden.
Aber Methoden Überschreiben würde ich mir schon schwer überlegen.
Irgendwann kann es sehr unübersichtlich werden.
Hier machen dann Vielleicht Interfaces wieder mehr Sinn
Siehe
https://www.sps-forum.de/codesys-un...ogrammieren.html?highlight=interfaces+Codesys


----------



## StructuredTrash (29 Januar 2021)

Ich habe mir eine einfache Grundregel auferlegt: Eine Methode muss ihre Aufgabe mit einem einzigen Aufruf komplett erledigen. Alles, was mehrere Zyklen braucht oder gar permanent zyklisch aufgerufen wird, kommt in den FB. Methoden also nur für ereignisgesteuerte Dinge wie z. B. die Stellbefehlsübergabe an einen Antrieb bei einer Schrittketten-Transition.


----------



## oliver.tonn (29 Januar 2021)

Hallo Larry,


Larry Laffer schrieb:


> ich bin jetzt nicht der Beckhoffer - somit hätte ich erstmal die Frage an dich worin sich für dich Methoden und FB unterscheiden ...
> Kann man in TwinCat innerhalb eines FB (also Klasse ?) verschiedene Methoden deklarieren ?


Es ist tatsächlich so wie Du vermutest. Ein FB kann verschiedene andere Dinge enthalten, unter anderem Methoden. Aber auch Aktionen, dies sind vereinfacht ausgedrückt Methoden ohne eigene Variablen und Properties mit denen Werte gesetzt (Setter) und gelesen (getter) werden können. Man kann den FB aber auch ohne diese Dinge direkt nutzen.


----------



## oliver.tonn (29 Januar 2021)

Hallo Jens,


JSEngineering schrieb:


> ich habe mich noch nicht mit OOP in CoDeSys beschäftigt, aber gerade Dein Beispiel mit dem Ventil würde mich einladen, das mit Methoden zu erledigen.
> 
> Denn dann kann ich vermutlich auch Methoden überladen. Ich könnte also eine Methode Open() machen und eine Methode Open(p:=50.0). Über die Vererbung würde ich möglicherweise die verschiedenen Ventiltypen abbilden: Monostabil offen/monostabil geschlossen/bistabil/variabel/ mit Dauersignal/Impulssteuerung/Analogsignal jeweils mit einem Endschalter/zwei Endschaltern/Analogsignal und den Endschaltern als NC oder NO..... da gibt es so viele schöne Varianten.


Einer meiner Kunden hat die Vererbung genau für Ventile genutzt, allerdings meine ich ohne Methoden. Die verschiedenen Varianten wurden dann abgeleitet und der allgemeine Teil mit SUPER^() aufgerufen.


----------



## Larry Laffer (29 Januar 2021)

oliver.tonn schrieb:


> Ein FB kann verschiedene andere Dinge enthalten, unter anderem Methoden. Aber auch Aktionen, dies sind vereinfacht ausgedrückt Methoden ohne eigene Variablen und Properties mit denen Werte gesetzt (Setter) und gelesen (getter) werden können. Man kann den FB aber auch ohne diese Dinge direkt nutzen.



Naja ... das kenne ich von der .Net-Programmierung her ...
Dann müßte (oder könnte ?) ja auch die Überlagerung von Methoden (wie hier schon angesprochen) funktionieren. Ich weiß zwar jetzt im Augenblick hierfür kein Beispiel im Bereich SPS - wenn man allerdings den FB selbst überlagern könnte dann würde mir da schon etwas dazu einfallen ...


----------



## Larry Laffer (29 Januar 2021)

oliver.tonn schrieb:


> Einer meiner Kunden hat die Vererbung genau für Ventile genutzt, allerdings meine ich ohne Methoden. Die verschiedenen Varianten wurden dann abgeleitet und der allgemeine Teil mit SUPER^() aufgerufen.



Vererbung oder Interfaces könnte ich mir für "Standard-Bausteine" gut vorstellen - also z.B. ein FU- oder Servo-Baustein, der "von Aussen" für einen SEW-Regler genauso aussieht wie für einen Bosch-Rexroth - und natürlich in seiner Funktions-Umsetzung auch gleich funktioniert - aslo der eine Baustein 1:1 bei geänderter Perepherie gegen den anderen austauschbar ist ...


----------



## oliver.tonn (29 Januar 2021)

Larry Laffer schrieb:


> Vererbung oder Interfaces könnte ich mir für "Standard-Bausteine" gut vorstellen - also z.B. ein FU- oder Servo-Baustein, der "von Aussen" für einen SEW-Regler genauso aussieht wie für einen Bosch-Rexroth - und natürlich in seiner Funktions-Umsetzung auch gleich funktioniert - aslo der eine Baustein 1:1 bei geänderter Perepherie gegen den anderen austauschbar ist ...


Interfaces gibt es bei TC3 auch, allerdings ist mir nicht klar wofür die verwendet werden.


----------



## StructuredTrash (29 Januar 2021)

Larry Laffer schrieb:


> Vererbung oder Interfaces könnte ich mir für "Standard-Bausteine" gut vorstellen - also z.B. ein FU- oder Servo-Baustein, der "von Aussen" für einen SEW-Regler genauso aussieht wie für einen Bosch-Rexroth - und natürlich in seiner Funktions-Umsetzung auch gleich funktioniert - aslo der eine Baustein 1:1 bei geänderter Perepherie gegen den anderen austauschbar ist ...



So etwas habe ich für meine Antriebe gemacht, wobei meine Welt aus EtherCat CoE und dem CanOpen-Antriebsprofil DS402 besteht. Ich setze mittlerweile 5 verschiedene Antriebsfamilien ein, die zumindest auf dem Papier diesem Standard entsprechen, aber eben nur dort. Es gibt viele Detailunterschiede bei Verfügbarkeit oder Inhalt von I/O-Objekten. Ich habe dabei mehrere Lösungsansätze verfolgt:

Die Basisklasse enthält die Grundfunktionalität und ruft für die Detailunterschiede abstrakte Methoden auf, die von jedem konkreten Antriebs-FB überschrieben werden. Habe ich dann aber nicht gemacht, weil die Gesamtfunktionalität dadurch ziemlich "zerpflückt" wird und ein neuer Antrieb vielleicht wieder einen anderen Detailunterschied aufweist. Dann bräuchte ich nicht nur eine weitere Detailmethode in der Basisklasse, sondern müsste sie auch in allen bestehenden FBs nachrüsten.

Die Basisklasse enthält nur abstrakte Methoden. Dann müsste ich aber die komplette Funktionalität in jedem konkreten FB programmieren, obwohl sie doch weitgehend gleich ist. Als Fan der klassischen OOP mit Vererbung statt Interfaces hat mir der Gedanke auch nicht gefallen.

Schliesslich habe ich eine Basisklasse programmiert, die die komplette Funktionalität enthält, wofür ich den meist eingesetzten Antrieb zum Quasi-Standard erhoben habe. Die konkreten FBs brauchen dann "nur" ihre Funktion an diesen Standard anpassen. Im Wesentlichen tun sie das durch hin- und herüberseten zwischen ihren HW-I/Os und virtuellen I/Os der Basisklasse. Damit bleibt die Funktionalität in der Basisklasse gut lesbar, und die Anzahl der von den konkreten FBs zu überschreibenden Methoden hält sich in Grenzen.


----------



## StructuredTrash (30 Januar 2021)

oliver.tonn schrieb:


> Interfaces gibt es bei TC3 auch, allerdings ist mir nicht klar wofür die verwendet werden.



Interfaces sind für Programmierer, die zu faul sind, eine saubere Vererbungshierarchie zu entwickeln.
Im Ernst: Mann kann nicht die gesamte reale Welt durch Vererbung darstellen. Klassisches Beispiel ist die Basisklasse "Fahrzeug", von der die Klassen "Landfahrzeug" und "Wasserfahrzeug" abgeleitet werden. Was ist dann aber mit dem Amphibienfahrzeug? Das müsste vom Land- und vom Wasserfahrzeug erben. So eine Mehrfachvererbung ist sehr aufwändig, meines Wissens gibt es sie im kommerziellen Bereich nur bei C++. Die Interfaces wurden als einfache Alternative dazu eingeführt. Ein Objekt kann beliebig viele Interfaces haben, muss dann aber natürlich auch alle in den Interfaces enthaltenen Methoden implementieren. Damit kann man einem Pferd auch das Fahrrad fahren beibringen, wenn das später mal notwendig wird. Mit Vererbung wäre das schwierig, denn niemand wird auf die Idee kommen, Pferd und Fahrrad im gleichen Zweig einer Vererbungshierarchie unterzubringen.

In TC3 nutze ich Interfaces, um aus einer Hintergrundtask auf FBs in der Steuerungstask zugreifen zu können. Einem Interface ist es nämlich egal, ob der FB, auf den es zeigt, in einer anderen Task läuft. Da ein Interface den Zugriff auf den FB nur mit Methoden ermöglicht, kann man so auch den Zugriff von aussen auf die Daten beschränken, auf die zugegriffen werden darf.


----------



## Larry Laffer (30 Januar 2021)

Der Sinn von Interfaces (allerdings unter .Net) kann Reflektion sein. Über die Reflektion kann ich ein Interface finden ohne die Klasse dazu überhaupt zu kennen. Das habe ich untrer .Net zwar auch noch nicht so häufig gemacht - kann aber für Steuerelemente in einer Visualisierung ganz witzig sein ...

Vererbung ist dann wieder so ganz eigenes Ding. Erben kann ich ja nur von einer Klasse. Hier ist es wichtig (aus meiner Sicht), dass man nach Möglichkeit die Basisklasse so auswählt das man eben am Besten keine eingelagerten Methoden überschreiben muss sondern nur ergänzen ...
Ich hatte aber mal einen Mitarbeiter, der für Schrank die Basisklasse Stein genommen hat und das auch noch richtig gut fand - dabei gab es auch noch die Klasse Brett ...


----------



## georg28 (30 Januar 2021)

StructuredTrash schrieb:


> So etwas habe ich für meine Antriebe gemacht, wobei meine Welt aus EtherCat CoE und dem CanOpen-Antriebsprofil DS402 besteht. Ich setze mittlerweile 5 verschiedene Antriebsfamilien ein, die zumindest auf dem Papier diesem Standard entsprechen, aber eben nur dort. Es gibt viele Detailunterschiede bei Verfügbarkeit oder Inhalt von I/O-Objekten. Ich habe dabei mehrere Lösungsansätze verfolgt:.


Dies ist inzwischen eben auch mehr meine Welt, wobei bei mir eher Array of FB ein Thema ist da viele der gleichen FB mehrmals in der gleichen Maschine verwendet werden. Noch mehr ist objektorientierte Programmierung bei mir ein Thema für Software welche für die Visualisierung der Maschinen und dann Teile davon  in anderen Anwendungen eingesetzt werden kann. z. B. TCP Kommunikation


----------



## georg28 (30 Januar 2021)

Ich habe eher schon FBs gemacht die in der Siemens und Codes Welt zum Einsatz kamen. Da stellt sich dann der Einsatz dieser ganzen Features ohnehin nicht mehr die Frage, aber das ist ja hier auch nicht das Thema


----------



## wollvieh (30 Januar 2021)

Habt ihr mal an einer OOP Maschine im Produktionsbetrieb versucht, online Fehler zu finden? Man sieht nur Adressen und Pointer auf Speicherberiche, wenn man Inhalte sehen möchte, nur mit Breakpoint, d.h. die Maschine steht. Sehr geil. Vom Grundgedanken einer einfachen Programmiersprache entfernt man sich, aber das scheint grad trendy?


----------



## georg28 (30 Januar 2021)

wollvieh schrieb:


> Habt ihr mal an einer OOP Maschine im Produktionsbetrieb versucht, online Fehler zu finden? Man sieht nur Adressen und Pointer auf Speicherberiche, wenn man Inhalte sehen möchte, nur mit Breakpoint, d.h. die Maschine steht. Sehr geil. Vom Grundgedanken einer einfachen Programmiersprache entfernt man sich, aber das scheint grad trendy?



Genau und dann bei Beckhoff eine Safety Sps mitdabei, die geht dann weil das normale Programm nicht mehr läuft in Störung :TOOL:


Daher leichte objektorientierte Programmierung in der Sps ja, aber nicht zuviel


----------



## StructuredTrash (30 Januar 2021)

wollvieh schrieb:


> Habt ihr mal an einer OOP Maschine im Produktionsbetrieb versucht, online Fehler zu finden? Man sieht nur Adressen und Pointer auf Speicherberiche, wenn man Inhalte sehen möchte, nur mit Breakpoint, d.h. die Maschine steht. Sehr geil. Vom Grundgedanken einer einfachen Programmiersprache entfernt man sich, aber das scheint grad trendy?


Wenn man den OOP-Missionaren von Codesys und Beckhoff glaubt, ist das die Zukunft. Diese Herrschaften kommen vermutlich frisch von der Uni und haben noch nie eine IBN gemacht. Trotzdem halte ich die OOP-Erweiterungen durchaus für sinnvoll. Man muss sie halt mit Augenmass nutzen, und wenn man merkt, dass man es übertrieben hat, auch mal einen Schritt zurück gehen.


----------



## georg28 (31 Januar 2021)

Die Thematik hier erinnert mich sehr an Diskussionen in anderen Foren c vs. C++ da gibt es in der Embedded Welt haufenweise Grabenkämpfe. Aber da gibt es dann viele andere Dinge zu beachten die man als Sps Programmierer nicht kennt weil die Hersteller der Sps das machen. Aber mit Beckhoff könnte man selbst mit C++ ohne weiteres das Sps Programm machen. Hier ist Beckhoff echt sehr offen. Viele Möglichkeiten um an sein Ziel zu kommen. Aber einfacher wir es halt auch nicht unbedingt. Da ist seitens Siemens öfters der Richtige Weg vorgegeben Beckhoff ist seit neuestem sogar in der Linux Welt mit der CX Baureihe unterwegs. Dies soll noch auf die Leistungsstarken PCs übertragen werden.


----------



## Larry Laffer (31 Januar 2021)

StructuredTrash schrieb:


> Trotzdem halte ich die OOP-Erweiterungen durchaus für sinnvoll. Man muss sie halt mit Augenmass nutzen, und wenn man merkt, dass man es übertrieben hat, auch mal einen Schritt zurück gehen.


*ACK*
Augenmaß ist hier genau das Stichwort ...
Das von Wollvieh im Beitrag #17 dargestellte Szenario wäre auch für mich ein absolutes No-Go ...

Gruß
Larry


----------



## testor (31 Januar 2021)

wollvieh schrieb:


> Habt ihr mal an einer OOP Maschine im Produktionsbetrieb versucht, online Fehler zu finden? Man sieht nur Adressen und Pointer auf Speicherberiche, wenn man Inhalte sehen möchte, nur mit Breakpoint, d.h. die Maschine steht. Sehr geil. Vom Grundgedanken einer einfachen Programmiersprache entfernt man sich, aber das scheint grad trendy?



Also ich muss sagen, dass ich ziemlich viel mit den OOP-Elementen arbeite. Ich verstecke dabei allerdings viel in Bausteinen, die eh in einer verschlossenen Bibliothek sind. Im Anwendungsprogramm nutze ich eigentlich fast auschließlich FUP/SFC. Insgesamt ergeben sich daher viele Vorteile was z. B. die "Cleanheit" des Anwendungsprogramms, die Analysemöglichkeiten, hohe Flexibilität und auch im Bereich der Codegenerierung.  Ich stimme dir bei dem was du schreibst allerdings vollkommen zu:
- Wieso werden in Methoden deklarierte Variablen im Online View mit einem Wert "???" angezeigt?
- Wieso kann man in Referenzinstanzen springen, in Interfacepointer aber nicht?
- Vererbungsketten lassen sich einfach schlecht nachvollziehen (Ich lasse Vererbung deswegen generell Weg oder limitiere sie auf eine Vererbungsstufe)
- etc.
Allerdings hat das weniger etwas mit der Anwendung der durch die OOP-Elemente geschaffenen Möglichkeiten zu tun, sondern mit den Möglichkeiten der Entwicklungsumgebung. Es ist als Gesamtkonzept einfach nicht hinreichend umgesetzt.

Zur Eingangsfrage von Oliver, ich nutze Methoden wie folgt:
- In Bibliotheksbausteinen nutze ich oftmals klassische OOP Design patterns (Command, Observer etc.). Hier nutze ich Methoden mit Interfaces entsprechend der Pattern.
- Mein Programmiertemplate sieht vor auch die "Anwendungs"-Module (Modulstruktur im Stil der ISA88 ) mit Methoden zu strukturieren. Dabei gibt es zyklisch aufgerufene Methoden die z. B. unterlagerte Module aufrufen, Interlocks verarbeiten etc. Dann gibt es auch nicht zyklisch aufgerufene Methoden, die in der Regel die von dir angesprochenen Funktionen umsetzen (open/close, drive to etc.). Diese Methoden können auch von extern aufgerufen werden (z. B. über Interfaces). Ich limitiere das allerdings nicht wie z. B. StructuredTrash geschrieben hat auf einen Zyklus. Die Methoden werden aufgerufen und geben dann eine Rückmeldung das diese fertig sind.


----------



## StructuredTrash (2 Februar 2021)

testor schrieb:


> - Wieso werden in Methoden deklarierte Variablen im Online View mit einem Wert "???" angezeigt?


Weil sie temporär sind und nur während des Methodenaufrufs auf dem Stack existieren. Ist halt genauso wie bei Funktionen. Allerdings kann man Methodenvariablen mittlerweile als VAR_INST deklarieren, um sie statisch an den FB anzuhängen. Habe ich selbst aber noch nicht ausprobiert.


testor schrieb:


> - Wieso kann man in Referenzinstanzen springen, in Interfacepointer aber nicht?


Da wurde offenbar nachgebessert. Ich bin gerade am Basteln (4024.12). Ich kann online ein Interface aufklappen, dann wird der Instanzname des FBs angezeigt, auf den das Interface zeigt. Und den kann ich auch wieder aufklappen und sehe die Variablen des FBs.


testor schrieb:


> - Vererbungsketten lassen sich einfach schlecht nachvollziehen


*ACK*
In Borland Pascal (Gott hab es selig) gab es einen Objektbrowser, mit dem man zu jedem Vorgängerobjekt einer Vererbungshierarchie gelangen konnte. Würde CodeSys/TwinCat auch gut zu Gesicht stehen.


----------



## Frank_Martin (13 August 2021)

Vielleicht ist es ja vielen SPS-Programmierern nicht aufgefallen. Die Programmierung hat sich seit der S5 weiter entwickelt. Schon mit der S7 hat sich sogar Siemens in eine Richtung entwickelt wo CODESYS schon lange ist. Ob einem gefällt oder nicht. Die Modularisierung geht weiter und OOP ist State of the Art. Wird es auch in der Automatisierungstechnik. Vielleicht auch ohne IEC 61131.
Der Vorteil liegt bei der Rationalisierung der Programmierung(Kosten).
Der Trend geht Richtung KI die programmiert. Durchgetestet Module brauchen weniger Fehlersuche. So einfach ist das. Auch wenn man es nicht mag, die Zukunft findet statt. 😉


----------



## Ralle (13 August 2021)

Frank_Martin schrieb:


> Vielleicht ist es ja vielen SPS-Programmierern nicht aufgefallen. Die Programmierung hat sich seit der S5 weiter entwickelt. Schon mit der S7 hat sich sogar Siemens in eine Richtung entwickelt wo CODESYS schon lange ist. Ob einem gefällt oder nicht. Die Modularisierung geht weiter und OOP ist State of the Art. Wird es auch in der Automatisierungstechnik. Vielleicht auch ohne IEC 61131.
> Der Vorteil liegt bei der Rationalisierung der Programmierung(Kosten).
> Der Trend geht Richtung KI die programmiert. Durchgetestet Module brauchen weniger Fehlersuche. So einfach ist das. Auch wenn man es nicht mag, die Zukunft findet statt. 😉


Ja und vielen Dank für die Belehrung.
Wir sind nicht ganz so doof, wie du vielleicht denkst und wir hatten diese Diskussionen hier im Forum auch schon häufiger.
Ich kenne mehr Maschinen mit "OOP-Ansatz", die überhaupt nicht gut liefen, als schlechte "normal" "s5-like" (Das sollen Ironie-Tags sein :  ) programmierte Maschinen, die überhaupt nicht gut liefen. Und was die Zeitersparnis betrifft, das muß mir erst mal jemand vorführen, mit einer halbwegs großen Sondermaschine. Also; dann programmiere doch OOP, ist ja die Zukunft, ich hab da nichts dagegen. Ich komm dann, schmeiß den Scheiß raus und bringe das Teil zum laufen, wie so oft!!!


----------



## DeltaMikeAir (13 August 2021)

Frank_Martin schrieb:


> Der Trend geht Richtung KI die programmiert.


Kannst du hier mal Beispiele nennen.


----------



## Blockmove (13 August 2021)

Frank_Martin schrieb:


> Vielleicht ist es ja vielen SPS-Programmierern nicht aufgefallen. Die Programmierung hat sich seit der S5 weiter entwickelt. Schon mit der S7 hat sich sogar Siemens in eine Richtung entwickelt wo CODESYS schon lange ist. Ob einem gefällt oder nicht. Die Modularisierung geht weiter und OOP ist State of the Art. Wird es auch in der Automatisierungstechnik. Vielleicht auch ohne IEC 61131.
> Der Vorteil liegt bei der Rationalisierung der Programmierung(Kosten).
> Der Trend geht Richtung KI die programmiert. Durchgetestet Module brauchen weniger Fehlersuche. So einfach ist das. Auch wenn man es nicht mag, die Zukunft findet statt. 😉


Mit deinen Marketing-Buzzwords kannst du sofort bei jedem agilen I4.0-Startup anfangen.

Durchgetestete Module ... Was soll jetzt daran neu sein?
Selbst wenn du jetzt mit Unit-Tests kommst, so ist auch das in der SPS-Welt bekannt.
Und du wirst lachen, ich hab davon schon vor 30 Jahren bei der S5 gehört.
Code-Generatoren, Programmerstellung aus Excel oder CAD-Daten. Auch nicht neu.
Lustigerweise war's sogar mit S5 einfacher als heute mit Codesys oder TIA.

Und eine vielleicht für dich neue Erkenntnis:
Rationalisierung der Programmierung ist gar nicht wichtig.
Eine Anlage oder Maschine wird im Büro programmiert. Da hat man Zeit.
Viel wichtiger ist Wartbarkeit, klar strukturierter Aufbau der Software und vorallem einfache Fehlersuche.
Und da ist nicht KI, sondern menschliche Intelligenz gefragt.

Achja:
Ich verwende OOP bei Codesys, wo es sinnvoll ist.


----------



## Frank_Martin (13 August 2021)

DeltaMikeAir schrieb:


> Kannst du hier mal Beispiele nennen.


Sondermaschinen gehören sicherlich nicht dazu.


----------



## DeltaMikeAir (13 August 2021)

Frank_Martin schrieb:


> Sondermaschinen gehören sicherlich nicht dazu.


Und was ist jetzt dein Beispiel


----------



## DeltaMikeAir (13 August 2021)

Frank_Martin schrieb:


> Sondermaschinen gehören sicherlich nicht dazu.


Warum der Sondermaschinenbau nicht. Du schreibt das eine KI programmiert. Der KI sollte es doch egal sein ob es eine Serienmaschine ist oder ein Sondereinzelstück. Vielleicht erklärst du uns das mal etwas genauer


----------



## Blockmove (13 August 2021)

Frank_Martin schrieb:


> Sondermaschinen gehören sicherlich nicht dazu.


Doch der gehört dazu..
Ich kenne Forschungsprojekte für den Bereich Sondermaschinenbau und Intralogistics.
Intralogistics ist schon recht fortgeschritten, Sondermaschinenbau naja


----------



## Frank_Martin (13 August 2021)

Blockmove schrieb:


> Mit deinen Marketing-Buzzwords kannst du sofort bei jedem agilen I4.0-Startup anfangen.
> 
> Durchgetestete Module ... Was soll jetzt daran neu sein?
> Selbst wenn du jetzt mit Unit-Tests kommst, so ist auch das in der SPS-Welt bekannt.
> ...


Ihre Haltung kenne ich auch schon 30 Jahre. Damals bei Opel Bochum. Selbst 2008 hat man mir versichert, dass sich nie etwas ändern wird. 2012 war das Werk zu und heute ist alles weg. Wer sich nicht bewegt, wird bewegt.


----------



## DeltaMikeAir (13 August 2021)

Frank_Martin schrieb:


> Ihre Haltung kenne ich auch schon 30 Jahre. Damals bei Opel Bochum. Selbst 2008 hat man mir versichert, dass sich nie etwas ändern wird. 2012 war das Werk zu und heute ist alles weg. Wer sich nicht bewegt, wird bewegt.


Werden die gestellten Fragen noch beantwortet oder ist das ein Opel-Werk geschlossen wurde jetzt deine Begründungsgrundlage?


----------



## Frank_Martin (14 August 2021)

DeltaMikeAir schrieb:


> Werden die gestellten Fragen noch beantwortet oder ist das ein Opel-Werk geschlossen wurde jetzt deine Begründungsgrundlage?


Nö danke, die Hausherren wissen ja schon alles. Da muss man nicht reden. Schönes Wochenende.


----------



## Frank_Martin (14 August 2021)

Ralle schrieb:


> Ja und vielen Dank für die Belehrung.
> Wir sind nicht ganz so doof, wie du vielleicht denkst und wir hatten diese Diskussionen hier im Forum auch schon häufiger.
> Ich kenne mehr Maschinen mit "OOP-Ansatz", die überhaupt nicht gut liefen, als schlechte "normal" "s5-like" (Das sollen Ironie-Tags sein :  ) programmierte Maschinen, die überhaupt nicht gut liefen. Und was die Zeitersparnis betrifft, das muß mir erst mal jemand vorführen, mit einer halbwegs großen Sondermaschine. Also; dann programmiere doch OOP, ist ja die Zukunft, ich hab da nichts dagegen. Ich komm dann, schmeiß den Scheiß raus und bringe das Teil zum laufen, wie so oft!!!


Und Verzeihung, ich wollte Ihnen weder auf den Schwanz treten, noch Sie belehren. Aber scheinbar fühlten Sie sich angesprochen. 🤷🏻‍♂️


----------



## Blockmove (14 August 2021)

@Frank_Martin 

Zu meinen Aufgaben gehört unter Anderem auch I4.0.
Ich kenne also neue Technologien und neue Trends im Bereich Steuerungstechnik und Automatisierung.
Und das nicht in einer kleiner Klitsche sondern in einem Kornzern mit 60000 Mitarbeitern und knapp 50 Fabriken weltweit.

Unsere Neuanlagen haben alle Cloud-Anbindung.
Wir haben Teams für Big-Data und KI.
Sowohl für unsere Produkte, als auch für unsere Fabriken

Ich denke, dass ich über die technischen Möglichkeiten durchaus im Bilde bin.
Was jedoch wichtiger ist als die ganzen Zukunftsvisionen, ist eine stabile, technisch beherrschbare Fertigung mit all ihren Randbedingungen, wie z.B. Bedien- und Instandhaltungspersonal.
Nur wenn in den Fabriken Geld verdient wird, kann mein Gehalt bezahlt werden.
Beispiel:
Normalerweise sind unsere Maschinen untereinander vernetzt und tauschen Informationen und Stati über Netzwerk aus.
Wir haben jedoch Standorte, die noch klassische Relais-Schnittstellen wollen, weil die Instandhaltung nicht mit Netzwerk zurecht kommt.
An diesen Standorten sind auch kaum Roboter installiert, dafür jede Menge manuelle Einrichtungen.
Wir verdienen dort aber genauso Geld und die Fabriken sind wirtschaftlich.

An deutschen Standorten lösen wir z.B. die ersten alten 1500er Steuerungen ab und ersetzten sie durch neue leistungsfähigere Steuerungen.
Hintergrund ist die Umstellung auf OPC UA als Kommunikationsprotokoll. Und auch hier muss die Qualifikation der Instandhaltung berücksichtigt werden. Wir haben leider erst vor ein paar Jahren mit einem I4.0 Qualifizierungsprogramm für Instandhalter begonnen.
Es ist zwar in mancher Hinsicht ein "Henne - Ei - Problem", aber letztlich kann ich neue Technologien erst einsetzten, wenn sie beherrschbar sind und geeignete Werkzeuge zur Verfügung stehen.

Aus meiner Sicht hast du aktuell nur Buzzwords ohne Hintergrund geliefert.
Sei doch bitte so nett und liefere mal ein paar Details zur KI-unterstützten SPS-Programmierung.


Gruß
Blockmove


----------



## Ralle (14 August 2021)

Frank_Martin schrieb:


> Und Verzeihung, ich wollte Ihnen weder auf den Schwanz treten, noch Sie belehren. Aber scheinbar fühlten Sie sich angesprochen. 🤷🏻‍♂️


Nein, das ist gar nicht das Problem. Aber ich liebe Leute, die in Themen reinkommen, mit ein paar Buzzwords um sich  werfen und dann meinen, als große Fachleute wahrgenommen werden zu müssen. Du klingst nach Unternehmensberatung, da werd ich halt allergisch 

@Blockmove 
Wir liefern i.d.R., ws unsere Kunden wünschen. Meißt bekommt man dann ohnehin einen gewissen Standard vorgeschrieben, an den man sich halten muß. Wenn das so ist, finde ich es besser, als so wischi-waschi-Anforderungen, die sich anschließend noch x Mal ändern. Daher ist es gut, wenn ein Kunde sich auch selbst mit diesen Dingen auseinandersetzt.  Arbeitet ihr auch mit OPC-UA Clients in der 1500-er. Das kommt mir irgendwie reichlich kompliziert vor in der Handhabung. Da muß man sicher ein paar Standards firmenseitig einführen oder?  Lohnt das, wenn man 1500-er untereinander verbinden will oder ist das eher für Fremdsysteme gedacht?


----------



## Frank_Martin (14 August 2021)

Das neue Factory Automation Studio von Grollmus geht ganz klar in diese Richtung.
Im Übrigen muss man nicht Beispiele für Entwicklungen bringen die in der Zukunft liegen. Beispiele lassen sich nur rückwärts gewandt sicher definieren. Bis dahin ist es wie in der Kirche. Glaube. Und Ich glaube daran, dass wir vor disruptiven Veränderungen stehen. Mit meinen 60 Jahren muss ich die zum Glück nicht mehr alle in der Praxis umsetzen, aber ich werde die nächsten 10 Jahre noch aktiv mit denen arbeiten die davon betroffen sind.


			https://www.grollmus.de/wp-content/uploads/SPS-MAGAZINAugust_2021-Factory-Automation-Studio-1.pdf


----------



## Frank_Martin (14 August 2021)

Ralle schrieb:


> Nein, das ist gar nicht das Problem. Aber ich liebe Leute, die in Themen reinkommen, mit ein paar Buzzwords um sich  werfen und dann meinen, als große Fachleute wahrgenommen werden zu müssen. Du klingst nach Unternehmensberatung, da werd ich halt allergisch


Gute Intuition. Chapeau.
Allerdings bin ich kein klassischer Unternehmensberater. Sonst wäre ich 25 Jahre alt, hätte noch nie eine Produktion von innen gesehen und noch nie eine Schraube festgezogen. Aber in der European Business School studiert.
Mit anderen Worten, ich unterscheide mich von einem Unternehmensberater dadurch das ich weiß wie es geht. Diese Allergie teile ich.

Zum Wochenende meinen Lieblings Beraterwitz:
Es war einmal ein _Schäfer_, der in einer einsamen Gegend seine *Schafe* hütete. Plötzlich tauchte in einer großen Staubwolke ein nagelneuer grauer Audi Quattro auf und hielt direkt neben ihm.

Der Fahrer, ein junger Mann in Brioni Anzug, Cerutti Schuhen, Ray Ban Sonnenbrille und einer YSL Krawatte steigt aus und fragt ihn: "Wenn ich errate, wie viele Schafe Sie haben, bekomme ich dann eins?" Der Schäfer schaut den jungen Mann an, dann seine friedlich grasenden Schafe (es ist eine große Herde), und sagt ruhig "In Ordnung".
Der junge Mann verbindet sein Notebook mit dem Handy, geht im Internet auf eine NASA-Seite, scannt die Gegend mit Hilfe seines GPS-Satellitennavigationssystems, öffnet eine Datenbank und 60 Excel Tabellen mit einer Unmenge Formeln. Schließlich druckt er einen 150seitigen Bericht auf seinem Hi-Tech-Minidrucker, dreht sich zu dem Schäfer um und sagt: 

"Sie haben hier exakt 742 Schafe."

Der Schäfer sagt "Das ist richtig, suchen Sie sich ein Schaf aus." Der junge Mann nimmt ein Schaf und lädt es in den Audi Quattro ein.
Der Schäfer schaut ihm zu und sagt: "Wenn ich Ihren Beruf errate, geben Sie mir das Schaf dann zurück?" Der junge Mann antwortet: "Klar, warum nicht." Der Schäfer sagt: "Sie sind Consultant einer Unternehmensberatung."
"Das ist richtig, woher wissen Sie das?" will der *Berater* wissen.
"Ganz einfach," erklärt der Schäfer,

"Erstens: kommen sie hierher, obwohl Sie niemand gerufen hat.
Zweitens: wollen Sie ein Schaf als Bezahlung haben dafür, dass Sie mir etwas sagen, was ich ohnehin schon weiß.
Drittens: haben Sie keine Ahnung von dem, was ich tue.
Und jetzt geben Sie mir meinen Hund zurück!"


----------



## Blockmove (14 August 2021)

Frank_Martin schrieb:


> Das neue Factory Automation Studio von Grollmus geht ganz klar in diese Richtung.
> Im Übrigen muss man nicht Beispiele für Entwicklungen bringen die in der Zukunft liegen. Beispiele lassen sich nur rückwärts gewandt sicher definieren. Bis dahin ist es wie in der Kirche. Glaube. Und Ich glaube daran, dass wir vor disruptiven Veränderungen stehen. Mit meinen 60 Jahren muss ich die zum Glück nicht mehr alle in der Praxis umsetzen, aber ich werde die nächsten 10 Jahre noch aktiv mit denen arbeiten die davon betroffen sind.
> 
> 
> https://www.grollmus.de/wp-content/uploads/SPS-MAGAZINAugust_2021-Factory-Automation-Studio-1.pdf



Sorry, erst kommst du mit Zukunft, KI, Programmierung jenseits der IEC61131 und nun mit Grollmus?
Was bitte ist daran KI?
Es handelt sich um einen Code Generator, der Templates nutzt.
Sowas gibt es seit Jahren, wenn nicht seit Jahrzehnten.
Schau dir mal z.B. Bosch Nexeed Control Plus an.


----------



## Blockmove (14 August 2021)

Ralle schrieb:


> Nein, das ist gar nicht das Problem. Aber ich liebe Leute, die in Themen reinkommen, mit ein paar Buzzwords um sich  werfen und dann meinen, als große Fachleute wahrgenommen werden zu müssen. Du klingst nach Unternehmensberatung, da werd ich halt allergisch
> 
> @Blockmove
> Wir liefern i.d.R., ws unsere Kunden wünschen. Meißt bekommt man dann ohnehin einen gewissen Standard vorgeschrieben, an den man sich halten muß. Wenn das so ist, finde ich es besser, als so wischi-waschi-Anforderungen, die sich anschließend noch x Mal ändern. Daher ist es gut, wenn ein Kunde sich auch selbst mit diesen Dingen auseinandersetzt.  Arbeitet ihr auch mit OPC-UA Clients in der 1500-er. Das kommt mir irgendwie reichlich kompliziert vor in der Handhabung. Da muß man sicher ein paar Standards firmenseitig einführen oder?  Lohnt das, wenn man 1500-er untereinander verbinden will oder ist das eher für Fremdsysteme gedacht?


Gegen den Client auf der 1500er habe ich mich jahrelang mit Händen und Füssen gewehrt.
Bislang war - wie du sagst - die Sache zu kompliziert.
Mit der neuen Firmware 2.9 und TIA 17 ändert sich das.
Von den 7 FBs sind nur noch 3 übrig und die Konfiguration und Diagnose soll auch einfacher sein.
Hab's aber noch nicht selbst getestet.
Nach meinem aktuellen Projekt will ich da mal nen Versuchsaufbau machen.
Gegenüber den bisherigen Verbindungen hat OPC UA schon viele Vorteile.


----------



## DeltaMikeAir (14 August 2021)

@Frank_Martin 

Wenn das Produkt von Grollmus deine besagte KI der Zukunft ist, dann hat sich für mich ein weiteres Gespräch erübrigt. Wie Dieter schon schrieb, Codegeneratoren gibt es schon lange. Ich nannte hier schon einmal die Logistiganlage vom Flughafen München mit >10.000 Antrieben. Das hat alles allerdings nichts mit KI zu tun sondern eine Software generiert einfach das was man ihr beigebracht hat was sie zu generieren hat.


----------



## Frank_Martin (14 August 2021)

Blockmove schrieb:


> Sorry, erst kommst du mit Zukunft, KI, Programmierung jenseits der IEC61131 und nun mit Grollmus?
> Was bitte ist daran KI?
> Es handelt sich um einen Code Generator, der Templates nutzt.
> Sowas gibt es seit Jahren, wenn nicht seit Jahrzehnten.
> Schau dir mal z.B. Bosch Nexeed Control Plus an.


Habe ich behauptet das sei KI?
Das steht „das geht in diese Richtung“ und es ging um Codegenerierung. Und ich würde es gerne beim „Sie“ belassen. Danke


----------



## Frank_Martin (14 August 2021)

DeltaMikeAir schrieb:


> @Frank_Martin
> 
> Wenn das Produkt von Grollmus deine besagte KI der Zukunft ist, dann hat sich für mich ein weiteres Gespräch erübrigt. Wie Dieter schon schrieb, Codegeneratoren gibt es schon lange. Ich nannte hier schon einmal die Logistiganlage vom Flughafen München mit >10.000 Antrieben. Das hat alles allerdings nichts mit KI zu tun sondern eine Software generiert einfach das was man ihr beigebracht hat was sie zu generieren hat.


Und im nächsten Step wird die Software immer mehr selbst übernehmen. Kann man glauben, muss man aber nicht.


----------



## DeltaMikeAir (14 August 2021)

Frank_Martin schrieb:


> Und im nächsten Step wird die Software immer mehr selbst übernehmen. Kann man glauben, muss man aber nicht.


Dann glauben "Sie" gerne daran, ich glaube schon daran dass sich in den kommenden 10 Jahren viel tun wird, dass diese genannte Firma dabei federführend ist bezweifle ich allerdings stark.


----------



## Frank_Martin (14 August 2021)

DeltaMikeAir schrieb:


> Dann glauben "Sie" gerne daran, ich glaube schon daran dass sich in den kommenden 10 Jahren viel tun wird, dass diese genannte Firma dabei federführend ist bezweifle ich allerdings stark.


Auch das ist wieder eine Aussage, die Sie mir in den Mund legen. Ich habe keine Aussage getroffen welche Rolle die Grollmus GmbH in der Zukunft haben wird. Warum auch. Ich habe ein eigenes Unternehmen. Ich bezweifle allerdings stark, dass Sie mit ihrem "Grill den Neuen" Modus in diesem Forum überhaupt eine nennenswerte Rolle für die Entwicklung der Automatisierungstechnik spielen werden. 
Schönes Wochenende.


----------



## DeltaMikeAir (14 August 2021)

Frank_Martin schrieb:


> Auch das ist wieder eine Aussage, die Sie mir in den Mund legen. Ich habe keine Aussage getroffen welche Rolle die Grollmus GmbH in der Zukunft haben wird. Warum auch. Ich habe ein eigenes Unternehmen. Ich bezweifle allerdings stark, dass Sie mit ihrem "Grill den Neuen" Modus in diesem Forum überhaupt eine nennenswerte Rolle für die Entwicklung der Automatisierungstechnik spielen werden.
> Schönes Wochenende.


Passt schon, ich wünsche auch ein schönes Wochenende.


----------



## Blockmove (14 August 2021)

Frank_Martin schrieb:


> Habe ich behauptet das sei KI?
> Das steht „das geht in diese Richtung“ und es ging um Codegenerierung. Und ich würde es gerne beim „Sie“ belassen. Danke



Du (und dabei bleibe ich, da es im Forum üblich ist) hast mit Buzzwords um dich geworfen und mangelnde Innovationsfreude unterstellt.
Den Begriff KI hast du ins Spiel gebracht und nun wunderst du dich, dass bei einem Codegenerator Gegenwind kommt?

Ich weiß nicht in wie weit du weißt woran z.B. Siemens arbeitet?
Als Beispiel mal die Verbindung Teamcenter, NX und TIA mit all den Möglichkeiten, die dahinter stecken.


----------



## Onkel Dagobert (14 August 2021)

Ich habe mal prophylaktisch die Methode des Ignorierens angewendet. Funktioniert ganz gut.


----------



## Frank_Martin (14 August 2021)

Blockmove schrieb:


> Du (und dabei bleibe ich, da es im Forum üblich ist) hast mit Buzzwords um dich geworfen und mangelnde Innovationsfreude unterstellt.
> Den Begriff KI hast du ins Spiel gebracht und nun wunderst du dich, dass bei einem Codegenerator Gegenwind kommt?
> 
> Ich weiß nicht in wie weit du weißt woran z.B. Siemens arbeitet?
> Als Beispiel mal die Verbindung Teamcenter, NX und TIA mit all den Möglichkeiten, die dahinter stecken.


Sie wissen sicherlich, dass das TIA Selectiontool Tool von Grollmus programmiert wird. Von daher wäre es spannend zu schauen wer hinter Teamcenter oder NX wirklich steckt. 😉


----------



## Blockmove (14 August 2021)

Frank_Martin schrieb:


> Auch das ist wieder eine Aussage, die Sie mir in den Mund legen. Ich habe keine Aussage getroffen welche Rolle die Grollmus GmbH in der Zukunft haben wird. Warum auch. Ich habe ein eigenes Unternehmen. Ich bezweifle allerdings stark, dass Sie mit ihrem "Grill den Neuen" Modus in diesem Forum überhaupt eine nennenswerte Rolle für die Entwicklung der Automatisierungstechnik spielen werden.
> Schönes Wochenende.



Niemand will den Neuen grillen.
Wenn man jedoch pauschal kritisiert, dann will man wissen, was steckt hinter dem Neuen.
Welche Expertise hat er, welchen Background hat er und ggf. für wen arbeitet er.


----------



## Blockmove (14 August 2021)

Frank_Martin schrieb:


> Sie wissen sicherlich, dass das TIA Selectiontool Tool von Grollmus programmiert wird. Von daher wäre es spannend zu schauen wer hinter Teamcenter oder NX wirklich steckt. 😉



Ja klar ... Und wahrscheinlich verkauft Siemens demnächst seine Industrieausrüstungssparte an Grollmus 😜


----------



## Ralle (14 August 2021)

Frank_Martin schrieb:


> Und im nächsten Step wird die Software immer mehr selbst übernehmen. Kann man glauben, muss man aber nicht.


Wenn du schon so lange dabei bist, dann solltest du wissen, dass uns das seit über 30 Jahren prophezeit wird. Alle Jahre wieder. Ist es nun endlich soweit? Schön, wenn es denn dann mal funktionierende Ansätze und Systeme gibt mache ich da gerne mit, das soll kein Problem sein. Was bisher so mit den FB geht, machen wir auch, da ist schon mehr OOP drin, als so mancher glaubt. Aber da haben so einige Hersteller erst einmal eine Bringepflicht, denn ich soll das ja kaufen. Wenn ich Siemens TIA so sehe, dann kann ich nur sagen, wenn das in einem AKW stecken sollte, weit Abstand halten. 

PS: Wir  grillen hier nur Grillgut, dass sich selbst dazu anbietet. Du hast weit vorne gelegen und es war durchaus amüsant. Bisschen gemein, ok, aber darüber stehen Programmierer, echte jedenfalls. 😂  Für mich ist es nun gut, genug heiße Luft, schönes WE.


----------



## wollvieh (14 August 2021)

Eins noch zum Besten: Vor einigen Tagen habe ich an einer 34 Jahre alten Bosch CL Steuerung eine Programmänderung gemacht. Schön mit Vergleichen, Ändern, Online Nachladen, auf Diskette sichern. Das möchte ich mal an einer gleichalten Beckhoff oder TIA Maschine sehen... Wär bestimmt interessant.


----------



## Kieler (14 August 2021)

Frank_Martin schrieb:


> Allerdings bin ich kein klassischer Unternehmensberater. Sonst wäre ich .......


Also für mich hört sich das eher nach einer Bestätigung an. Vielleicht mit der Einschränkung, daß du nicht so gut ausgebildet bis wie ein  klassischer Unternehmensberater.


----------



## Gerhard Bäurle (15 August 2021)

Frank_Martin schrieb:


> Vielleicht ist es ja vielen SPS-Programmierern nicht aufgefallen. Die Programmierung hat sich seit der S5 weiter entwickelt. Schon mit der S7 hat sich sogar Siemens in eine Richtung entwickelt wo CODESYS schon lange ist. Ob einem gefällt oder nicht. Die Modularisierung geht weiter und OOP ist State of the Art. Wird es auch in der Automatisierungstechnik. Vielleicht auch ohne IEC 61131.
> Der Vorteil liegt bei der Rationalisierung der Programmierung(Kosten).
> Der Trend geht Richtung KI die programmiert. Durchgetestet Module brauchen weniger Fehlersuche. So einfach ist das. Auch wenn man es nicht mag, die Zukunft findet statt. 😉


Werter Herr Schmiedel, was sich in der Theorie toll anhört, ist in der Praxis nicht zwingend brauchbar. Das merkt man halt nur, wenn man auch in der Praxis unterwegs ist und in den Themen arbeitet.  

Nebenbei: Meiner Meinung nach wird das Thema KI völlig überschätzt.

Starke KI, also Problemlösungen, wie es der Mensch kann, ist doch Science Fiction: Den Maschinen fehlt – im Vergleich zum Menschen – etwas entscheindendes: der menschliche Verstand. Die Forschung ist hier kaum weiter als bei Null.

Schwache KI, riesige Datenmengen druchsuchen und Muster erkennen, oder maschinelles Lernen wird sicher an Bedeutung gewinnen. Wobei die heutigen Systeme ja nicht mal merken, wenn sie mit den falschen Daten trainiert werden.

Alles in allem ein schwieriges Thema. Besonders hier im SPS-Forum, wo überwiegend Leute sind, die das, was sie machen, auch verantworten müssen – so im Gegensatz zum gängigen "Berater".


----------



## Heinileini (15 August 2021)

Gerhard Bäurle schrieb:


> Alles in allem ein schwieriges Thema. Besonders hier im SPS-Forum, wo überwiegend Leute sind, die das, was sie machen, auch verantworten müssen ...


Genau das ist der Knackpunkt. Machbar ist so einiges, was man mit dem Begriff KI "rechtfertigen" kann. Mag es noch so gut gemeint sein als Entlastung der ach so gestressten Menschen. Aber es bleibt uns nicht erspart, Entscheidungen zu treffen und zu verantworten.
Wissen wir demnächst überhaupt noch, wenn wir uns auf "Fakten" berufen (wollen), ob bzw. inwieweit diese auf "Erkenntnissen" aus der KI basieren?
Wollen wir es dann überhaupt noch wissen, wenn es doch so schön ist, den Schwarzen Peter weiterreichen zu können?


----------



## DeltaMikeAir (16 August 2021)

@Frank_Martin 
Keine Antwort mehr?


----------



## DeltaMikeAir (17 August 2021)

Was macht eigentlich ein "Coach für Lebensfreude"?


----------



## oliver.tonn (17 August 2021)

Blockmove schrieb:


> Ja klar ... Und wahrscheinlich verkauft Siemens demnächst seine Industrieausrüstungssparte an Grollmus 😜


Ich finde zwar, dass @Frank_Martin es an manchen Stellen übertreibt, z.B. was die Sache mit dem Sie angeht, er etwas empfindlich ist und von seiner Meinung etwas zu sehr überzeugt ist und andere Meinungen nur schwer akzeptieren kann, aber bezüglich seiner Aussage zum TIA Selection Tool muss ich ihn in Schutz nehmen, dies stammt tatsächlich von Grollmus, was hier nachzulesen ist.


----------



## DeltaMikeAir (17 August 2021)

oliver.tonn schrieb:


> aber bezüglich seiner Aussage zum TIA Selection Tool muss ich ihn in Schutz nehmen, dies stammt tatsächlich von Grollmus, was hier nachzulesen ist.


Das hat ja auch niemand bezweifelt. Das ist allgemein bekannt.


----------



## oliver.tonn (17 August 2021)

DeltaMikeAir schrieb:


> Das hat ja auch niemand bezweifelt. Das ist allgemein bekannt.


OK, sorry, das hörte sich für mich anders an.


----------



## seehma (17 August 2021)

Wow, hier gehts ja rund. Ich sehe schon, war viel zu lange nicht mehr im Forum -> spannende Diskussion.
Vielleicht hilfts wenn ich unsere Story ein wenig erzähle...
(Achtung: heißt nicht das ist der einzig richtige oder wahre weg, es war halt ein Weg...)

Also wir kommen von der Steuerungsprogrammierung mit Linux und Echtzeitunterbau, Programmierung in C (Antriebe Sercos). Hochsprache mit allen Feinheiten und Raffinessen, extrem viel Performance aber leider auch hoher administrativer Aufwand in der Basisentwicklung (Treiber, OS-Umstieg, Entwicklungssystem, CrossCompile). Wir wollten dann auf einen Systemanbieter (2012) wechseln weil wir uns diesen "Aufwand" sparen wollten und es ist dann der große Rote geworden, der zu dieser Zeit mit Twincat 3.*0 *ein extrem innovatives Produkt gebracht hat. Objektorientierung, Multitasking, 64Bit usw...

Wir haben uns dann Anfangs voll drauf gestürzt und die komplette Welt der Objektorientierung ausgenutzt. Es wurde eine Art Vorlage entwickelt wie man Maschinen programmiert damit alle gleich arbeiten, es gibt einen Satz an Basisbibliotheken, welche die wesentlichen Funktionen abdeckt (Achsen, IOs, Aktuatoren, ...) und so entstand mal eine erste Version. Die Performance war eher Mau und teils war es auch viel zu kompliziert gemacht, vor allem in Hinblick auf Wiederverwendbarkeit. Es war zwar schön durchdesignt aber mit den falschen Randbedingungen. Wir dachten einfach so eine SoftSPS ist ein wahres Rechenwunder, ab einer gewissen Zykluszeit und größe der Maschine wirds halt auch für eine SoftSPS eng. 

In Version zwei sind wir einige dieser Punkte angegangen und haben das ganze nochmal gründlich überarbeitet, größtenteils wurden auch ältere Projekte noch portiert. Es wurden die Performance-Engpass-Verursacher gesucht und entfernt, der Aufbau etwas entwirrt und auch gewisse Dinge noch stärker standardisiert. Leider haben wir es dann aber auch gerade beim Thema Initialisierung und Abstraktion wieder übertrieben und kamen auch hier nach ein paar Sondermaschinen drauf: das geht noch besser.

Ein paar kleine Änderungen wurden dann noch eingearbeitet, sozusagen eine V2.1 und dies verwenden wir jetzt für alle neue Projekte innerhalb unserer Firma. Was sind nun solche Projekte: Im Wesentlichen Sondermaschinen für die interne Produktion. Dabei gehts um ganz kleine Maschinen mit 1-5 Achsen und ein paar hundert IO-Punkten bis rauf zu großen Maschinen 170 Achsen und ein paar Tausend IO-Punkten. Alles mit dem selben Framework und eben auch Aufbau.

Der Vorteil hier ist, durch den klar dokumentierten Aufbau kann man die Mitarbeiter sehr flexibel für Erweiterungen und Verbesserungen (extrem wichtig bei Sondermaschinen da dies meist Prototypen sind) einsetzen. Sie finden sich schnell zurecht und finden die jeweiligen Stellen wo programmiertechnisch angesetzt werden muss, falls es mal Probleme gibt oder man was neues braucht.

Was ich hier sagen will, die Objektorientierung ermöglicht und vereinfacht vieles (Wiederverwendung, Struktur und was nicht zu vernachlässigen ist die Akzeptanz unter den jüngeren Entwicklern/Bewerbern), aber man muss extrem aufpassen dass man sich nicht verhaspelt. Im wesentlichen arbeitet man mit einem hochverfügbaren System das Echtzeit beherrschen soll und da darf man gewisse Dinge einfach nicht tun. Das war schon unter der Linux Steuerung so und ist auch bei Codesys V3 Systemen so. Man darf und kann PLC-Programmierung nicht mit einer "normalen" IT Applikation vergleichen. Ich muss auch sagen, das wissen aus der "C-Welt", also wie das ganze auch dann im Speicher und auf der CPU abläuft, hilft hier natürlich auch stark.

Die Version 3 dieses Frameworks wird jetzt von einer externen Firma nochmals komplett neu entwickelt und die wirds bald inkl. der Libs Online als OpenSource System geben.

Zum Thema KI hab ich lachen müssen. Viele reden von KI und haben ein paar Whitepaper von Herstellern durchgelesen. Auch wir hatten solche Firmen da und haben auch einiges umsetzen können, richtig was gebracht hats nur in wenigen Fällen. Meiner Meinung nach fängt das Problem ja schon bei der Datenaufzeichnung, Haltung und Qualität an. Wie schnell wird aufgezeichnet, wie deterministisch, wie werden die Daten abgespeichert, wo werden sie abgespeichert und wie generisch sind sie gespeichert. Im Sondermaschinenbau natürlich möglich, aber ohne starke Standardisierung nur sehr schwer!

Insgesamt muss ich sagen sind wir doch sehr froh, dass wir komplett auf die Objektorientierung gesetzt haben, da wir dadurch die benötigte Komplexität der Maschinen und auch der Prozesse übersichtlicher und einfacher abbilden konnten. Die Wiederverwendbarkeit ist hiermit auch viel einfacher und besser möglich. Weiters haben einige jüngere Mitarbeiter das Feedback gegeben, dass klassische PLC-Programmierung mit AWL, FUP und KOP oder auch ohne moderne Paradigmen der OOP sie eher zum Jobwechsel gebracht hätten als zum Job halten. Die Learnings die wir mit OOP und dem Codesys System hatten möchte ich eh nochmal niederschreiben, vll teil ich das dann mal hier mit euch...

Sg
M.


----------



## Blockmove (17 August 2021)

@seehma 
Vielen Dank für deine Erläuterungen  
Ganz besonders zum Thema OOP.
Das deckt sich komplett mit meinen Ansichten.
OOP ist der richtige Weg in der Automatisierung.
Wir arbeiten schließlich mit realen Objekten und warum soll sich das dann nicht auch in der Software wiederspiegeln?
Über das Ziel hinausschießen ist dabei wirklich das Thema.
Ich hatte dazu mal ne nette Erfahrung mit nem jungen Kollegen.
Er hat versucht alles von einer Achse abzuleiten. Ein normaler Zylinder war auch eine Achse.
In der Theorie auch richtig, kann man in OOP machen. Diskussion war zwecklos.
Also hat er sein Programm so geschrieben ... Und ist an der Inbetriebnahme gescheitert.
Daraufhin einfach auf Ableitung und Vererbung verzichtet und Zylinder, Achsen getrennt betrachtet und alles war gut.


----------



## rlw (17 August 2021)

seehma schrieb:


> Der Vorteil hier ist, durch den klar dokumentierten Aufbau kann man die Mitarbeiter sehr flexibel für Erweiterungen und Verbesserungen (extrem wichtig bei Sondermaschinen da dies meist Prototypen sind) einsetzen. Sie finden sich schnell zurecht und finden die jeweiligen Stellen wo programmiertechnisch angesetzt werden muss, falls es mal Probleme gibt oder man was neues braucht.


Hallo, mich würden die Erfahrungen der Instandhaltung bei der Fehlersuche interessieren. Sind die auch so positiv ?
gruß rlw


----------



## oliver.tonn (17 August 2021)

rlw schrieb:


> Hallo, mich würden die Erfahrungen der Instandhaltung bei der Fehlersuche interessieren. Sind die auch so positiv ?
> gruß rlw


Da muss der Instandhalter sich halt fortbilden. Früher gab es Klappertechnik, bis es einer gewagt hatte da eine Steuerung statt der schönen Schütze einzusetzen. Was hat da der Instandhalter gemacht? Dann wurde die schöne S5 die lief und mit der man doch eigentlich alles machen konnte frecherweise durch eine S7 ersetzt. Was nun? Man muss halt offen für Neuerungen sein, aber natürlich diese nicht mit Gewalt einsetzen. Die Entwicklung geht weiter und wir alle müssen uns anpassen.


----------



## rlw (17 August 2021)

oliver.tonn schrieb:


> Da muss der Instandhalter sich halt fortbilden. Früher gab es Klappertechnik, bis es einer gewagt hatte da eine Steuerung statt der schönen Schütze einzusetzen. Was hat da der Instandhalter gemacht? Dann wurde die schöne S5 die lief und mit der man doch eigentlich alles machen konnte frecherweise durch eine S7 ersetzt. Was nun? Man muss halt offen für Neuerungen sein, aber natürlich diese nicht mit Gewalt einsetzen. Die Entwicklung geht weiter und wir alle müssen uns anpassen.


Das ist jetzt nicht gerade ein Erfahrungsbericht.


----------



## oliver.tonn (17 August 2021)

rlw schrieb:


> Das ist jetzt nicht gerade ein Erfahrungsbericht.


Also ich habe schon für mehrere Kunden gearbeitet die einen gewissen OOP Ansatz (z.B. Ventil FBs vererbt) verfolgen und da kamen keine Klagen aus den entsprechenden Abteilungen.


----------



## Blockmove (17 August 2021)

OOP vs Instandhaltung:
Hier ist es ganz klar abhängig von der Umsetzung durch den Programmierer.
Du kannst OOP so aufbauen, dass du z.B. einen nach aussenhin einen ganz normalen FB für Ventilansteuerung hast.
Vererbung / Erweiterung findet alles intern statt. 
Du kannst aber auch OOP so aufbauen dass Methoden und Eigenschaften überall im Programm verstreut sind.
Wie  eine Eigenschaft (z.B. "Station2.X-Achse.Bewegungsfrg") aufgebaut ist, wo sie herkommt, kann dann schwierig zu finden sein.
Die Vorteile bei OOP liegen momentan doch mehr bei der Programmerstellung als bei der Fehlersuche.


----------



## seehma (17 August 2021)

Die klare Strukturierung hat hier nicht nur dem Steuerungstechniker-Team geholfen den Code gleich aufzubauen und zu programmieren sondern die hilft natürlich auch anderen. Folgende Vorgehensweise haben wir gewählt (keine Garantie auf Erfolg, bei uns hats geklappt):

(Fast hätte ich es vergessen): Coding Guidelines -> wie markiere ich eine variable die statisch da liegt oder am Stack; Wie benamse ich ein Enum und eine Struktur. Das ganze haben wir noch ein paar mal nachschärfen müssen da manche Dinge von der IDE nicht so gut unterstützt waren, aber der Guide sollte dann halt auch quer über alle Abteilungen bekannt sein
Nomenklatur für Maschinen und Standardisierung des Aufbaus: Es war uns wichtig das jeder das gleiche versteht wenn von einer Station, einer Achse, einem Aktuator oder einem IO gesprochen wird. Jeder muss auch wissen wie und wo sind die Schnittstellen definiert.
Testbetriebe für standardisiertes Equipment: So gut wie alles, das in der Maschine einen Prozess verrichtet ist standardisiert und somit gibt es dafür auch Testbetriebe. Damit meine ich im wesentlichen elektroantriebe, aktuatoren (meist pneu oder hydr.), inputs, outputs, sensoren usw...
Die Testbetriebe werden bei uns großteils automatisiert erstellt, erzeugen somit keinen Mehraufwand.
Weniger Debuggen mit Haltepunkte mehr übersichtliches Logging: Wir sind von den Haltepunkten etwas weggekommen und verwenden sie nur mehr im äußersten Notfall (der Instandhalter gar nicht mehr). Viel wichtiger war es für uns ein hoch performantes, übersichtliches und standardisiertes Logging zu haben. Diese Logfiles lesen geben eigentlich über alles Aufschluss, erfordert aber auch etwas Übung; Achtung, da spreche ich nicht von Meldungen die am HMI angezeigt werden, die Logfiles die ich meine sind gut mal einige Megabyte große für ein paar Minuten Maschinenleistung. Die Vorteile liegen auf der Hand, aber wenn man aus der Welt der Haltepunkte kommt ist das nicht so eindeutig ersichtlich. Wir hatten sowas bei Linux/C nicht, da gabs auch nur das Logging und daher waren wir das auch so gewöhnt.
Ich hoffe ich konnte das genügend erklären und hab da gleich eine Gegenfrage @rlw : Suchen bei euch Instandhalter auch Softwarebugs oder schreiben Prozessabläufe um, oder geht es bei der Instandhaltung wirklich "nur" um die bestehende Software und Prozesse aufrechterhalten?

Vielleicht komme ich ja mal in den Genuss die Idee bzw. den gewählten, künftigen Weg näher zu zeigen, gäbe es da Interesse? Das wäre natürlich auch von anderen interessant, falls noch jemand sich in diese Richtung bewegt hat...


----------



## PN/DP (17 August 2021)

Na, Haltepunkte sind bei SPS zur Störungssuche eh' ein absolutes No-Go.

Instandhalter sind in der Regel nicht doof und können sich auch an die verschiedensten Programmiersysteme gewöhnen, wenn die sich bei der Arbeit einfach beobachten lassen. Instandhalter suchen meistens unter Zeitdruck, warum es in einem Prozess nicht weitergeht "Auf welches Signal wartet der Prozess?" oder "Welcher Sensor ist kaputt?" Wenn sich das nicht einfach beobachten lässt, dann ist die ganze tolle Software-Technologie für die Katz.

Ab welcher Version ungefähr wird es bei dem System Online Change im Run geben?

Harald


----------



## Blockmove (17 August 2021)

Es gibt halt letztlich ganz verschiedene Arten Maschinen zu programmieren.
Kommt man aus der Embedded-Ecke, dann macht man es lhalt anders als wenn man von der klassischen Steuerungstechnik kommt.

Ich hab mal ein Fördertechnik-Programm ändern müssen. Etwa 20 Elemente (Rollenbahnen, Drehtische, Stopper, ...).
Es gab im gesamten Programm nur 32 Datenbits. Bezeichnet mit Binärregister 0 bis 31. Dazu 32 Datenworte bezeichnet als Wordregister 0 bis 31.
Dann gabs noch einen Stack. Die Anlage hat recht gut funktioniert.
Ich sollte nur eine Kleinigkeit ändern, habs aber in dem System nicht hinbekommen.
Der vorherige Programmierer hat vorher Mikrocontroller basierte Steuerungen programmiert und war nicht mehr greifbar.


----------



## seehma (18 August 2021)

PN/DP schrieb:


> Instandhalter sind in der Regel nicht doof und können sich auch an die verschiedensten Programmiersysteme gewöhnen


So war es gar nicht gemeint, hab gemacht bzw. mach das selber ja auch noch teilweise. Software kann da aber schon sehr helfen wenn klar strukturiert, immer gleich und die Meldungen im Log/HMI aussagekräftig. Oft sind auch Testbetriebe sehr wichtig wo man gewisse Sensorfunktionen testen/aufzeichnen kann um eben überhaupt mal deren Funktion zu testen. Das Problem im Sondermaschinenbau ist ja eigentlich, man hat schon genug mit Prozess und der "Sondermaschine" zu tun und meist wenig Zeit für die Standardisierungs-Dinge und so Testbetriebe, deshalb werden die meist nicht umgesetzt.



PN/DP schrieb:


> Ab welcher Version ungefähr wird es bei dem System Online Change im Run geben?


Online Change im Run gibt es ja bei Twincat schon seit Beginn eigentlich. Das ganze lief mal besser mal schlechter, mittlerweile eigentlich sehr stabil. Früher hat er halt nicht erkannt, bzw. nicht gewarnt wenn sich beim Change im Speicher was tut nach dem OnlineChange, das wurde jetzt verbessert (bin mir nicht ganz sicher mit welcher Version).



Blockmove schrieb:


> Es gibt halt letztlich ganz verschiedene Arten Maschinen zu programmieren.
> Kommt man aus der Embedded-Ecke, dann macht man es lhalt anders als wenn man von der klassischen Steuerungstechnik kommt.


Das stimmt natürlich. Da wir aus der C und Linux Welt kamen, waren unsere Ansprüche einfach: wir wollen auf jeden Fall OOP und deshalb auch gleich voll in die Richtung. Wir haben bei Linux mal so UML-Geschichten getestet und waren da sehr weit, das wurde dann aber auf Grund von Zeitdruck wieder verworfen.

Auf jeden Fall, falls man einen Systemwechsel macht, die Möglichkeiten von OOP mal anschauen und falls es gibt, auch mit Hilfe. Die gabs bei uns nicht und wir haben da halt ein paar Jahre ordentlich lernen müssen (viele Überstunden lang, aber ganz ehrlich, hat auch Spaß gemacht)


----------



## ducati (18 August 2021)

seehma schrieb:


> Die Version 3 dieses Frameworks wird jetzt von einer externen Firma nochmals komplett neu entwickelt


??? 🤔
Wieviel Geld habt Ihr denn für V1 und V2 schon ausgegeben? Und wenn dass doch so gut war und toll funktioniert hat, warum wirds dann jetzt nochmal extern neu gemacht?

Hört sich für mich nach entwickeln um des Entwickelns Willen und Lizenz zum Geld verbrennen an. Oder nach Joberhaltung für die Entwickler.

Wenn eine Bibliotheksentwicklung so viel Geld kostet, wieviel Anlagen muss mann dann damit bauen, damit sich das rechnet?


----------



## Rob1337 (18 August 2021)

Die OOP in Codesys hat sehr viel Potential, insbesondere in Bibliotheken.

Es gibt leider noch Mankos:

Der Status in der Online-Ansicht von Properties / Methoden stoßen bei uns in der Firma aktuell auf großen Unmut. Die Pragmas sind zwar ganz nett, aber auch mit Vorsicht zu genießen. Zudem funktionieren diese nicht so toll bei der Verwendung von Interfaces
Die Querverweise sind zum Teil gruselig bezgl. Nachverfolgen. Insbesondere bei der der Verwendung von Interfaces
Ein Onlinechange ist nur noch bedingt möglich. Sobald ein Property / Methoden geändert wird oder in der Deklaration wird es schwierig. Mir hat man erklärt es wäre von Vorteil wenn der Body zyklisch aufgerufen wird, auch wenn dieser keinen Code enthält.
Bei Verwendung von THIS^ Pointern kann die Variable nicht mehr wie gewohnt mit Rechtsklick zu einem Trace hinzugefügt werden
Die Performance kann bei richtiger Verwendung gesteigert werden, aber die Lektüren was es aktuell dazu gibt ist sehr dürftig. Man muss eher in andere Programmiersprachen einarbeiten um ein besseres Verständnis zu bekommen
Die Dokumente was es zu den von Codesys erstellten „OOP Bibliotheken“ gibt sind aus meiner Sicht ungenügend. Da hab ich die .NET Beschreibung besser verstanden, als ich mal was damit gemacht habe, obwohl das nicht meine Welt ist
Die oben genannten Punkte sind mir mit einer älteren Version aufgefallen (3.5.8)

Der Trend geht trotzdem klar zur OOP.
Ich wäre sehr interessiert an deinem Framework @seehma


----------



## seehma (18 August 2021)

ducati schrieb:


> Wieviel Geld habt Ihr denn für V1 und V2 schon ausgegeben? Und wenn dass doch so gut war und toll funktioniert hat, warum wirds dann jetzt nochmal extern neu gemacht?


Du hast Recht, die erste Version war nicht gratis. Vor allem haben wir erstmal mit Twincat und der V3 richtig umgehen lernen müssen. Die genauen Kosten kann ich nicht sagen, aber es wurde auf jeden Fall mal ein Projekt für das ganze aufgesetzt. Man muss dazusagen, die Ideen für das Framework waren nicht neu, wir hatten das alles schon im Linux System und wussten wie vom Grundgerüst her das aufzubauen ist. Probleme gabs am Anfang eher mit der Systemstabilität (Bluescreens, Ethercat Probleme, Ausfälle der Echtzeit und somit der Antriebe, Bibliothekshandling ist auch komplett anders als in anderen Sprachen und Systemen, Abstürze der Umgebung, Links gingen ständig verloren usw...).

Die Folgeversionen wurden dann eigentlich immer im Zuge von neuen Großprojekten mit-(und weiter-)entwickelt. V2 klingt jetzt so, wie wenn es komplett über den Haufen geschmissen wurde, aber im wesentlichen wurde nur der Aufbau (wo liegen welche Objekte und wie wird drauf zugegriffen) geändert. Heißt mehr Verschiebe- und Dokumentationsarbeit als neu entwickeln. Also hier hat sich der Aufwand in Grenzen gehalten.

V2.1 war dann eigentlich nur noch eine Draufgabe um die Performance zu verbessern. Wir haben dann ein paar Maschinen gebaut die von der Zykluszeit her aufgrund Prozess auf 500us und 250us runter mussten, allerdings mit 10-18 Achsen (je nach Ausbaustufe) und da haben wir dann hier nochmal einiges verbessert.



ducati schrieb:


> Hört sich für mich nach entwickeln um des Entwickelns Willen und Lizenz zum Geld verbrennen an. Oder nach Joberhaltung für die Entwickler.


Eigentlich war es immer ein kontinuierliches verbessern.



ducati schrieb:


> Wenn eine Bibliotheksentwicklung so viel Geld kostet, wieviel Anlagen muss mann dann damit bauen, damit sich das rechnet?


Ich hab nie gesagt dass es viel Geld war ;-). Die Rechnung ging bei uns dann ganz wo anders auf. 
Beispiel: Wir haben eine sehr große Anlage, gemacht von 2 Entwicklern mit dem V2 System und wie der Teufel so will war einer mal Urlaub und der zweite im Krankenstand, zeitgleich. Es trat ein Fehler auf und es war eindeutig ein Softwarebug im Steuerungssystem. Durch den strukturierten Aufbau konnte halt ein dritter Entwickler, der die Maschine nie gesehen hat hingehen, sich das Problem erklären lassen und das Problem zügig beheben (1/2h). Zugegeben sagt jetzt nicht unbedingt viel aus, aber für uns intern war das dann irgendwie eine Bestätigung dass der Weg an sich schon passt. Gerade im Sondermaschinenbau passiert es halt oft dass sich mehrere unterschiedliche Systeme etablieren und die Entwickler nicht beliebig austauschbar sind.



ducati schrieb:


> Und wenn dass doch so gut war und toll funktioniert hat, warum wirds dann jetzt nochmal extern neu gemacht?


V3 gibts einfach nur deswegen, weil wenn du mit so einem (intern entwickelten) System extern gehst dann muss die Codequalität, Testabdeckung und Dokumentation einfach viel durchgängiger und besser sein. Durch das ständige Weiterentwickeln haben sich halt so manche Unschönheiten eingeschlichen die man auf Grund von Zeitdruck intern nicht ausbessert. Das kannst du mit einem öffentlichen System aber so nicht machen. Leider hat Corona halt auch die Wirtschaftliche Situation nicht unbedingt verbessert und wir mussten auch Leute abbauen.

Möchte nochmal betonen, ich sag hier auf keinen Fall "das ist der einzig richtige Weg". Ich kann nur von meiner Erfahrung und Historie her sagen, für uns hat es sich insgesamt schon gelohnt und ich möchte das ganze nicht mehr missen. Im Endeffekt sind aber natürlich immer mehrere Punkte in so eine Bewertung mit reinzunehmen und man kann das nicht pauschal für eine Entwicklermannschaft oder Firma sagen ob passt oder nicht.


----------



## oliver.tonn (18 August 2021)

PN/DP schrieb:


> Na, Haltepunkte sind bei SPS zur Störungssuche eh' ein absolutes No-Go.


Da werden Dir viele meiner Kunden aber widersprechen, wobei hier Störungssuche eine Definitionssache ist. Da ging es meist um die Fehlersuche während der Entwicklung oder Erweiterung einer Anlage.


----------



## DeltaMikeAir (18 August 2021)

oliver.tonn schrieb:


> Da werden Dir viele meiner Kunden aber widersprechen, wobei hier Störungssuche eine Definitionssache ist. Da ging es meist um die Fehlersuche während der Entwicklung oder Erweiterung einer Anlage.


Also ich stimme Harald ( @PN/DP ) vollkommen zu. Bei unseren Anlagen wären Haltepunkte absolut sinnbefreit und auch gar nicht möglich.
( Palettierer, Kommissionieranlagen, Abfüllanlagen.... ).

Du kannst dir ja selbst mal überlegen, wenn ich bei einem Flaschenabfüller mit einer schnell rotierenden Masse von ca. 4 to
einen Breakpoint setze, was dann passiert. Dann bin ich nicht mehr mit dem ursprünglichen Problem beschäftigt sondern mit 50 anderen.



Es kommt wohl auf die Anlagenart an.


----------



## oliver.tonn (18 August 2021)

DeltaMikeAir schrieb:


> Also ich stimme Harald ( @PN/DP ) vollkommen zu. Bei unseren Anlagen wären Haltepunkte absolut sinnbefreit und auch gar nicht möglich.
> ( Palettierer, Kommissionieranlagen, Abfüllanlagen.... ).
> 
> Du kannst dir ja selbst mal überlegen, wenn ich bei einem Flaschenabfüller mit einer schnell rotierenden Masse von ca. 4 to
> ...


Das hatte ich nicht extra erwähnt, aber klar kommt es auf den Anlagentyp an. Bei einer hochdynamischen Anlage kann man natürlich nicht einfach einen Breakpoint setzen um sich gewisse Dinge mal in Ruhe anzusehen. Können könnte man natürlich schon, aber mit was für Konsequenzen.


----------



## rostiger Nagel (18 August 2021)

DeltaMikeAir schrieb:


> Also ich stimme Harald ( @PN/DP ) vollkommen zu. Bei unseren Anlagen wären Haltepunkte absolut sinnbefreit und auch gar nicht möglich.
> ( Palettierer, Kommissionieranlagen, Abfüllanlagen.... ).
> 
> Du kannst dir ja selbst mal überlegen, wenn ich bei einem Flaschenabfüller mit einer schnell rotierenden Masse von ca. 4 to
> ...


Das Haltepunkte im Maschinenbau Käse sind ist klar,
allerdings wie ich es bei seehma rauslese, wird er die auch
nicht benötigen.


----------



## DeltaMikeAir (18 August 2021)

rostiger Nagel schrieb:


> allerdings wie ich es bei seehma rauslese, wird er die auch
> nicht benötigen.


Dafür fehlt mir die Erfahrung im Bereich OOP.


----------



## Blockmove (18 August 2021)

rostiger Nagel schrieb:


> Das Haltepunkte im Maschinenbau Käse sind ist klar,
> allerdings wie ich es bei seehma rauslese, wird er die auch
> nicht benötigen.


Die Probleme bei OOP hat ja @Rob1337 gut beschrieben.
Du bekommst teilweise nicht mal einen Status angezeigt (zumindest bei Wago eCockpit).
Also daher muss man schon überlegen was man mit OOP umsetzt und was man "normal" macht.


----------



## vollmi (21 August 2021)

wollvieh schrieb:


> Eins noch zum Besten: Vor einigen Tagen habe ich an einer 34 Jahre alten Bosch CL Steuerung eine Programmänderung gemacht. Schön mit Vergleichen, Ändern, Online Nachladen, auf Diskette sichern. Das möchte ich mal an einer gleichalten Beckhoff oder TIA Maschine sehen... Wär bestimmt interessant.


 Ich bin nicht davon überzeugt, dass eine 1500er überhaupt so lange lebt. Die ersten paar haben bei mir grad mal so die Garantiezeit überlebt, bis sie einfach dunkel wurden. Ich bin also skeptisch, dass wir überhaupt die Chance haben werden bei einer so alten Anlage was ändern zu können.


----------



## rostiger Nagel (21 August 2021)

vollmi schrieb:


> Ich bin nicht davon überzeugt, dass eine 1500er überhaupt so lange lebt. Die ersten paar haben bei mir grad mal so die Garantiezeit überlebt, bis sie einfach dunkel wurden. Ich bin also skeptisch, dass wir überhaupt die Chance haben werden bei einer so alten Anlage was ändern zu können.


Das ist extra so gemacht, weil die TIA auch so verdammt schnell altert.
Nicht das du in 5 Jahren versuchst V11 zu starten.


----------



## Pippen (1 September 2021)

Sehr spannende Diskussion hier. 
Ich arbeite bereits seit über 7 Jahren mit TC3 und ich nutze die Möglichkeiten von OOP wirklich aus. 
Mit OOP hat man die Möglichkeit seine Programme sehr leserlich zu machen, wenn man das will.
Ich arbeite vor allem viel mit Interfaces, die sind sehr mächtig und hilfreich.
Klar gibt es noch ein paar Dinge, die für meinen Geschmack noch fehlen (besonders das Erweitern von Methoden mit zusätzlichen Parametern bei Erweiterungen) und es gibt auch Dinge mit denen man sehr gut aufpassen muss (dynamische Objekte). Wenn man aber ein bisschen dahinter sieht, wenn man weiss, wie das alles im Speicher abläuft, dann ist es wirklich eine sehr gute Sache. Und ganz wichtig: Man muss immer daran denken, dass man es bei SPS Anwendungen mit einer deterministischen Umgebung zu tun hat: Man darf es nicht übertreiben.

Aber für Personen, die sich mit OOP noch nicht so auskennen, würde ich empfehlen zuerst mal einen OOP Kurs zu besuchen (mit SOLID Prinzipien und so). Denn das hilft dann wirklich, ein Programm gut zu strukturieren und die OOP Möglichkeiten gut einzusetzen.


----------



## ducati (1 September 2021)

Pippen schrieb:


> Mit OOP hat man die Möglichkeit seine Programme sehr leserlich zu machen, wenn man das will.
> Ich arbeite vor allem viel mit Interfaces, die sind sehr mächtig und hilfreich.


Leserlich für Dich oder für andere 

Also was sagen Instandhalter oder fremde Programmierer des Kunden zu Deinem Programmierstil?

Ich finde, mit jeder Programmiersprache/Programmierstil kann man leserlich oder unleserlich programmieren.

Aber bestimmte Dinge sind halt eben "Standard" in der Automatisierung, weil man es eben "immer so macht" und deshalb sind diese Sprachen/Stile per see schonmal "leserlicher".

Man fährt halt in Deutschland mit dem Auto auf der rechten Straßenseite, weil das eben so ist, bzw. weil man es in der Fahrschule/Automatisierungslehre so gelernt hat.

Am Ende kommts aber vorrangig drauf an, dass die Anlage/Maschine ordentlich läuft und auch in 10 Jahren noch änderbar/wartbar ist, auch durch einen fremden Automatisierer.

Das ist jetzt keine Kritik an Dir, sondern nur meine allgemeine persönliche Meinung.

Gruß.

PS: es macht halt keinen Sinn, wenn jeder "Programmierer" sich an jeder Anlage neu "selbstverwirklichen" will 

Bei mir gilt generell Einheitlichkeit geht vor Schönheit.


----------



## Pippen (1 September 2021)

ducati schrieb:


> Leserlich für Dich oder für andere
> 
> Also was sagen Instandhalter oder fremde Programmierer des Kunden zu Deinem Programmierstil?
> 
> ...



Ich bin voll Deiner Meinung. Einheitlichkeit ist das A und O.

Deshalb ist es so wichtig, dass es eine Codier- und eine Designrichtlinie gibt an die sich alle halten.
Dann wird der Code komplett verständlich und wartbar.

Instandhalter und fremden Programmierern kann man dann diese Richtlinien und die Dokumentation zeigen und dann ist es ihnen sehr schnell klar, wie das Ganze aufgebaut ist und funktioniert. Bis jetzt haben wir da überhaupt keine Probleme gehabt. Im Gegenteil: Sie waren begeistert von diesem Stil.

Zudem werden in 10 Jahren fast alle Automatisierer mit OOP komplett vertraut sein, da bin ich mir ziemlich sicher.


----------



## IBFS (8 September 2021)

Blockmove schrieb:


> Schau dir mal z.B. Bosch Nexeed Control Plus an.



Nexeed Control Plus ist für mich im Sondermaschinenbau derzeit das Beste auf dem Markt.


----------



## IBFS (8 September 2021)

PN/DP schrieb:


> Haltepunkte sind bei SPS zur Störungssuche eh' ein absolutes No-Go.


Ich verwende NIE!!!!  Haltepunkte. Das liegt aber vermutlich daran, das ich versuche so zu programmieren, das ich auch ohne Haltepunkte und ggf. mit aufrufabhängigen Merkern "Wartepunkte" erzeugen kann, ohne die ganze SPS "abzuschießen".


----------

