Codegenerierung in der Praxis

[Faceman]

Zuviel Werbung?
-> Hier kostenlos registrieren

Meine Erfahrung aus 30 Jahren Programmierung, den größten Mist liefern die Programmierer ab, die sich für etwas besseres halten. Die kommen mit niemanden klar,
keiner will mit ihnen was zu tun haben geschweige denn auf Montage fahren und sie liefern für einfachste Aufgaben einen Hochsprachencode ab, den sie nach 3 Monaten
selber nicht mehr lesen können.

Da lobe ich mir die bescheidenen, beständigen und auf dem Boden gebliebenen Programmierer, egal in welcher Sprache sie abliefern

Danke

 

[Ralle]

Um Jesu Willen, ich suche doch gerade die offene Diskussion ? Dafür sitzen wir ja hier ?



Leider völlig falsch. Ich komme von der Feldseite her. War Azubi im Schaltschrankbau und habe selber ganze Anlagen verdrahtet bevor ich mich für das Studium der Elektrotechnik entschieden habe.

Na dann, ;-) Muß ich das wohl zurücknehmen.
Also, immer Alles so simpel wie möglich halten, was natürlich nciht immer möglich ist!

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Draco

SCL ist ein Glaubenskrieg. Da will ich eigentlich gar nicht darüber diskutieren.
Wir haben für uns entschieden, dass wir keine Programme komplett in SCL zulassen.
Ganz einfach runtergebrochen: Was sich bewegt wird in FUP oder Graph programmiert.
Berechnungen und Datenverarbeitung in SCL.

Natürlich macht es Sinn, die Ansteuerung einer Achse oder eben eines Prop-Ventils in einen FB zu packen.
Letztlich hat man da eine überschaubare Anzahl von Parametern.

Auf der anderen Seite kann man auch einen Codegenerator schreiben, der einen KOP/FUP-Baustein mit E/A-Adressen erzeugt.
An sowas hat ein Fördertechnik-Lieferant von uns mal gearbeitet.
Für den Anwendungsfall fand ich das eine klasse Lösung.

Gruß
Blockmove

 

[Draco Malfoy]

die sich für etwas besseres halten ... Danke

Wie immer, sobald die Sachargumente ausgehen, beginnen die persönlichen Angriffe.

SCL ist ein Glaubenskrieg. Da will ich eigentlich gar nicht darüber diskutieren.

Diesen Glaubenskrieg habe ich doch gar nicht beginnen wollen.

Ganz einfach runtergebrochen: Was sich bewegt wird in FUP oder Graph programmiert.
Berechnungen und Datenverarbeitung in SCL.

Das habe ich doch 5 oder 6 mal ungefähr so auch geschrieben.

Wir haben für uns entschieden, dass wir keine Programme komplett in SCL zulassen.

Würde ich auch nicht machen. S. Beispiel Procter & Gamble. Mit deren Standard kommt niemand zurecht. Das gesamte Programm in SCL, Schritte werden fix codiert, also Zylinder soundso öffnet von Schritt 9 bis Schritt 12. Weiter brauche ich gar nicht auszuführen.

S. mein Beitrag oben:

generell laufen die Schrittketten im GRAPH und alles wo EA-Variablen direkt beschaltet werden, in KOP.

Das Thema was ich gerne diskutieren möchte, ist weiterhin ein Framework und ggf. automatische Codeerzeugung auf Basis von abgeschlossenen Librarys. Ich möchte hier weder Glaubenskriege losbrechen noch die persönlichen Qualitäten irgendwelcher Besserwisser-Programmierer, die dem Facemann auf seinem 30 jährigen steinigen Pfad im Dienste der Automatisierung begegnet sind, diskutieren.

So ähnlich also wie PCS7, nur für den Maschinenbau, und ohne CFC dafür aber mit GRAPH.

 

[Faceman]

Wie immer, sobald die Sachargumente ausgehen, beginnen die persönlichen Angriffe.

Ich versteh deine Antwort nicht. Ich schrieb über Programmierer, die sich für etwas besseres halten, mit denen niemand etwas zu tun haben will...
Warum denkst du das ich dich damit gemeint habe, wo steht da dein Name? Oder fühlst du dich angesprochen. Ja dann entschuldige ich mit herzlich.
Ich habe nicht dich gemeint

Meine Erfahrung aus 30 Jahren Programmierung, den größten Mist liefern die Programmierer ab, die sich für etwas besseres halten. Die kommen mit niemanden klar,
keiner will mit ihnen was zu tun haben geschweige denn auf Montage fahren und sie liefern für einfachste Aufgaben einen Hochsprachencode ab, den sie nach 3 Monaten
selber nicht mehr lesen können.

Da lobe ich mir die bescheidenen, beständigen und auf dem Boden gebliebenen Programmierer, egal in welcher Sprache sie abliefern

Danke

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Thema was ich gerne diskutieren möchte, ist weiterhin ein Framework und ggf. automatische Codeerzeugung auf Basis von abgeschlossenen Librarys.

Bosch Atmo hat genau sowas für Maschinenbau auf Codesys-Basis

https://www.bosch-connected-industry.com/connected-manufacturing/nexeed-automation/

Erstellt dir das komplette Programmgerüst, Betriebsarten, Handbetrieb, Fehlermeldungen, Visualisierung.
Du musst nur noch Freigaben und Verriegelungen ausprogrammieren.
Das System ist komplett auf die Boschanforderungen zugeschnitten und meines Erachtens überzogen.

Mir persönlich gefällt der Librarys-Ansatz nicht so ganz.
Pack man alle relevanten Funktionen in Bibliotheksbausteine, dann wird es sehr schnell auf grund der Parameter unübersichtlich.
Ein Codegenerator auf Basis von Biblitheken UND Bausteintemplates würde mir deutlich besser gefallen.

Gruß
Blockmove

 

[Draco Malfoy]

Mir persönlich gefällt der Librarys-Ansatz nicht so ganz.
Pack man alle relevanten Funktionen in Bibliotheksbausteine, dann wird es sehr schnell auf grund der Parameter unübersichtlich.
Ein Codegenerator auf Basis von Biblitheken UND Bausteintemplates würde mir deutlich besser gefallen.

Ich rede definitiv nicht davon, ALLE Funktionen in Librarys zu verpacken. Abläufe sind spezifisch - die kann man nicht in eine Library verpacken.

Ein vernünftiger Ansatz ist im VASS realisiert worden, auch wenn in der Umsetzung vieles extrem unglücklich gelaufen ist. Da sieht man auch, was passiert, wenn man S5 Programmierer an SCL Librarys dran setzt.

Ich denke mal, sinnvollerweise sollte folgendermaßen vorgegangen werden:

Es wird eine Maschineneinheit - Beispiel Ventil, oder eine Gruppe Ventile oder ein Zylinder oder ein Vacuuminjector usw. erkannt. Daraufhin packt mir mein Codegenerator alle Typicals für die Geräte der Gruppe =OBERTISCH in einen entsprechenden Aufruf mit Sybmbolik =OBERTISCH und erzeugt eine Visu-Seite OBERTISCH wo diese Typicals ihre Faceplates haben.

Würde schon mal einen Haufen Arbeit ersparen. Viel mehr müsste eigentlich auch gar nicht sein. Natürlich erwarte ich dann, daß der Aufruf eines Ventils =OT+5200MJ02-200PV128 entsprechend am Baustein korrekt parametriert ist, daß AW und QW korrekt durchverdrahtet sind, Faceplates in der VISU richtig angebunden sind, und so weiter. Wenn der Generator statt eines Ventils einen RFID-Reader vorfindet, dann soll er natürlich analog verfahren.

Dann soll mir der Generator noch die grundlegenden VISU-Bilder mit einer Menüstruktur, und je ein Gruppenbild innerhalb der entsprechenden Bilderhierarchie erzeugen. Das reicht mir dann schon vollkommen. Alles andere kann ich dann nach Bedarf händisch erledigen.

Voraussetzungen:

- Ich habe eine Library mit den Typicals für jede Art der eingestezten Hardware;
- Ich habe Typicals für die Bildung von Betriebsarten, für die Versorgung der VISU-Anzeige, für die Diagnose von PROFINET usw.;
- Die Typicals haben definierte Faceplates;
- Der Codegenerator kennt meine Typicals und die Faceplates, weiß damit umzugehen, und vermag aus dem EPLAN die nötigen Basis-Informationen herauszulesen.

Was Alarme angeht: Hardware-bezogene Alarme (Ventil schaltet nicht richtig) werden direkt aus dem Baustein erzeugt. BMK nimmt der FB aus der Aufruf-Parametrierung, und arbeitet mit dem bausteinbezogenen Meldeverfahren mit mehrsprachigen Text-Librarys. Ablaufmeldungen kommen aus dem Graph (Verriegelung fehlt, Supervision angesprochen usw.) und alle sonstigen Prozess-Meldungen kann ich flexibel mit PRODIAG projektabhängig parametrieren.

80% der fehlerträchtigen Tipp-Arbeit und Copy-Paste Fehler wäre bei diesem Verfahren erspart. Erleichternd hinzu käme noch eine einheitliche Benennung der Module und Objekte innerhalb der Anlage, die von allen Gewerken gleich benutzt wird und sich im EPLAN so wiederfindet.

 

[Blockmove]

@Draco
Ich kann mir vorstellen was du meinst und natürlich kann man sowas umsetzen.
Alleine schon das korrekte „Verdrahten“ spart viel Zeit.
Bleibt die Frage: Für wen willst du sowas machen?
In sowas stecken Mannjahre.
Von Support und Pflegeaufwand gar nicht zu reden.
Als Community-Projekt kann man sowas auch kaum umsetzen.
Dafür gehen die Vorstellungen der SPSler zu weit auseinander.

Just my 2Cents

Blockmove

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich könnte mir auch eine Codeerzeugung vorstellen, die auf Bausteintemplates aufbaut und ein Grundgerüst erzeugt. Aber auch da ist noch viel Handarbeit angesagt.
Wir haben ein System, das rel. viel mit Array arbeitet, so dass man auch Programmteile aus einer Station in eine andere kopieren kann, der Stationsindex ist dort anders, fertig.
Ein Servo ist so in 10 Minuten umkopiert und angepaßt, mun muß aber schon ein wenig davon wissen.
Aber Graph etc. programmieren wir in der Regel eh immer neu aus, bzw. man sucht sich eine Station, die schon in die richtige Richtung geht. Ist halt wirklich Sondermaschinenbau.
Bibliotheken mag ich eher nicht, schon gar nicht kopiergeschützt, aber die paar Bausteine, die wir so brauchen, die kann man noch so handeln.

 

[Draco Malfoy]

@Draco
Ich kann mir vorstellen was du meinst und natürlich kann man sowas umsetzen.
Alleine schon das korrekte „Verdrahten“ spart viel Zeit.
Bleibt die Frage: Für wen willst du sowas machen?

Ich denke mal, der Knackpunkt ist das Herauslesen der Daten aus dem EPLAN. In allen Systemen die ich bisher kenne, ob COMOS oder CS-Tool oder "Selbstgebaschteltes", wird jeweils entweder eine komplett andere Plattform wie EPLAN oder irgendwelche Excell-Tabellen bzw. Interfaces bemüht, wo ich die gewünschte Konfiguration händisch eintragen muss.

Heißt, einer sitzt da, und tippt dann aufwändig ab, was im EPLAN schon vorhanden ist. Das EPLAN kann aber so zwischen 1000 und 10 000 Seiten haben. Es muss doch irgend einen Weg geben, die Schnittstelle zu EPLAN soweit zu rationalisieren, daß die Basisc von dort von alleine rüberwandern. Ich empfinde das immer als den mühsamsten Punkt des gesamten Projekt-Setup => Die EPLAN-Welt in die SPS-Welt zu übertragen.

Bibliotheken mag ich eher nicht, schon gar nicht kopiergeschützt, aber die paar Bausteine, die wir so brauchen, die kann man noch so handeln.

Das möchte ich ehrlich gesagt net kommentieren, auch wenn man dazu sicherlich einiges sagen könnte. Know-How geschützte Bibliotheken ohne ausreichende Beschreibung und klare Abhängigkeitsstrukturen sind ein Fluch, aber das genrelle Ablehnen des Bibliothekskonzepts kann für mich keine rationalen sondern ausschließlich religiöse Gründe mitbringen. (Kopiergeschützte und Know-How-geschützte Bibliotheken sind im übrigen verschiedene Paar Schuhe.). Aber ich sag da an der Stelle besser gar nichts.

 

[Blockmove]

Ich denke mal, der Knackpunkt ist das Herauslesen der Daten aus dem EPLAN. In allen Systemen die ich bisher kenne, ob COMOS oder CS-Tool oder "Selbstgebaschteltes", wird jeweils entweder eine komplett andere Plattform wie EPLAN oder irgendwelche Excell-Tabellen bzw. Interfaces bemüht, wo ich die gewünschte Konfiguration händisch eintragen muss.

Heißt, einer sitzt da, und tippt dann aufwändig ab, was im EPLAN schon vorhanden ist. Das EPLAN kann aber so zwischen 1000 und 10 000 Seiten haben. Es muss doch irgend einen Weg geben, die Schnittstelle zu EPLAN soweit zu rationalisieren, daß die Basisc von dort von alleine rüberwandern. Ich empfinde das immer als den mühsamsten Punkt des gesamten Projekt-Setup => Die EPLAN-Welt in die SPS-Welt zu übertragen.

Je universeller dein Framework sein soll, umso schlechter ist ein Import aus EPlan möglich.
Dafür gibt es schlichtweg zu viele Möglichkeiten ein EPlan-Projekt zu strukturieren.
Bei EPlan würde ich mich mal nur auf BMK, Adresse und Kommentar beschränken.

 

[Draco Malfoy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Je universeller dein Framework sein soll, umso schlechter ist ein Import aus EPlan möglich.
Dafür gibt es schlichtweg zu viele Möglichkeiten ein EPlan-Projekt zu strukturieren.
Bei EPlan würde ich mich mal nur auf BMK, Adresse und Kommentar beschränken.

Was hindert mich daran, Makros, die importfähig sein sollen, in bestimmter Form anzulegen, sodaß ein externer Codegenerator, der darüber läuft, sie zählen und belangreiche Informationen daraus extrahieren kann.

Wie gesagt: Es geht mir net darum, die Welt zu retten. Ich denke hier an Metallverarbeitung, Montage- und Transferlinien, Verpackungsindustrie, Handling-Automation. Also da, wo man das am ehesten sinnvoll nutzen kann. Zusammen mit bestimmten Vorgaben für die EPLAN-Welt ist das doch wunderbar umsetzbar. Ich meine, EPLAN ist eh sehr individuell, nur vollkommene Idioten nutzen da die Makros aus dem Data-Portal. Daher ist eine Anpassung nach Vorgaben im Zuge einer "Automatisierung der Automatisierung" eigentlich nichts weltbewegendes.

 

[Blockmove]

Das Thema EPlan schätz ich schwieriger ein als TIA.
Eplan Struktur und Makros so anzupassen, dass der Codegenerator dami zurecht kommt,
kann recht aufwendig sein und Viele abschrecken.

 

[Draco Malfoy]

Das Thema EPlan schätz ich schwieriger ein als TIA.
Eplan Struktur und Makros so anzupassen, dass der Codegenerator dami zurecht kommt,
kann recht aufwendig sein und Viele abschrecken.

Alles andere wäre allerdings wieder mit einer erheblichen Verminderung des schlußendlichen Nutzens des Produkts verbunden. Dann müsste dann wieder jemand sitzen und abtippen, dann womöglich auch noch aus einem PDF-Plan heraus.

Andererseits haben einige Firmen ihre E-Pläne bereits heute weitestgehend automatisiert - mit solchen Features wie Optionshandling, EPLAN-Cogineere, Schnittstellen zur SAP, verschienenen VBS-Makros und kruden Excell-Tabellen usw.

Warum dann also nicht den nächsten Schritt gehen und die Makros für die Codeerzeugung aufbereiten. Letzen Ende muss es ja nur

1) Generierung der HW-Config aus EPLAN geben (funtioniert und existiert heute schon),
2) Übernahme der BMKs und Adressen in die Symboltabelle (tut es auch schon mehr oder weniger überall) und
3) Erkennung von bestimmten Geräten wie RFID-Reader, Prop-Ventile, Pneumatik-Zylinder usw.

Weitere Möglichkeiten gibt es noch mit Tools wie FESTO Schematic Solution etc. die ihre Daten direkt ins EPLAN schmeißen.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Alles andere wäre allerdings wieder mit einer erheblichen Verminderung des schlußendlichen Nutzens des Produkts verbunden. Dann müsste dann wieder jemand sitzen und abtippen, dann womöglich auch noch aus einem PDF-Plan heraus.

Andererseits haben einige Firmen ihre E-Pläne bereits heute weitestgehend automatisiert - mit solchen Features wie Optionshandling, EPLAN-Cogineere, Schnittstellen zur SAP, verschienenen VBS-Makros und kruden Excell-Tabellen usw.

Warum dann also nicht den nächsten Schritt gehen und die Makros für die Codeerzeugung aufbereiten. Letzen Ende muss es ja nur

1) Generierung der HW-Config aus EPLAN geben (funtioniert und existiert heute schon),
2) Übernahme der BMKs und Adressen in die Symboltabelle (tut es auch schon mehr oder weniger überall) und
3) Erkennung von bestimmten Geräten wie RFID-Reader, Prop-Ventile, Pneumatik-Zylinder usw.

Weitere Möglichkeiten gibt es noch mit Tools wie FESTO Schematic Solution etc. die ihre Daten direkt ins EPLAN schmeißen.

So eine Argumentation höre ich sonst immer zum Thema I4.0 und IIoT
Am Ende beißt sich dann die SAP-Integration mit deinem Codegenerator.
Spaß beiseite:
So ein Tool muss hochgradig modular sein.
X Eingabeschnittstellen und Y Ausgaben.
Aber das ist genauso Marketinggeschwätz

 

[Ralle]

Und dann kommt die nächste Eplan-Version und man hat eine Kleinigkeit geändert und der Urheber des Tools ist nicht da, noch schlimmer nicht mehr da...
Und garantiert -- Dann kommt, wie nun jedes Jahr eine neue TIA-Version und Siemens hat ganz viel geändert.

Ich glaube, um so viel Zeit und Arbeit zu inverstieren, ist das nicht zukunftssicher genug. Das muß man ständig dran rumfrickeln.

 

[Blockmove]

Ich sehe hier den Pflege- und Supportaufwand letztlich höher als den eigentlich Entwicklungsuafwand

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich sehe hier den Pflege- und Supportaufwand letztlich höher als den eigentlich Entwicklungsuafwand

und vor Allem u.U. höher als der Nutzen

 

[winnman]

Listen aus EPlan bekommt man in jeder Art und Weise.

Ein bisschen mit Excel optimieren und dann ist die Symbolik fertig.

Wenn dann ein Codegenerator da ist, sollte sich der auch mit diesen Listen (ev. paar Spalten händisch bearbeiten die so Infos wie Hydraulikzylinder 1, Motor, . . . enthalten) ja auch unabhängig von Eplan und TIA, . . . füttern lassen.

Da sollte dann die Versionsproblematik auf beiden Seiten keine Rolle spielen.

Ich hab keine Anlagen die solche Dimensionen annehmen, dass ich an einen Codegenerator dächte.

 

[Blockmove]

und vor Allem u.U. höher als der Nutzen

Der Nutzen ist meines Erachtens eindeutig gegeben.
Aber:
Daraus ein tragfähiges Geschäftsmodell zu machen, stelle ich mir sehr schwierig vor.
Wenn ein Konstruktionsbüro so eine Lösung für den internen Gebrauch entwickelt, dann macht das richtig Sinn.
Es spart Zeit und Aufwand und man kann das Tool genau an die Bedürfnisse und Arbeitsweise anpassen.
Am Markt muss man daraus die eierlegende Wollilchsau machen, und das bedeutet wieder viele Einschränkungen.
Spannend aber schwierig.

Gruß
Blockmove