Codegenerierung in der Praxis

lu.koerfer

Level-1
Beiträge
5
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich wollte mal fragen, wer hier bereits Erfahrungen mit Codegenerierung für SPS-Umgebungen gesammelt hat und welche Erkenntnisse dabei gesammelt werden konnten. Am interessantesten wären natürlich Berichte über einen praktischen Einsatz, aber auch falls jemand nur ein wenig experimentiert hat, würde ich gerne davon erfahren

Für welchen Umgebungen (bspw. TIA) wurde generiert?
Welche Komponenten (bspw. Programmbausteine, Datentypen, Variablentabellen) eines SPS-Programms wurden generiert?
Mit welchen Technologien (bspw. T4-Templates) wurde gearbeitet?
Wie sieht das Ursprungsformat der Daten aus?
Welches Format (bspw. XML oder direkt Code) wird für die entsprechende Umgebung benötigt?

Um den Anfang zu machen:
Mein Interesse rührt daher, dass im Rahmen meiner Hiwi-Tätigkeit vor einiger Zeit Code-Generierung mit dem TIA-Portal am Rande Thema war. Ich persönlich habe nur minimale Erfahrungen mit der Programmierung von speicherprogrammierbaren Steuerungen (TIA und PC Worx), programmiere jedoch schon seit langer Zeit für Hochsprachen. In diesem Kontext kenne ich auch ein paar Aufgabengebiete und Methoden der Codegenerierung (HTML-Templates und Java Annotation Processing). Daher und aufgrund der Tatsache, dass TIA offensichtlich zu genau diesem Zweck die Openness API anbietet, wollte ich mal fragen inwiefern diese oder andere Werkzeuge bereits Anwendung finden oder ob da Potential gesehen wird.

Viele Grüße,
Lukas
 
Viele Details kann ich leider nicht mitteilen, da das ganze schon ein paar Jahre zurückliegt. Bei der Harro Höfliger wurden PacDrive M Steuerungen eingesetzt, die E-Konstruktion erfolgte mit EPlan. Sobald die EKON fertig war hat diese ein Makro gestartet das ein Grundgerüst der Software erzeugt hat, dass dann von uns Programmiereŕn weiter mit Leben gefüllt wurde.

Von irgendwas mit Internetzugang gesendet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Viele Details kann ich leider nicht mitteilen, da das ganze schon ein paar Jahre zurückliegt. Bei der Harro Höfliger wurden PacDrive M Steuerungen eingesetzt, die E-Konstruktion erfolgte mit EPlan. Sobald die EKON fertig war hat diese ein Makro gestartet das ein Grundgerüst der Software erzeugt hat, dass dann von uns Programmiereŕn weiter mit Leben gefüllt wurde.

Von irgendwas mit Internetzugang gesendet.

Ja, solche "Tools" haben viele große Firmen... ob nun direkt aus EPLAN oder aus ner Excelliste...

aber:

- das Erstellen/Pflege/Wartung von dem Tool dauert auch (viel) Zeit, grad bei TIA mit Openess bist da bei jeder neuen TIA Version am rumändern
- das funktioniert nur, wenn man seinen eigenen Standard auch einsetzen darf, wenn der Endkunde nen anderen "Programmierstandard" fordert, dann gehts halt nicht
- ich programmiere ja nicht bei jedem Projekt händisch jede einzelne Codezeile neu, sondern kopiere das Projekt von nem früheren ähnlichen, bzw. einzelne Bausteine. Von daher ist die Zeitersparniss der autom. Codegenerierung nicht so hoch wie man glauben mag


Also lange Rede kurzer Sinn, ich halte nicht viel davon... Weils einfach in der Praxis meist nicht soo viel Zeitersparnis bringt...
 
Codegenerierung für SPS-Umgebungen? Gehören NCs noch zur SPS-Umgebung?
Das skurrilste und überflüssigste Programm, das ich je geschrieben habe (weil auf ausdrücklichen KundenWunsch), war ein ProgrammGenerator programmiert in und zur Erzeugung von "G-Code" einer Siemens NC (880M).

Mit einem ProgrammGenerator Code für eine SPS zu erzeugen finde ich auch nicht sehr sinnvoll.
Aus ePlan-Daten oder vergleichbarem eine E-/A-Belegung zu zaubern, mag noch angehen, wenn die in ePlan verwendeten Bezeichnungen "brauchbar" sind - also eine Vorlage für Deklarationen?
Um "wirklichen" Code (ausführbare Anweisungen) zu produzieren, was könnte dafür ausgewertet werden? Ich weiss es nicht.
Will man anhand der BestellBezeichnungen der verwendeten FrequenzUmrichter und der Massstäbe/DrehGeber schon eine Auswahl aus zur Verfügung stehenden FCs/FBs und aus in Frage kommenden Fehlermeldungen treffen? Hilft es wirklich, die Anzahl der Achsen und HilfsAchsen zu kennen, um automatisiert ein SPS-Programm anhand solch viel zu spärlicher Kriterien zuzubereiten?
Selbst wenn man nur SonderMaschinen baut, hat man seine Software doch meistens so angelegt, dass sich vieles durch Parametrierung konfigurieren lässt.
Es gibt normalerweise nicht so vieles, das einfach nach "Schema F", ohne Handarbeit (und ohne Kopfarbeit!) erledigt werden kann.

Ein wenig "off Topic", aber ich finde durchaus vergleichbar:

Auf Anregung meiner Mechanik-/HydraulikKollegen habe ich mal in Excel einen "SchmierPlanGenerator" gebastelt, der sich aus den StückListen ernährte.
Die Idee fand ich gar nicht schlecht, aber wenn sich partout kein SachKundiger findet, der bereit wäre, etwas Grips und PflegeArbeit zu investieren . . .
Excel war fertig und bestens getestet. Die PflegeArbeiten hätten im TeileStamm der Datenbank stattfinden müssen - also genau da, wo die Kollegen ohnehin oft bis ständig tätig waren - in gewohnter Umgebung und nicht in Excel. Aber nichtsdestotrotzig - Projekt schnellstens gestorben.

Ferner: ein ErsatzteilPaketGenerator, der sich aus StückListen ernährt. Die Idee war von den Mechanikern in Excel umgesetzt worden und ich habe sie für die Elektrik angepasst.
Auch hier dasselbe Problem: diejenigen, die das KnowHow haben, sind bis über beide Ohren mit Arbeit zugeschüttet und können sich nicht um die Pflege des Systems kümmern und andere sollten tunlichst die Finger davon lassen.

Gruss, Heinileini
 
Mit einem ProgrammGenerator Code für eine SPS zu erzeugen finde ich auch nicht sehr sinnvoll.
Aus ePlan-Daten oder vergleichbarem eine E-/A-Belegung zu zaubern, mag noch angehen, wenn die in ePlan verwendeten Bezeichnungen "brauchbar" sind - also eine Vorlage für Deklarationen?
Um "wirklichen" Code (ausführbare Anweisungen) zu produzieren, was könnte dafür ausgewertet werden? Ich weiss es nicht.

Naja, theoretisch geht das schon... Bei PCS7 wirds ja auch irgendwie mit den Musterplänen + Excelliste gemacht...

wenn Du weisst, dass Du 50 Pt100 Temperatursensoren hast, kannst Du ja auch den SPS-Code + Visubildvorlage dafür erstellen... Nur spart man dadurch nicht viel Zeit. Wenn ich das händisch mache, tippe ich den Code nämlich nicht 50mal, sondern nur 1 mal und kopiere ihn 49 mal und ändere Kleinigkeiten ab...

Gruß.
 
Also lange Rede kurzer Sinn, ich halte nicht viel davon... Weils einfach in der Praxis meist nicht soo viel Zeitersparnis bringt...

Das mit der Zeitersparnis kommt darauf an was alles automatisiert erzeugt wird. Bei Harro Höfliger ist praktisch keine Anlage gleich und das Makro erzeugt auch gleich die Hardwarekonfig benennt die Variablen passend inklusive BMKs und die FBs erhalten schon alle benötigten IOs.

Von irgendwas mit Internetzugang gesendet.
 
Aber bei den bisher genannten Ansätzen bezieht sich die Generierung immer auf die Verbindung mit Komponenten der Feldebene, oder? Sprich es werden Hardware-Konfigurationen, Variablentabellen und ggf. Baustein-Gerüste generiert, damit die Komponenten sofort so angesteuert werden können wie zuvor geplant. Oder betrifft die Generierung auch die Ablauflogik der Programme?

Ich kann mir leider unter den bisherigen Berichten nicht besonders viel vorstellen, da mir schlicht und einfach auch die Erfahrung fehlt. Meine SPS-Programmiererfahrungen waren kleine Anlagen, die ausschließlich in einem akademischen und keinesfall in einem produktiven Kontext eingesetzt wurden. Also nach dem Motto "Schließt mal Umrichter, Sensoren und Greifer irgendwie an und schreibt nen kleines Programm, damit dies und das passiert". Also nichts in Richtung Eplan etc.

Was die von uns untersuchte Generierung betrifft, ging es konkret um die Übertragung von verschiedenen Modellen zur Ablaufbeschreibung (bspw. UML, endliche Automaten) in ein SPS-Programmgerüst. Ich nehme an, dass das an der Realität komplett vorbei geht, dennoch wollte ich mal in Erfahrung bringen, wie diese Realität denn konkret aussieht. Und vielleicht auch welches Potenzial gesehen wird. Die Tatsache, dass bspw. Siemens mit der Openness API eine Schnittstelle anbietet, zeigt ja, dass zumindest von Herstellerseite (ein bisschen was) getan wird.

Ich erkenne auch, was ich mir ohnehin schon ein wenig dachte, dass in diesem Bereich so ziemlich jeder für sich bleibt, eben da auch jeder die eigenen Abläufe und Vorgaben definiert. Es existieren keine Werkzeuge, die man dann an die eigenen Bedürfnisse anpassen kann, sondern, wenn überhaupt, wird die Funktionalität ein wenig zusammen gehackt (Excel, Skripte, etc.). Da stellt sich dann die Frage, ob solche Werkzeuge nicht sinnvoll sein könnten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aber bei den bisher genannten Ansätzen bezieht sich die Generierung immer auf die Verbindung mit Komponenten der Feldebene, oder? Sprich es werden Hardware-Konfigurationen, Variablentabellen und ggf. Baustein-Gerüste generiert, damit die Komponenten sofort so angesteuert werden können wie zuvor geplant. Oder betrifft die Generierung auch die Ablauflogik der Programme?
Jein, ja es geht bei dem von mir geschilderten Ansatz unter anderem um die Verbindung mit Komponenten der Feldebene. Da keine Maschine bei diesem Kunden gleich war wurde in den oberen Ebenen lediglich das Bausteingerüst erstellt, was wir dann mit Leben füllen mussten. Bei Grundkomponenten wie z.B. Ventilen wird allerdings auch die Logik vom Makro generiert.
Ich kann mir leider unter den bisherigen Berichten nicht besonders viel vorstellen, da mir schlicht und einfach auch die Erfahrung fehlt. Meine SPS-Programmiererfahrungen waren kleine Anlagen, die ausschließlich in einem akademischen und keinesfall in einem produktiven Kontext eingesetzt wurden. Also nach dem Motto "Schließt mal Umrichter, Sensoren und Greifer irgendwie an und schreibt nen kleines Programm, damit dies und das passiert". Also nichts in Richtung Eplan etc.
Gut, bei so kleinen und nur vereinzelt zu erstellenden Anlagen wird sich der Aufwand den man betreiben muss ehe die einzelnen Lösungen laufen nur lohnen, wegen des möglichen Lerneffekts. Bei Serienanlagen wird man, wie ducati schon vorgeschlagen hat, eher ein altes Projekt als Vorlage nehmen.
Was die von uns untersuchte Generierung betrifft, ging es konkret um die Übertragung von verschiedenen Modellen zur Ablaufbeschreibung (bspw. UML, endliche Automaten) in ein SPS-Programmgerüst. Ich nehme an, dass das an der Realität komplett vorbei geht, dennoch wollte ich mal in Erfahrung bringen, wie diese Realität denn konkret aussieht. Und vielleicht auch welches Potenzial gesehen wird. Die Tatsache, dass bspw. Siemens mit der Openness API eine Schnittstelle anbietet, zeigt ja, dass zumindest von Herstellerseite (ein bisschen was) getan wird.
Wieso soll das an der Realität vorbeigehen? Es ist, wie Du ja selber festgestellt hast, Realität, allerdings, man möge mich korrigieren wenn ich hier falsch liege, noch nicht so sehr verbreitet. Für Beckhoff TwinCAT V3 gibt es zum Beispiel eine Erweiterung zum Erstellen von UML-Diagrammen aus denen dann Code generiert wird, allerdings ist das dann auch nur ein Gerüst.
Ich erkenne auch, was ich mir ohnehin schon ein wenig dachte, dass in diesem Bereich so ziemlich jeder für sich bleibt, eben da auch jeder die eigenen Abläufe und Vorgaben definiert. Es existieren keine Werkzeuge, die man dann an die eigenen Bedürfnisse anpassen kann, sondern, wenn überhaupt, wird die Funktionalität ein wenig zusammen gehackt (Excel, Skripte, etc.). Da stellt sich dann die Frage, ob solche Werkzeuge nicht sinnvoll sein könnten.
Wie kommst Du jetzt wieder drauf? Das EPLAN Paket ist ein allgemeines Werkzeug, dass aber für die eigenen Bedürfnisse natürlich angepasst werden muss.

Von irgendwas mit Internetzugang gesendet.
 
Bei SSI Schäfer wird eine ganze Födertechnik-Anlage aus einem Code-Generator, genannt CS Tool, erstellt. Händische Nacharbeit ist danach kaum bis gar nicht mehr notwendig (nur an schwierigen Stellen).

Wieso soll eine automatische Codegenerierung denn nicht sinnvoll sein ? Sie ist in den Branchen, wo sie Sinn macht, absolut sinnvoll, und wird auch zunehmend angewendet. Auch wenn ich persönlich nichts davon halte, Entwicklung zu machen, bloß um bestehende Systeme (Comos + pcs7) unzulänglich nachzubauen.

Die Automatische Kodegenerierung bietet sich dort an, wo Massenverarbeitung angesagt ist, und der Anteil der händischen Anpassungen dabei klein ist, wobei auch die Komponenten alle aus einem bestimmten zuvor definierten Frame kommen. Anderes Beispiel in diese Richtung ist VASS.

Wo das definitiv ein absoluter Blödsinn ist - zu versuchen, Stand-Alone Anlagen in der verarbeitenden Industrie mit jedes Mal erheblichem Spezialbedarf, Maßanfertigung und weiteren spezifischen UnicSellingPoints und dazu noch womöglich unter Mitspracherecht des Endkunden in der Auswahl der Komponenten über irgendwelche Code-Generatoren abzubilden.

Das hat eine gewisse Spritzgussmaschinen-Automation Firma aus dem süddeutschen Raum nach 2Mio€ Schaden und einem herausgeworfenen Apologeten dieser Irrsinnsideen auch vor kurzem erfahren. Der Unternehmensruin konnte durch finanzielle Zuwendungen der Muttergesellschaft gerade noch abgewendet werden.

Aber da man natürlich nicht aus den Fehlern lernen soll, wird jetzt dort ein anderes Monsterprojekt ähnlicher Beschaffenheit aufegfahren - Einheitliche Visualisierung.
 
Zuletzt bearbeitet:
Das ganze ist natürlich ein breites Feld.
Im Bereich Fördertechnik / Indralogistik gibt es schon einige Firmen die sowas nutzen.
Hier hat manja meist auch eine Art Baukasten.
Im Maschinenbau geht es wohl eher richtig Workflow und oder Framework.
Wenn mir hier Tools automatisch ein Grundgerüst erstellen, dann reicht das - meiner Meinung nach - auch völlig aus.
Verriegelungen und Freigaben von Bewegungen muss ich ausgrogrammieren.
Abläufe mache in Graph.
Wo soll da der Zeitvorteil von einem Codegenerator sein?
Für ein UML-Diagramm brauche ich solange wie für ne Graph-Kette.

Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Abläufe mache in Graph.
Wo soll da der Zeitvorteil von einem Codegenerator sein?
Für ein UML-Diagramm brauche ich solange wie für ne Graph-Kette.

Gruß
Blockmove

Japp. Erzähl das mal den älteren Herren, die in Firmen die Oberhoheit in Sachen Software sich unter den Nagel gerissen haben, Graph verteufeln wahlweise zu einem Abmahnungsgrund und Häresie erklären, und stattdessen lieber 200 schrittige Ketten liebevoll in Excell aufmalen um sie später in irgendwelche KOP Bausteine zu übertragen. Das kostet sie dann 2000h je Auftrag und sichert die Arbeitsplätze bis zur wohlverdienten Rente.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wo das definitiv ein absoluter Blödsinn ist - zu versuchen, Stand-Alone Anlagen in der verarbeitenden Industrie mit jedes Mal erheblichem Spezialbedarf, Maßanfertigung und weiteren spezifischen UnicSellingPoints und dazu noch womöglich unter Mitspracherecht des Endkunden in der Auswahl der Komponenten über irgendwelche Code-Generatoren abzubilden.
Da muss ich erneut widersprechen. Bei der Harro Höfliger wurden Abfüllanlagen für Pulver und Flüssigkeiten und Montageanlagen (z.B. für Insulin-Pens) gefertigt, diese sind praktisch nie gleich. Auch da lohnt sich der Einsatz von Codegeneratoren oder besser gerade da lohnt er sich. Aus EPLAN wurde über Makros die Hardwarekonfiguration erzeugt, die Variablenangelegt und passend inklusive der BMKs benannt, die einzelnen Gerüste der FBs erzeugt, bei Standardkomponenten sogar die kompletten FBs, Fehlerlisten mit Standard-Fehlermeldungen und anderes erzeugt. Macht man das alles händisch oder versucht das aus einem in etwa ähnlichen Projekt zu ziehen dauert das ewig. Was aus anderen Projekten übernommen wurde ist der Code von speziellen Komponenten.

Von irgendwas mit Internetzugang gesendet.
 
Wobei es meiner Meinung nach so ist, dass wenn ich aus einen Schaltplan automatisch das Programm erzeugen kann, dann sollte ich auch einen weiteren Schritt gehen können, und aus einer wie auch immer gearteten Konstruktionsliste (z.B. Antriebs- und Messstellenliste) auch automatisch den Schaltplan und das Programm erzeugen können. Macht das jemand?
 
Wobei es meiner Meinung nach so ist, dass wenn ich aus einen Schaltplan automatisch das Programm erzeugen kann, dann sollte ich auch einen weiteren Schritt gehen können, und aus einer wie auch immer gearteten Konstruktionsliste (z.B. Antriebs- und Messstellenliste) auch automatisch den Schaltplan und das Programm erzeugen können. Macht das jemand?
Das wird vermutlich nicht gehen. In der Definition einer Messstelle wird ja vermutlich nicht angegeben sein an welchen Eingang der Sensor gehen soll/muss.

Von irgendwas mit Internetzugang gesendet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da muss ich erneut widersprechen. Bei der Harro Höfliger wurden Abfüllanlagen für Pulver und Flüssigkeiten und Montageanlagen (z.B. für Insulin-Pens) gefertigt, diese sind praktisch nie gleich. Auch da lohnt sich der Einsatz von Codegeneratoren oder besser gerade da lohnt er sich. Aus EPLAN wurde über Makros die Hardwarekonfiguration erzeugt, die Variablenangelegt und passend inklusive der BMKs benannt, die einzelnen Gerüste der FBs erzeugt, bei Standardkomponenten sogar die kompletten FBs, Fehlerlisten mit Standard-Fehlermeldungen und anderes erzeugt. Macht man das alles händisch oder versucht das aus einem in etwa ähnlichen Projekt zu ziehen dauert das ewig. Was aus anderen Projekten übernommen wurde ist der Code von speziellen Komponenten.

Von irgendwas mit Internetzugang gesendet.

Also ich weiß nicht, was und wie bei euch generiert wird, ich weiß auch nicht, welche Maschinen Harro Höflinger herstellt. Verpackungstechnik hört sich stark nach Serienmaschinenbau an. Ich weiß nur, bei vergleichbaren Ansätzen haben sich schon viele Firmen die Zähne dran ausgebissen und Millionenschäden eingefahren.

Es gab schon seit S5 Zeiten Versuche, über irgendwelche Excell-Listen irgendwas zu automatisieren. Es bleibt in der Regel dabei - diese Vorgehensweisen funktionieren nur, wenn man die Auswahl der zum Einsatz kommenden Komponenten und die Modularität der Anlage, die am Ende das Licht der Welt erblicken soll, zuvor genauestens definiert hat, und sich dran hält. Heißt, die Hardwareplanung verplant nur fertige Modulmakros, wo hinterher nichts mehr dran geändert wird, und der Code-Generator weiß auch genau, wie er mit diesen Modulen umzugehen hat. Alles andere führt sofort zu einem kompletten Chaos. Das erinnert mich aber stark an PCS7 mit Musterlösungen und Hardwareplanung im Comos.

Es gibt auch mittlerweile die Möglichkeit, sich die Hardware-Config und Symbole direkt aus dem EPLAN zu generieren. Bloß sieht die HW-Planung bei den meisten Sondermaschinenbau-Firmen so aus, daß die froh sind, wenn da überhaupt etwas rauskommt, was irgendwie mit der Realität konvergiert.
 
Bei den Verpackungsanlagen geht es vermutlich tatsächlich in Richtung Serie, aber auch da gibt es noch genügend Unterschiede zwischen den Anlagen. Die Montageanlagen und teilweise die Abfüllanlagen sind aber definitv Einzelanlagen bei denen nur einzelne Grundkomponenten gleich sind.
Ich kann nicht wirklich mit Details dienen, unter anderem weil es schon einige Jahre her ist, aber es hatte sehr gut funktioniert und uns viel Arbeit erspart, z.B. bei der Konfiguration der Achsen und IOs und dem Anlegen der IO-Variablen (Name + BMK), der Erstellung der FB-Gerüste, Fehlermeldungen und vielem mehr. Für die PacDrive M SPS hatte Harro ein eigenes Framework erstellt, weil es von Schneider als die Entwicklung der Software startete noch keins gab.

Von irgendwas mit Internetzugang gesendet.
 
Bei den Verpackungsanlagen geht es vermutlich tatsächlich in Richtung Serie, aber auch da gibt es noch genügend Unterschiede zwischen den Anlagen.

Ich glaube, diese Unterschiede sind marginal. Mal will der Kunde eine Bandstahlstanze, mal will er Stanz-Schnittwerkzeug, mal mit Austransport von Stanzgitter, mal nicht, mal mit Wechselstapelung oder mit Handentnahme. Ende der demokratischen Mitgestaltungsmöglichkeiten. Eine richtig einzigartige Verpackungsanlage wird dir dort wahrscheinlich keiner bauen. Nicht in den Budjets.

Die Montageanlagen und teilweise die Abfüllanlagen sind aber definitv Einzelanlagen

Nein. Montageanlagen werden im Karosseriebau wunderbar aus modularen Frames erstellt. VASS rockt.

bei der Konfiguration der Achsen und IOs und dem Anlegen der IO-Variablen (Name + BMK)

Begreife ich nicht, wieso kann man das nicht aus dem EPLAN machen ? Funktioniert doch wunderbar. Vorausgesetzt, man hat ein funktionierendes EPLAN-System aufgesetzt, und schmeißt nicht einfach irgendwelche Pflicht-Makros aus dem Dataportal zusammen, auch wenn's nachher aussieht wie n Sauhaufen.
 
Zurück
Oben