- Beiträge
- 25.793
- Reaktionspunkte
- 9.560
-> Hier kostenlos registrieren
Ich hoffe mal das bleibt eine one man show.
TIA S7-1500 Objektorientierte programmierung
- Ersteller Not-Aus
- Erstellt am
-> Hier kostenlos registrieren
Also beschäftige mich auch immer wieder mal mit “OOP“/generell Standardisierung.
Ich komme aus der Richtung Instandhaltung/Anlagen/Maschinenbau und bin seit vielen jahren als Programmier im Einsatz, hauptsächlich Siemens S7 und jetzt TIA Portal.
Ich denke das sowie die Vorredner auch immer wieder versuchen ”Klassen” was in der SPS-Welt FBs oder FĆs sind zu entwickeln und auch gewisse Standards/Bibliotheken dann aufzubauen.
Aber dadurch das es immer wieder neue anforderungen gibt, sich die HW etc ändert oder weil halt als Prozesstechnischen/Maschinenbau technischen dingen wieder mal was dazukommt weil man einfach noch einen Sensor braucht. Stoßt man auch schnell mal an die Grenzen was man wie umsetzen kann etc... bzw. Thema “EierliegendeWollmilchsau” FB´s.
Selber hab ich grad so einen Fall, 10 Kühlkreise, alle “irgendwie” gleich aber dann doch der ein oder andere wieder anders. Hab das auch bissal versucht mit einem gewissen “OOP” Ansatz zu machen aber ja man stößt halt auf grenzen. Oder man verrennt sich mal schnell in eine art “zwangsstandardiesierung”…
Ich hab auch schon mal ein TC3.1 Projekt in die hand gekriegt das dann wirklich mit OOP programmiert wurde, ja in gewisser weiße war manches ganz gut gelöst aber dann halt auch wieder nicht so gut und was halt für mich dazu kam, ich hab ca 2 Monate reengineering gemacht um das alles zu verstehen um kleine Änderungen zu machen. Das in diesem Programm dann mal ein Instandhalter reinschauen kann weil eben mal ein sensor etc. verstellt ist wie auch immer (und mann kann halt nicht alles mit Meldungen/Benutzerhinweisen dem Bediener/Instandhalter anzeigen) da was zu finden sag ich mal sehr schwierig….
Sowie die vorredner auch schon mitgeteilt haben, sehr schwierig und ja oft ist es am besten/effektivsten und auch schnellsten “klassisch Linear was zu machen” auch wenn man wie immer und überall man drüber nachdenken muss.
Dieser so “richtige“ OOP Ansatz mit Vererbung etc. machts selbst für Programmierer nicht einfach bei der Fehleruche (da mein ich nicht Code Fehler) sondern Maschinenfehler sehr schwer…
Aber ich bin auch so offen das man immer wieder bissal neu denken soll oder auch “muss” aber auch nicht immer das Rad neu erfinden und auch nicht unbedingt immer mit für mich Buzzword “objektorientierung” rum hantieren.
Viele gedanken die mir bei dem Thema durch den kopf gehen mit gemischten gefühlen teilweise JA und dann wieder NEIN, kommt es wie so oft im leben auf den bereich an und wie weit man was vernünftig umsetzen kann, man sollte halt vermeiden das man sich zu erst bückt durch die Beine greift um sich am Kopf zu Kratzen
Ich komme aus der Richtung Instandhaltung/Anlagen/Maschinenbau und bin seit vielen jahren als Programmier im Einsatz, hauptsächlich Siemens S7 und jetzt TIA Portal.
Ich denke das sowie die Vorredner auch immer wieder versuchen ”Klassen” was in der SPS-Welt FBs oder FĆs sind zu entwickeln und auch gewisse Standards/Bibliotheken dann aufzubauen.
Aber dadurch das es immer wieder neue anforderungen gibt, sich die HW etc ändert oder weil halt als Prozesstechnischen/Maschinenbau technischen dingen wieder mal was dazukommt weil man einfach noch einen Sensor braucht. Stoßt man auch schnell mal an die Grenzen was man wie umsetzen kann etc... bzw. Thema “EierliegendeWollmilchsau” FB´s.
Selber hab ich grad so einen Fall, 10 Kühlkreise, alle “irgendwie” gleich aber dann doch der ein oder andere wieder anders. Hab das auch bissal versucht mit einem gewissen “OOP” Ansatz zu machen aber ja man stößt halt auf grenzen. Oder man verrennt sich mal schnell in eine art “zwangsstandardiesierung”…
Ich hab auch schon mal ein TC3.1 Projekt in die hand gekriegt das dann wirklich mit OOP programmiert wurde, ja in gewisser weiße war manches ganz gut gelöst aber dann halt auch wieder nicht so gut und was halt für mich dazu kam, ich hab ca 2 Monate reengineering gemacht um das alles zu verstehen um kleine Änderungen zu machen. Das in diesem Programm dann mal ein Instandhalter reinschauen kann weil eben mal ein sensor etc. verstellt ist wie auch immer (und mann kann halt nicht alles mit Meldungen/Benutzerhinweisen dem Bediener/Instandhalter anzeigen) da was zu finden sag ich mal sehr schwierig….
Sowie die vorredner auch schon mitgeteilt haben, sehr schwierig und ja oft ist es am besten/effektivsten und auch schnellsten “klassisch Linear was zu machen” auch wenn man wie immer und überall man drüber nachdenken muss.
Dieser so “richtige“ OOP Ansatz mit Vererbung etc. machts selbst für Programmierer nicht einfach bei der Fehleruche (da mein ich nicht Code Fehler) sondern Maschinenfehler sehr schwer…
Aber ich bin auch so offen das man immer wieder bissal neu denken soll oder auch “muss” aber auch nicht immer das Rad neu erfinden und auch nicht unbedingt immer mit für mich Buzzword “objektorientierung” rum hantieren.
Viele gedanken die mir bei dem Thema durch den kopf gehen mit gemischten gefühlen teilweise JA und dann wieder NEIN, kommt es wie so oft im leben auf den bereich an und wie weit man was vernünftig umsetzen kann, man sollte halt vermeiden das man sich zu erst bückt durch die Beine greift um sich am Kopf zu Kratzen
Zuletzt bearbeitet:
HansSattel
Level-2
- Beiträge
- 10
- Reaktionspunkte
- 7
-> Hier kostenlos registrieren
Hallo,
ich versuche hier niemanden zu überreden oder zu ändern. Bitte nehmt mein Verhalten nicht als Angriff gegen eure bisherige Arbeit an. Ich tue dies übrigens auch nicht...
Ich werde OOP auch nicht zu 100% im SPS bereich verwenden. Vererbung geht auch garnicht und wenn, dann will ich es auch nicht haben.
Aber der Grundgedanke von OOP oder für mich fast die gleiche Idee bietet OPC-UA, finde ich super.
Das Programm muss natürlich so aufgebaut sein, dass man es auch verstehen kann. Jeder Programmierer will sein code in 3Jahren noch verstehen können...
Durchgesetzt hat es sich noch nicht, da noch genügend Programmierer da sind. Ein neues Gerät hinzufügen, ist mir übrigens auch schon passiert. Hier kann ich durch die Programmierung meist einen großteil Kopieren und bin viel schneller fertig als früher. Ich haben bereits 10Jahre Berufserfahrung und seit 5Jahren in der Entwicklung. Also auch kein Anfänger mehr.
Ich würde mich nur darüber freuen, wenn sich Gleichgesinnte bei mir melden. Und wir uns bei einem Bierchen darüber freuen, wie kompliziert wir die Welt des Maschinenbaus machen
ich versuche hier niemanden zu überreden oder zu ändern. Bitte nehmt mein Verhalten nicht als Angriff gegen eure bisherige Arbeit an. Ich tue dies übrigens auch nicht...
Ich werde OOP auch nicht zu 100% im SPS bereich verwenden. Vererbung geht auch garnicht und wenn, dann will ich es auch nicht haben.
Aber der Grundgedanke von OOP oder für mich fast die gleiche Idee bietet OPC-UA, finde ich super.
Das Programm muss natürlich so aufgebaut sein, dass man es auch verstehen kann. Jeder Programmierer will sein code in 3Jahren noch verstehen können...
Durchgesetzt hat es sich noch nicht, da noch genügend Programmierer da sind. Ein neues Gerät hinzufügen, ist mir übrigens auch schon passiert. Hier kann ich durch die Programmierung meist einen großteil Kopieren und bin viel schneller fertig als früher. Ich haben bereits 10Jahre Berufserfahrung und seit 5Jahren in der Entwicklung. Also auch kein Anfänger mehr.
Ich würde mich nur darüber freuen, wenn sich Gleichgesinnte bei mir melden. Und wir uns bei einem Bierchen darüber freuen, wie kompliziert wir die Welt des Maschinenbaus machen
- Beiträge
- 15.091
- Reaktionspunkte
- 3.600
@Peda : Das hast du wirklich sehr schön geschrieben und gut zusammengefasst.
Ich selbst bin beim Programmieren auch ein großer Freund von Standards und innerhalb eines gewissen Rahmens lassen die sich auch schön umsetzen (ich habe dazu vor Jahren ja auch in diesem Thread ein paar Beispiele gepostet). On das jetzt so ganz wirklich objekt-orientiert ist - darüber kann man sich auch streiten. Ich würde diese Instanzierungs-Geschichte nach wie vor auf der untersten Ebene ansetzen - also z.B. einen FU-Baustein (oder oder oder). Hier könnte man das dann z.B. so gestalten, dass man den FB-Sinamics gegen einen FB-Movitrac 1 zu 1 austauschen könnte. In der Richtungs gibt es ganz noch viele weitere Beispiele - ich würde es dann aber eher Framework nennen (heute).
Ich selbst bin beim Programmieren auch ein großer Freund von Standards und innerhalb eines gewissen Rahmens lassen die sich auch schön umsetzen (ich habe dazu vor Jahren ja auch in diesem Thread ein paar Beispiele gepostet). On das jetzt so ganz wirklich objekt-orientiert ist - darüber kann man sich auch streiten. Ich würde diese Instanzierungs-Geschichte nach wie vor auf der untersten Ebene ansetzen - also z.B. einen FU-Baustein (oder oder oder). Hier könnte man das dann z.B. so gestalten, dass man den FB-Sinamics gegen einen FB-Movitrac 1 zu 1 austauschen könnte. In der Richtungs gibt es ganz noch viele weitere Beispiele - ich würde es dann aber eher Framework nennen (heute).
- Beiträge
- 15.091
- Reaktionspunkte
- 3.600
@HansSattel : ich denke mal, dass der hauptsächliche Gegenwind, den du hier bekommen hast daraus resultiert was die Kollegen schon so in Richtung Vererbung und "von hinten durch die Brust ins Auge" kennengelernt haben. Ich beschäftige mich auch mit .Net-Programmierung und ich hatte in diesem Bereich schon mal einen Kollegen, der für "Schrank" als Basisklasse "Stein" gewählt hatte - "Brett" hätte es aber auch gegeben.
Das Beispiel hinkt jetzt vielleicht - aber vielleicht verstehst du auch den Konsens ...
Das Beispiel hinkt jetzt vielleicht - aber vielleicht verstehst du auch den Konsens ...
- Beiträge
- 12.312
- Reaktionspunkte
- 4.488
-> Hier kostenlos registrieren
@Larry
Framework trifft es ganz gut.
Dein Beispiel mit den FUs ist sehr gut.
In IT-Sprache bedeutet es, dass du einen Abstraktionslayer eingezogen hast und nun mit Devicetreiber für Sinamics und SEW erstellt hast.
Framework trifft es ganz gut.
Dein Beispiel mit den FUs ist sehr gut.
In IT-Sprache bedeutet es, dass du einen Abstraktionslayer eingezogen hast und nun mit Devicetreiber für Sinamics und SEW erstellt hast.
- Beiträge
- 15.091
- Reaktionspunkte
- 3.600
oder im .Net-Bereich wäre das dann möglicherweise ein Interface ...
Aber du hast schon recht - wenn man es so macht dann würde es absolut Sinn machen. Hier könnten dann diese "Basis-FB's" ja auch schon so gestaltet sein, dass man gar nicht mehr darein schauen muss (oder möchte) - sie geben ja alle Info's raus ...
Aber du hast schon recht - wenn man es so macht dann würde es absolut Sinn machen. Hier könnten dann diese "Basis-FB's" ja auch schon so gestaltet sein, dass man gar nicht mehr darein schauen muss (oder möchte) - sie geben ja alle Info's raus ...
- Beiträge
- 15.091
- Reaktionspunkte
- 3.600
Einen habe ich noch ...
Hier zeigt sich dann auch schön der Unterschied zu .Net wegen Vererbung und so ...
Wenn wir jetzt mal den FB-Umrichter nehmen dann könnte man sich ja grundsätzlich ein Basis-Objekt erstellen (in der .Net-Welt und ich denke auch bei TC / Codesys) , dass die grundsätzlichen Properties (also Ein- und Ausgaben) und vielleicht ein paar Hilfsroutinen schon mitbringt.
Wenn ich mir das jetzt aber in der SPS vorstelle (auch TC / Codesys - bei Siemens geht es glaube ich so gar nicht) dann würde dies nicht unbedingt zur Durchsichtigkeit des Codes beitragen. Bei .Net hingegen ist es gängige Praxis und macht den Code eher übersichtlich denn unübersichtlich ...
Soviel also dazu ...
Hier zeigt sich dann auch schön der Unterschied zu .Net wegen Vererbung und so ...
Wenn wir jetzt mal den FB-Umrichter nehmen dann könnte man sich ja grundsätzlich ein Basis-Objekt erstellen (in der .Net-Welt und ich denke auch bei TC / Codesys) , dass die grundsätzlichen Properties (also Ein- und Ausgaben) und vielleicht ein paar Hilfsroutinen schon mitbringt.
Wenn ich mir das jetzt aber in der SPS vorstelle (auch TC / Codesys - bei Siemens geht es glaube ich so gar nicht) dann würde dies nicht unbedingt zur Durchsichtigkeit des Codes beitragen. Bei .Net hingegen ist es gängige Praxis und macht den Code eher übersichtlich denn unübersichtlich ...
Soviel also dazu ...
- Beiträge
- 12.312
- Reaktionspunkte
- 4.488
-> Hier kostenlos registrieren
Dann doch lieber nen Gin und die Welt des Maschinenbaus einfacher machenIch würde mich nur darüber freuen, wenn sich Gleichgesinnte bei mir melden. Und wir uns bei einem Bierchen darüber freuen, wie kompliziert wir die Welt des Maschinenbaus machen
Wie bereits geschrieben ist OOP bei SPS absolut sinnvoll.
Eine Maschine / Anlage besteht schließlich aus jeder Menge von Objekten.
Also müsste sowas eigentlich richtig gut geeignet sein für OOP.
Was aber fehlt sind aus meiner Sicht die passenden Entwicklungstools.
Wenn ich mit Klassen arbeite, dann brauch ich auch so was wie einen Klassenbrowser.
Und auch irgendeine Form von geeigneteten Debugger.
Beispiel:
Du kommst an eine Anlage von einem Kollegen und musst was ändern.
Normalerweise orientiert man sich da erstmal an der Hardware. Also mal nach dem Aktor schauen, der dafür zuständig ist.
Also Schaltplan -> Ausgangsadresse -> TIA -> Querverweis
Hab ich jetzt OOP oder Frameworks, dann heisst das bei Siemens meist tiefverschachtelte Bausteine.
Du musst dich u.U. durch x Ebenen rückwärts hangeln bis du an der richtigten Stelle bist.
Ausser den Querverweisen hast du da kaum Unterstützung. Wenn dann noch eine Visu dabei beteiligt ist, wirds noch komplexer.
Teilweise hab ich da schon mit Microsoft OneNote gearbeitet um da die Verschachtelung und Pfade zu notieren.
Du hast vorher auch mal OPC UA.
Nutzen wir seit ein paar Jahren und bringt für viele Anwendungen Vorteile.
Von Seiten der IT gibt es schon lange die Forderung nach Client auf der SPS und auch nach Methoden.
Mit TIA V15 war das Thema komplex und es gab kaum Tools bei TIA. Für den Client 7 Funktionsbausteine.
Mit TIA 17/18 hat sich einiges getan. Jetzt kann man darüber nachdenken.
Einer meiner "Lebensweisheiten" ist:
"Für jede Aufgabe das richtige Werkzeug einsetzten"
Ein Chiruge operiert auch nicht mit dem Holzfällerbeil
@HansSattel: Denke das du niemanden angegriffen hast und hoff auch nicht das du dich von manchen ”irgendwie“ angegriffen fühlst sowie auch @Larry Laffer schon geschrieben hat, haben manche leider ”schlechte/kontroverse” erfahrungen gemacht.
Auch ich hab da leider sehr viele “negative Erfahrungen” gemacht und leider konnte mir dann jeder nur sagen OOP ist einfach ”geil” aber wenn man dann etwas nachgefragt hat, konnte keiner eine Vernünftige Antwort geben.
@Larry Laffer: das mit dem Ansatz Sinamcis und Movitrac sozusagen 1:1 austauschen find ich auch eine super Idee bzw. hab sowas bei einem Maschinenbauer in gewisser weiße auch schon so ähnlich gesehen. Das könnte man vergleichen mit Interface in der OOP-Welt obwohl ich OOP nur so am ”Rande” kann/verstehe.
@Blockmove: genauso ist es bei fremden Programmen das man sich da durchhangeln muss von der EA-Adresse und das bringt mich bei meinen Programmen auch immer wieder mal zum Grüppeln, soll ich nochmal verschachteln oder doch eine Ebene weniger usw.
@Alle: Egal ob Bier, Gin oder Wein (oder auch Black coffee) reden ist immer gut und ich denke wir haben alle ein gemeinsames Ziel, weil ich denke wenn wir hier so schreiben wir alle ein gewisses Maß an Leidenschaft für die Programmierung haben und einfache und gute Problemlösungen für unsere Automatisierungsaufgaben haben wollen 
!
Auch ich hab da leider sehr viele “negative Erfahrungen” gemacht und leider konnte mir dann jeder nur sagen OOP ist einfach ”geil” aber wenn man dann etwas nachgefragt hat, konnte keiner eine Vernünftige Antwort geben.
@Larry Laffer: das mit dem Ansatz Sinamcis und Movitrac sozusagen 1:1 austauschen find ich auch eine super Idee bzw. hab sowas bei einem Maschinenbauer in gewisser weiße auch schon so ähnlich gesehen. Das könnte man vergleichen mit Interface in der OOP-Welt obwohl ich OOP nur so am ”Rande” kann/verstehe.
@Blockmove: genauso ist es bei fremden Programmen das man sich da durchhangeln muss von der EA-Adresse und das bringt mich bei meinen Programmen auch immer wieder mal zum Grüppeln, soll ich nochmal verschachteln oder doch eine Ebene weniger usw.
Dem kann ich nur 110% zustimmen!!!
Genauso ähnlich war das mit dem TC3.1 projekt obwohl ich nicht beurteilen kann wie sowas tatsächlich in .NET ist.
@Alle: Egal ob Bier, Gin oder Wein (oder auch Black coffee
) reden ist immer gut und ich denke wir haben alle ein gemeinsames Ziel, weil ich denke wenn wir hier so schreiben wir alle ein gewisses Maß an Leidenschaft für die Programmierung haben und einfache und gute Problemlösungen für unsere Automatisierungsaufgaben haben wollen !
- Beiträge
- 12.312
- Reaktionspunkte
- 4.488
Mit den Ebenen ist das so ne Sache. Ich versuche sie bei bestimmten Aufgaben so gering wie möglich zu halten.
Wenn man eine gute Struktur in der Bezeichnung von Symbolen, Variablen, Bausteinen ... hat, dann kann man auch viel mit Copy / Paste und Rename arbeiten. Klar wird der Code dadurch größer und man hat u.U. auch mehr Arbeit, aber eventuell bin ich auch wieder flexibler bei Änderungen. Denn eines habe ich gelernt: Gleiche Einheiten / Stationen gibt es nur im Märchen.
- Beiträge
- 15.091
- Reaktionspunkte
- 3.600
-> Hier kostenlos registrieren
Dem kann ich jetzt nicht unbedingt zustimmen - ich hatte schon mit Maschinen zu tun wo es viele sich identisch wiederholende gleiche Aggregate gab.... Denn eines habe ich gelernt: Gleiche Einheiten / Stationen gibt es nur im Märchen.
- Beiträge
- 11.108
- Reaktionspunkte
- 3.741
Michitronik
Level-2
- Beiträge
- 523
- Reaktionspunkte
- 192
@HansSattel OOP ist halt im Automatisierungsumfeld nicht Prio1 und solange die Voraussetzungen nicht gegeben sind, macht es wenig Sinn eine Implementierung danach anzustreben (aus meiner Sicht).
Aber es könnte nützlich sein und gerade komplexe Systeme eine Struktur und Übersichtlichkeit bieten, die dann bei der Fehlersuche nutzen kann.
Zu oft habe ich aber bisher die Erfahrung gemacht, dass man dann schnell an Grenzen des System stößt, wo man den Weg der OOP verlassen muss um es dann irgendwie doch noch zum laufen zu bekommen.
Es gab in der Vergangenheit schon diverse Versuche und wird es in Zukunft weiter geben.
Dazu kommt, dass viele Anwendungen gerade eben anders Funktionieren, als eine ähnliche andere Anwendung und da ist dann die Frage, ob sich der Aufwand der Abstraktion und Anpassung lohnt.
Ein weiteres Manko sind die aktuellen Tools, die eine OOP Umsetzung eben nicht möglich machen (zumindest nicht durchgängig).
Auch sind die Hersteller abhängigen, systemischen, unterschiedlichen Verhalten schwierig zusammen zu bringen. Treiber Bausteine für jede Hardware und Abstraktion. Austausch von Umrichtern wird dann oft auf Ebene der Telegramm bewerkstelligt. Bei Sensoren wird halt ein fest definierte Anzahl/Typ und/oder bestimmte Hersteller unterstützt.
Die OOP sehe ich am Ehesten im Bereich des Serienmaschinenbaus, aber da muss so schlank wie möglich programmiert werden, damit die kleinst mögliche Steuerung funktioniert und damit Stuckkosten reduziert werden.
Aber es könnte nützlich sein und gerade komplexe Systeme eine Struktur und Übersichtlichkeit bieten, die dann bei der Fehlersuche nutzen kann.
Zu oft habe ich aber bisher die Erfahrung gemacht, dass man dann schnell an Grenzen des System stößt, wo man den Weg der OOP verlassen muss um es dann irgendwie doch noch zum laufen zu bekommen.
Es gab in der Vergangenheit schon diverse Versuche und wird es in Zukunft weiter geben.
Dazu kommt, dass viele Anwendungen gerade eben anders Funktionieren, als eine ähnliche andere Anwendung und da ist dann die Frage, ob sich der Aufwand der Abstraktion und Anpassung lohnt.
Ein weiteres Manko sind die aktuellen Tools, die eine OOP Umsetzung eben nicht möglich machen (zumindest nicht durchgängig).
Auch sind die Hersteller abhängigen, systemischen, unterschiedlichen Verhalten schwierig zusammen zu bringen. Treiber Bausteine für jede Hardware und Abstraktion. Austausch von Umrichtern wird dann oft auf Ebene der Telegramm bewerkstelligt. Bei Sensoren wird halt ein fest definierte Anzahl/Typ und/oder bestimmte Hersteller unterstützt.
Die OOP sehe ich am Ehesten im Bereich des Serienmaschinenbaus, aber da muss so schlank wie möglich programmiert werden, damit die kleinst mögliche Steuerung funktioniert und damit Stuckkosten reduziert werden.
HansSattel
Level-2
- Beiträge
- 10
- Reaktionspunkte
- 7
-> Hier kostenlos registrieren
Dann mag ich auch noch mal meine Erfahrung einbringen.
Der Vorschlag mit dem Tausch von verschiedenen FUs wurde von mir schon so umgesetzt und genau sowas meine ich. Die Verschachtelungstiefe ist immer ein Hinderniss. Ich persönlich begrenze mich hier jedoch nicht zu stark ein. Siemens erlaubt aber eh max. 8 Schachtelungen. Wenn sich bei mir ein Code immer wieder wiederholt, dann mache ich lieber einen FC oder FB raus, dann muss ich Bugs auch nicht an acht Stellen anpassen und habe noch zwei weitere vergessen.
Ich arbeite aktuell bei einem Sondermaschinenhersteller. Ich selber sehe eigentlich eine Standardmaschine aber meine Kollegen sehen eine Sondermaschine. Ich denke dies liegt auch an meiner modularen Denkweise. Die Kundenzufriedenheit sowie die gewonnen Inbetriebnahmezeiten sprechen meist auch für meinen Ansatz. (Entwicklungszeiten von zwei Jahren, benötige ich jedoch vorher auch dafür)
Die Übersichtlichkeit für einen Fremden ist aber auch für mich der größte Nachteil. Alles kann man aber leider nicht haben. So ist es überall. ( Energiewende ohne Windräder, ohne Energie einzusparen)
Daher würde ich dies gerne konstruktiv mit Gleichgesinnten mit einem ähnlichem Wissensstand besprechen.
Framework find ich übrigens auch besser als OOP. Ich habe meine Programm vor dem heutigen Tag übrings auch noch nicht als OO bezeichnet, sondern immer als Modular.
Finde es schon sehr schön, eure Meinungen zu lesen und finde es cool, dass so ein alter Beitrag frischen Wind erleben darf.
Grüße
Hans
Der Vorschlag mit dem Tausch von verschiedenen FUs wurde von mir schon so umgesetzt und genau sowas meine ich. Die Verschachtelungstiefe ist immer ein Hinderniss. Ich persönlich begrenze mich hier jedoch nicht zu stark ein. Siemens erlaubt aber eh max. 8 Schachtelungen. Wenn sich bei mir ein Code immer wieder wiederholt, dann mache ich lieber einen FC oder FB raus, dann muss ich Bugs auch nicht an acht Stellen anpassen und habe noch zwei weitere vergessen.
Ich arbeite aktuell bei einem Sondermaschinenhersteller. Ich selber sehe eigentlich eine Standardmaschine aber meine Kollegen sehen eine Sondermaschine. Ich denke dies liegt auch an meiner modularen Denkweise. Die Kundenzufriedenheit sowie die gewonnen Inbetriebnahmezeiten sprechen meist auch für meinen Ansatz. (Entwicklungszeiten von zwei Jahren, benötige ich jedoch vorher auch dafür)
Die Übersichtlichkeit für einen Fremden ist aber auch für mich der größte Nachteil. Alles kann man aber leider nicht haben. So ist es überall. ( Energiewende ohne Windräder, ohne Energie einzusparen)
Daher würde ich dies gerne konstruktiv mit Gleichgesinnten mit einem ähnlichem Wissensstand besprechen.
Framework find ich übrigens auch besser als OOP. Ich habe meine Programm vor dem heutigen Tag übrings auch noch nicht als OO bezeichnet, sondern immer als Modular.
Finde es schon sehr schön, eure Meinungen zu lesen und finde es cool, dass so ein alter Beitrag frischen Wind erleben darf.
Grüße
Hans
Ich versuche auch nicht zu viele ebenen zu haben, bei den Bezeichnungen etc bin ich auch wieder bei dir aber sobald doch ein gewisser Code sich wiederholt dann versuch ich schon einen FC/FB zu schreiben.Mit den Ebenen ist das so ne Sache. Ich versuche sie bei bestimmten Aufgaben so gering wie möglich zu halten.
Wenn man eine gute Struktur in der Bezeichnung von Symbolen, Variablen, Bausteinen ... hat, dann kann man auch viel mit Copy / Paste und Rename arbeiten. Klar wird der Code dadurch größer und man hat u.U. auch mehr Arbeit, aber eventuell bin ich auch wieder flexibler bei Änderungen. Denn eines habe ich gelernt: Gleiche Einheiten / Stationen gibt es nur im Märchen.
Wichtig wie du auch schreibst ist auch immer eine gewisse ”gleiche” Struktur, Bezeichner etc … das sich dann auch wirklich durch das ganze programm zieht, manche programme “durchblickt” man in ein “paar” tagen und man findet sich immer wieder zurecht bei anderen verzweifelt man einfach nur
da haben wir aber wahrscheinlich alle auch schon das ein oder andere erlebt.Jein zum thema mit den gleichen Einheiten und dem märchen
.Aber du hast auch recht mit der Flexibilität, dann steht man oft vor dem Problem was macht man jetzt, FB erweitern, eine abgewandte version aber ja da gibts auch verschiedene heran gehensweisen und einmal ist das besser oder auch dann wieder was anderes
..
Zuletzt bearbeitet:
- Beiträge
- 12.312
- Reaktionspunkte
- 4.488
@HansSattel
Nachdem du das böse Wort OOP durch Modularität und Framework ersetzt hast, sind wir wahrscheinlich gar nicht soweit auseinander.
Für mich ist wichtig, dass sich die Struktur der Anlage im EPlan und in der SPS wiederspiegelt.
Und genauso wichtig ist mir, dass ich möglichst viel mit Querverweisen finden kann. Das Durchhangeln bei vollparametrierten Bausteinen verlängert oft die Inbetriebnahme. Natürlich steht dies manchmal im Gegensatz zur Modularität. Hier muss man eben abwägen. Durch strukturierte Namen bei Symbolen und Variablen kann man sich da gut helfen. Sind Stationen nur ähnlich aber eben nicht gleich, dann kopiere ich oft Bausteine und arbeite mit Suche und Ersetze. Ich muss nicht krampfhaft voll parametrierbar sein. Aber natürlich hängt da viel vom Aufbau der Anlagen ab. Das Konzept muss zur Anlage passen.
Hat man viel ähnliche Anlagen lohnt es sich mehr Zeit in einen standardisierten Framework zustecken. Ist jede Anlage anders, dann ist ein gerätebezogener Ansatz für FU. Achsen, Regler, … ausreichend.
Nachdem du das böse Wort OOP durch Modularität und Framework ersetzt hast, sind wir wahrscheinlich gar nicht soweit auseinander.
Für mich ist wichtig, dass sich die Struktur der Anlage im EPlan und in der SPS wiederspiegelt.
Und genauso wichtig ist mir, dass ich möglichst viel mit Querverweisen finden kann. Das Durchhangeln bei vollparametrierten Bausteinen verlängert oft die Inbetriebnahme. Natürlich steht dies manchmal im Gegensatz zur Modularität. Hier muss man eben abwägen. Durch strukturierte Namen bei Symbolen und Variablen kann man sich da gut helfen. Sind Stationen nur ähnlich aber eben nicht gleich, dann kopiere ich oft Bausteine und arbeite mit Suche und Ersetze. Ich muss nicht krampfhaft voll parametrierbar sein. Aber natürlich hängt da viel vom Aufbau der Anlagen ab. Das Konzept muss zur Anlage passen.
Hat man viel ähnliche Anlagen lohnt es sich mehr Zeit in einen standardisierten Framework zustecken. Ist jede Anlage anders, dann ist ein gerätebezogener Ansatz für FU. Achsen, Regler, … ausreichend.
- Beiträge
- 25.793
- Reaktionspunkte
- 9.560
-> Hier kostenlos registrieren
Ich möchte auch mal etwas dazu sagen.
Unsere Kunden haben immer alle Programme / Parameterdateien vollständig erhalten. Ich finde das als Hersteller auch fair und sinnvoll.
Produktionsausfälle ( aus welchem Grund auch immer ) kosten viel Geld und wenn ein Instandhalter um 2 Uhr Nachts mit Hilfe des Programmes weiterhelfen kann oder einen Umrichter tauschen kann, dann ist jedem geholfen. Die meisten Maschinen sind auch keine Raketenwissenschaft und bevor jemand ein Programm kopiert und analysiert, da kann er es auch selber schreiben. Ich finde es teils unfair, indem Hersteller ihre Kunden an sich binden (fesseln) und alle Bausteine mit KnowHow Protect schließen. Bei einer Insolvenz des Herstellers ist der Endkunde der Ar**h.
Ich würde jeden Lieferant per Lastenheft ausschließen, der sein Programm nicht abliefert.
Denn => wenn es nachts Probleme gibt und er nichts machen kann, dann klingelt das Telefon....
Wer verschenkt seinen Code? Der Kunde bezahlt dafür und der Programmieraufwand ist in einem Projekt kalkuliert.
Unsere Kunden haben immer alle Programme / Parameterdateien vollständig erhalten. Ich finde das als Hersteller auch fair und sinnvoll.
Produktionsausfälle ( aus welchem Grund auch immer ) kosten viel Geld und wenn ein Instandhalter um 2 Uhr Nachts mit Hilfe des Programmes weiterhelfen kann oder einen Umrichter tauschen kann, dann ist jedem geholfen. Die meisten Maschinen sind auch keine Raketenwissenschaft und bevor jemand ein Programm kopiert und analysiert, da kann er es auch selber schreiben. Ich finde es teils unfair, indem Hersteller ihre Kunden an sich binden (fesseln) und alle Bausteine mit KnowHow Protect schließen. Bei einer Insolvenz des Herstellers ist der Endkunde der Ar**h.
Ich würde jeden Lieferant per Lastenheft ausschließen, der sein Programm nicht abliefert.
Die Instandhalter werden meiner Meinung nach oft unterschätzt. Ich kenne Instandhalter die kennen sich mit Siemens, Beckhoff, Elau, Schneider und Sonderlösungen bestens aus und können blind defekte Siemens / Lauer Panel überspielen/tauschen. Ich bin auch wirklich froh um jeden guten Instandhalter und wenn er interessiert ist zeige ich ihm auch gerne alles mal.
Denn => wenn es nachts Probleme gibt und er nichts machen kann, dann klingelt das Telefon....
- Beiträge
- 12.312
- Reaktionspunkte
- 4.488
Ich würd mal sagen, dass es auch bei Software den Begriff "Nachhaltigkeit" gibt.
Wir haben einen Anlagenhersteller, der seit mehr als 30 Jahren seine Software kontinuierlich weiterentwickelt.
Kennt man eine Anlage mit S5-Steuerung, dann findet man sich auch nach kurzer Zeit in seiner S7-1500 Software zurecht.
Dabei sind das aber keine Spielzeugmaschinen, sondern Maschinen für etwa 1-2 Millionen €.
Das Ganze zahlt sich für ihn als auch für uns als Kunden aus.
Natürlich passt das jetzt absolut zum Klischee des konservativen Maschinenbaus, aber irgendwie gibt ihm der Erfolg recht.
Wir haben einen Anlagenhersteller, der seit mehr als 30 Jahren seine Software kontinuierlich weiterentwickelt.
Kennt man eine Anlage mit S5-Steuerung, dann findet man sich auch nach kurzer Zeit in seiner S7-1500 Software zurecht.
Dabei sind das aber keine Spielzeugmaschinen, sondern Maschinen für etwa 1-2 Millionen €.
Das Ganze zahlt sich für ihn als auch für uns als Kunden aus.
Natürlich passt das jetzt absolut zum Klischee des konservativen Maschinenbaus, aber irgendwie gibt ihm der Erfolg recht.
Das kenn ich auch von einem Maschinenbauer, wenn man mal das system/Struktur verstanden hat findet man sich in jeder Anlage zu recht. Hatte letzes jahr einen kleinen umbau bei einer Maschine aus 2000 war natürlich schon etwas anders weil sich auch die Programmierabteilung weiterentwickelt hat, aber ich fand mich sofort zurecht.
Und sowas ist für mich absolute Spitzenklasse und hab davor absolut höchsten Respekt. Auch wenn natürlich der Maschinenaufbau doch immer sehr Ähnlich ist und auch die Produkte am Ende immer irgendwie ”gleich” sind. Das ist wahrscheinlich bei anderen nicht immer so einfach, aber auch da gibts möglichkeiten mit ”Styleguides” etc eine gewisse linie rein zubringen.
Alles irgendwie immer ein ständiger Prozess, vor kurzen hab ich mal wieder ein Programm aus meiner anfangszeit vor gut über 10 jahren in die hand gekriegt und naja vieles würd ich jetzt definitiv anders machen
Und sowas ist für mich absolute Spitzenklasse und hab davor absolut höchsten Respekt. Auch wenn natürlich der Maschinenaufbau doch immer sehr Ähnlich ist und auch die Produkte am Ende immer irgendwie ”gleich” sind. Das ist wahrscheinlich bei anderen nicht immer so einfach, aber auch da gibts möglichkeiten mit ”Styleguides” etc eine gewisse linie rein zubringen.
Alles irgendwie immer ein ständiger Prozess, vor kurzen hab ich mal wieder ein Programm aus meiner anfangszeit vor gut über 10 jahren in die hand gekriegt und naja vieles würd ich jetzt definitiv anders machen