# Codegenerierung in der Praxis



## lu.koerfer (15 April 2019)

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


----------



## oliver.tonn (15 April 2019)

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.


----------



## ducati (16 April 2019)

oliver.tonn schrieb:


> 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...


----------



## Heinileini (16 April 2019)

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


----------



## ducati (16 April 2019)

Heinileini schrieb:


> 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ß.


----------



## blackpeat (16 April 2019)

Hab mal gesucht weil letztens ein ähnliches Thema da war.

https://www.sps-forum.de/simatic/94908-excell-als-codetemplate-improtieren.html?highlight=excel


----------



## oliver.tonn (16 April 2019)

ducati schrieb:


> 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.


----------



## lu.koerfer (18 April 2019)

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.


----------



## oliver.tonn (18 April 2019)

lu.koerfer schrieb:


> 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.


lu.koerfer schrieb:


> 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.


lu.koerfer schrieb:


> 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.


lu.koerfer schrieb:


> 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.


----------



## Draco Malfoy (18 April 2019)

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.


----------



## Blockmove (18 April 2019)

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


----------



## Draco Malfoy (18 April 2019)

Blockmove schrieb:


> 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.
> 
> ...



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.


----------



## DeltaMikeAir (18 April 2019)

Vielleicht ist folgendes für den einen oder anderen Mitleser dieses Beitrags interessant:
Interessante Bachlorarbeit "Entwicklung eines SCL-Codegenerators für TIA"


----------



## zako (18 April 2019)

... hier noch ein paar Links von unterschiedlichen Herstellern:

SIEMENS
https://mall.industry.siemens.com/mall/de/WW/Catalog/Products/10168156

B&R
https://www.br-automation.com/de-de/produkte/software/mapp-technology/

LENZE
https://www.lenze.com/de-de/loesungen/systeme/unsere-software/fast-application-software-toolbox


Das Thema hat schon einen entsprechenden Stellenwert bei den Herstellern von Automatisierungssystemen


----------



## oliver.tonn (18 April 2019)

Draco Malfoy schrieb:


> 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.


----------



## Thomas_v2.1 (18 April 2019)

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?


----------



## oliver.tonn (18 April 2019)

Thomas_v2.1 schrieb:


> 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.


----------



## Draco Malfoy (20 April 2019)

oliver.tonn schrieb:


> 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.


----------



## oliver.tonn (20 April 2019)

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.


----------



## Draco Malfoy (20 April 2019)

oliver.tonn schrieb:


> 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.


----------



## oliver.tonn (20 April 2019)

Äh, Draco, warst Du beim Schreiben/Lesen schon halb am Schlafen? Meine ganzen Kommentare beziehen sich auf Makros für EPLAN und die Generierung des Codes mit diesen.

Von irgendwas mit Internetzugang gesendet.


----------



## Blockmove (20 April 2019)

Draco Malfoy schrieb:


> Alles andere führt sofort zu einem kompletten Chaos.



Ich sehe es nicht ganz so negativ.
Egal ob nun Sonder- oder Serienmaschine ... du hast immer viel Routineaufgaben.
Wir nutzten z.B. einen Aktorbaustein zur Ansteuerung von Aktoren, Laufzeitüberwachung, Verriegelungen und Freigaben.
Hier wäre ein automatisches Erstellen der Variablen und der Grundparametrierung durch einen Codegenerator durchaus sinnvoll und würde auch erheblich Arbeit sparen.

Ich wollt sowas schon mal umsetzen, aber bisher hat mich die TIA-Versionshölle abgeschreckt


----------



## Onkel Dagobert (20 April 2019)

Blockmove schrieb:


> .. Ich wollt sowas schon mal umsetzen, aber bisher hat mich die TIA-Versionshölle abgeschreckt


Das ist im TIA-Portal gar nicht so schlimm. Man muss nicht alles importieren. Ein bisschen Code oder Meldetexte hat man auch schnell mal aus generierten Textdateien kopiert. Das war in Classic sehr viel schlechter möglich, vor allem wenn man spaltenweise kopieren wollte.


Was das Generieren im Allgemeinen angeht, so gibt es ja grundlegend verschiedene Ansichten und Möglichkeiten, wie die Beiträge hier auch zeigen. Man kann auch Schaltpläne aus irgendwelchen Listen generieren und aus diesen wiederum hinterlegten Programmcode für die Steuerung erzeugen. Im Prinzip hört sich das alles sehr verlockend an. Gesehen habe ich so etwas bisher nur auf Messen. In der Praxis bedarf so etwas sehr viel Disziplin und Vorarbeit. Zudem muss das ganze Team mitziehen und sich streng an Regeln einhalten. Ich weiß nicht wie es euch geht, in meinem Umfeld ist das absolut nicht denkbar.

Ich glaube, man sollte es als kleiner "Allrounder" mit dem Generieren auch nicht zu weit treiben. Einfach die Routineaufgaben damit erschlagen und man hat im Handumdrehen ein perfektes Grundgerüst für sein Programm. Das projektspezifische Programmieren kann ein Generator so wie so nicht übernehmen. Je allgemeingültiger der generierte Code ist, um so flexibler kann man den Generator einsetzen. Ich mache es seit vielen Jahren so, dass ich in Excel die Symbolik der Eingänge und Ausgänge erstelle. Jedes Symbol besteht aus drei Teilen (z.Bsp. Anlage, Ort, BMK). Zu jeden dieser drei Teile gibt es einen Kurztext und einen Langtext, nebeneinander in Spalten angeordnet. In einer weiteren Tabelle setze ich aus diesen drei Teilen meine E/As zusammen. Aus den Kurztexten entsteht per Auswahl das Symbol, aus den Langtexten automatisch der Kommentar. Somit hat man schon mal eine fehlerfreie und einheitliche Syntax, egal wie groß das Projekt auch wird. Auf Knopdruck werden aus diesen Daten eine Hand voll Textdateien erzeugt. Einmal für die Symbolik, für die Analogwerte, für Störungsmeldungen, jeweils mit FBs, DBs und UDTs, alles einheitlich und fehlerfrei kommentiert. Dann noch eine Datenbasis für mein persönliches System und natürlich eine Liste mit den Störmeldetexten. Für jeden dig. Eingang wird eine Störmeldung vorgesehen, für analoge Signale jeweils vier. Die Bausteine für die Analogwerte und für die Störmeldungen werden anschließend händisch überarbeitet. Ich hatte auch schon die Normierung der Analogwerte und die verschiedenen Auswertungen für Störungen generierbar gemacht. Aber selbst das war meistens schon zu spezifisch und musste spätestens zur IBN so wie so noch einmal überarbeitet werden. Ein sauberes Grundgerüst mit Kommentaren, vollständig und fehlerfrei ist hingegen schon eine sehr zuverlässige Grundlage. 

Für die Classic-Welt haben alle diese Text-Dateien das entsprechende Format zum Importieren. Für TIA handhabe ich es so, dass ich aus den Textdateien oder aus Excel den Code, die Symbole oder die Meldetexte kopiere. Nach dem ich alles übernommen habe, ist das Generieren beendet. D.h., die Quellen sind ab diesen Zeitpunkt hinfällig.


----------



## ducati (21 April 2019)

tja, sehr viel interessante Dinge. Zwei Sachen noch von mir.
Wenn man eine ordentlich Strukturierte Programmierweise in der SPS hat, ist das die Grundvoraussetzung für ne Codegenerierung. Aber genau dann ist die "händische" Programmerstellung auch nicht so irre langwierig bzw. fehleranfällig. Vor allem wenn man aus ähnlichen Anlagen kopiert und bestimmte Dinge/Texte aus der Excel oder Eplan kopiert.

Zweites hab ich die Erfahrung gemacht, dass dann eher minder erfahrene und bezahlte SPS Programmierer eingestellt werden, wenn doch so ein toller Codegenerator vorhanden ist. Wie Draco schon schreibt, geht dann mal schnell alles den Bach runter, wenn man nicht aufpasst...


----------



## Semo (23 April 2019)

Aus aktuellem Anlass habe ich mir das Osterwochende gegönnt um mir Openness mal wieder anzuschauen.

Vorweg:
Einen Codegenerator auf Excel-Basis entwickle, pflege und nutze ich seit fast 8 Jahren. (95% Fördertechnik)
Generiert werden Projektspezifische Symbole, UDT, DB, und Bausteine in KOP (AWL-Quelle) und SCL.
Das größte Manko seit TIA ist, dass die Generierung von KOP oder gar FUP (falls Kundenwunsch) per Quelle nicht mehr "einfach" möglich ist.
Grade die Logik-Bausteine und unsere Aufrufstrukturen sollen nach Möglichkeit in KOP erstellt werden.

Am Wochenende habe ich mir also, die Export/Import per Openness angeschaut, nicht für die gesamte SW, sondern hauptsächlich für die ca 30 verschiedenen Förderer-FB (im aktuellen Projekt) und die ca 90 (* 24 Anlagen) Verwendungsstellen.  
Beispielaufrufe erstellt und exportiert, anschließend Try&Error bei den Imports.

Ergebnis:
Mit minimalen Aufwand lassen sich brauchbare Templates erstellen, aus dehnen wiederum wieder importierbare XML-Quellen entstehen...
Falls sich jemand hiermit noch nicht beschäftigt hat, folgende Tipps:

Alle Tags mit ReadOnly="true" und Informative="true" können direkt gelöscht werden
Selbiges gilt für die kompletten <sections>-Bereiche im Deklarationsbereich der Instanzierten FB oder UDT
Eigene Kennungen und Identifikatoren in den Variablen/Parametern durch Platzhalter ersetzt.
Die UID sind nur Netzwerk-weise Unique, können also belassen werden
Die ID ist muss im kompletten XML Unique sein und kann von Anfang bis Ende hochgezählt werden (Hexa-Formatierung beachten)
Wer will kann den Openness Scripter zum Export und Import nutzen am Anfang reicht der allemal


Bei der Hardware CAxx Import sind ist mir noch 2 Makel aufgefallen:

Die Position zuvor Exportierter Komponenten wird beim Import wahllos bestimmt, auch bei bereits vorhandenen, zu überschreibender Komponenten (Super bei bereits fertigen Topologie-Strukturen )
Ich habe keine Möglichkeit gefunden die Busadresse zu übergeben, im Gegensatz zu bestimmbaren Adressbereiche, IP und DNS-Namen, wird diese bei mir beim Import vom Portal  neu vergeben... Da die Bus-ID Teil unserer E-Doku und auch Fehlertexte ist, heißt das an allen Teilnehmern immer wieder neu zuordnen :sb7:

Vielleicht kennt ja jemand nen Workarround o.a., da ich mich hiermit nur sehr kurz beschäftigt habe, habe ich bestimmt was übersehen.


Gruß Semo


----------



## HauDraufWieNix (25 April 2019)

Servus,

ich bin aktuell bei einem Kunden an einem größeren Projekt dran. 

Dabei wird aus Eplan ein XML exportiert und daraus über Powershell die Applikation komplett generiert. Das Ganze 
zieht einen größeren Kreis da die gesamte Applikation zusätzlich über einen Jenkins Server automatisiert getestet wird.
Continous Delivery, Digitaler Zwilling usw. ist da ganz stark Fokus.

Ziel ist es das der Endkunde seine Maschine konfigurieren kann, die Elektrokonstruktion den Schaltplan erstellt (was
auch schon teilweise automatisiert passiert) und dann der Quellcode inklusive Simulationsumgebung erstellt wird.
Die Maschine sozusagen schon im Büro "getestet" werden kann.

Dafür hab ich mir ein kleines Framework ausgedacht das es ermöglicht Maschinenmodule unabhängig voneinander
zu erstellen. Die Basis ist streng objektorientiert und die Bausteine haben keine direkte Verbindung zueinander.
Dadurch können diese recht einfach per Skript eingebunden werden.

Nachträglich können Bausteine ebenso noch angepaßt werden, bzw können trotzdem schnell Sonderwünsche
für Kunden einfließen. 

Die Visualisierung bekommt die gleiche XML Datei und kann sich entsprechend die Infos zur Maschine auslesen
und sich anpassen.

Allerdings arbeite ich nicht mit TIA Portal sondern mit Beckhoff (Twincat3) und Sigmatek (Lasal2) Steuerungen. 
Da dort die Objektorientierte Entwicklung recht gut umgesetzt ist.


----------



## gotscho (8 August 2019)

Hallo zusammen,

der letzte Eintrag ist schon eine her...ich versuch das mal wieder aufzugreifen.
Ich habe mich auch bei meinem letzten Arbeitgeber der Entwicklung eines Softwarestandards und darauf aufgesetzt einem Codegenerator für die SPS über TIA.Openess gewidmet.

Leider, wie ich hier auch schon gelesen habe wurde das Projekt als zu pflege-intensiv eingestuft und eingestampft. Das aber momentan ein E-Konstrukteur / Sofwareler mind. 3 Wochen pro Anlage für Vorbereitungen und "abtippselarbeit" vergeudet und dieser Aufwand auf wenige Stunden hätte reduziert werden können wollte keiner einsehen.

Die Projekt-Durchlaufzeit und die Qualität von Schaltplan und Software wäre sicherlich deutlich besser geworden...

Wir hatten dort das E-CAD ELTime im Einsatz. Sehr rudimentär im vergleich zu EPlan, aber immerhin mit einem Schaltplangenerator ausgestattet den ich auch noch gleich angebunden habe.

Somit konnte ich aus einer Excel-Datei (Export aus der mech. Konstruktion) Schaltplan und SPS Software auf Knopfdruck erzeugen. Also durchaus sinnvoll, aber leider verkannt. Auch bei Kollegen hatte ich teilweise den Ruf ihre Arbeitsplätze wegrationalisieren zu wollen 

Ich habe mein Tool in das von Siemens zur Verfügung gestellte TIA Openess Demo integriert. Wen's interessiert, aus Youtube gibt's ein Bildschirmvideo von einer frühen, etwas rudimentären Version:

https://www.youtube.com/watch?v=f43TARWnrlk

Wer ist denn aktuell auch an solchen Themen dran?


----------



## Heinileini (8 August 2019)

gotscho schrieb:


> Wer ist denn aktuell auch an solchen Themen dran?


Ein gewisser gotscho, siehe: 


gotscho schrieb:


> . . . . . . . . . . .


Dort befinden sich die beiden Durchschläge zum Beitrag.


----------



## HauDraufWieNix (9 August 2019)

Hi,

ja die Angst Arbeitsplätze wegzurationalisieren kenn ich. Das haben komischerweise sehr viele, da die neue Arbeitsweise
sich niemand vorstellen kann. Ich hab jetzt für Beckhoff und Sigmatek jeweils eine Bibliothek die die Grundlage bildet
um eine Applikation generieren zu können.

Die Applikation selbst muss natürlich auch dazu passen... das Ganze macht nur bei sehr modularen Anlagen Sinn die
entsprechend kundenspezifisch immer anders ausgeliefert werden.

Beim letzten Kunden war das schon ein ziemlicher Kampf die Vorteile darzustellen... und alle haben das immer noch
nicht erkannt, leider.


----------



## Heinileini (9 August 2019)

HauDraufWieNix schrieb:


> ja die Angst Arbeitsplätze wegzurationalisieren kenn ich. Das haben komischerweise sehr viele, da die neue Arbeitsweise sich niemand vorstellen kann.


Wohl dem, der dann für die zehn Wegrationalisierten arbeiten muss, weil die Anlagen ja in NullKommaNix zu projektieren sind! 
Irgendwie war ich eigentlich hin und wieder froh, wenn mal Routinearbeiten anfielen, weil ich dann Zeit hatte, mich gedanklich mit dem jeweiligen Projekt anzufreunden. Schliesslich macht es keinen guten Eindruck, wenn man nur da sitzt, Löcher in die Luft guckt und auf dem Bleistift kaut - da ist es schon nicht schlecht, wenn man solche Phasen durch eifriges Tippen kaschieren kann!!!


----------



## ducati (12 August 2019)

HauDraufWieNix schrieb:


> Beim letzten Kunden war das schon ein ziemlicher Kampf die Vorteile darzustellen... und alle haben das immer noch
> nicht erkannt, leider.



Vielleicht liegts auch daran, dass der Codegenerator auch einige Nachteile hat. Die Wichtung der Vorteile / Nachteile ist natürlich immer Ansichtssache.

Bei ner Industrieanlage auch interessant, wer kennt sich nach 10 Jahren, bzw. von den Instandhaltern denn mit der "neuen" Programmierweise aus?

Gruß.


----------



## Heinileini (12 August 2019)

ducati schrieb:


> Bei ner Industrieanlage auch interessant, wer kennt sich nach 10 Jahren, bzw. von den Instandhaltern denn mit der "neuen" Programmierweise aus?


Meinst Du mit 'der "neuen" Programmierweise' etwa die Benutzung eines CodeGenerators? Warum sollte ausgerechnet ein Instandhalter (nach 10 Jahren) merken bzw. darunter leiden, ob/wenn ein CodeGenerator die Basis geliefert hat, die dann ggfs noch manuell überarbeitet wurde?
Wenn das Programm nicht lesbar ist, dann hat man es anscheinend nicht geschafft, dem CodeGenerator brauchbare Eigenschaften in die Wiege zu legen.
Oder der Aufwand an manueller Überarbeitung ist zu umfangreich bzw. wird immer umfangreicher, z.B. bedingt durch ständig neue Upgrades, Downgrades, Updates, Releases und die Rücksichtnahme auf diverse KompatibilitätsProbleme.
In diesem Sinne: unser täglich Update gib uns heute!

Gruss, Heinileini


----------



## Draco Malfoy (15 März 2020)

Mal ein Feedback aus der Praxis.

Mittlerer süddeutscher Maschinenbauer, etwa an die 200 Mitarbeiter. Gibt ja viele von. Setzt seit Kurzem solche "Features" wie IO-Link, busfähige Ventile, verschiedentliche Antriebstechnik von verschiedenen Herstellern ein, und so weiter.

Eine mittlere Anlage des mittleren süddeutschen Maschinenbauers: 40-50 Achsen, an die 120 Hydraulikventile, ein Bisschen Sonderhardware im Feld.

Programmierung: Wüster Haufen verschiener FCs, in denen serielle Kommunikation, zyklische Kommunikation, azyklische Kommunikation, Schaltpunkte die da gebildet werden, Positionsvorgaben und Schwellen, jeweils *EINZELN HÄNDISCH IN KOP* mit Einschlüssen von AWL unter Zugriff auf globale Variablen programmiert sind. 

Heißt, ein FC hat so 150-250 Netzwerke, wo dann die komplette Parametrierung eines Ventils über azyklische Schnittstelle stattfindet. Lustig ? Nein. Von den Ventilen gibts einige dutzend, also auch von den FCs so viele, und alle 150 Netztwerke sind vermutlich jeweils händisch getippt und editiert worden. Mit der Schnittstelle zur VISU, versteht sich.

Ich frage mich: Wer bezahlt sowas ? Sind die Ingenieure, die sowas veranstalten, völlig bescheuert ? Brauchts denn hier einen Codegenerator oder eher einfach mal ne Schulklasse zum Thema "Umgang mit Librarys" ?


----------



## Blockmove (15 März 2020)

@Draco

"Moderne" Programmierung ist nicht immer von Vorteil.
Wir haben auch einen Maschinenlieferanten:
Fast alles in Kop, keine parametrierten FBs, Symbolik = BMK + Kommentar.
Programm im S5-Stil.
Also im Prinzip alles das, was man bei einer Maschine heute nicht erwarten würde.
Aber:
Die eigenen Inbetriebnehmer kommen damit zurecht, unsere Instandhaltung ist absolut zufrieden damit und der Preis liegt auf Wettbewerber-Niveau (trotz Made in Germany)
Die Firma hat einen Standard, der über die letzten Jahrzehnte nur ganz moderat angepasst wurde.
Für langjährige Mitarbeiter (und davon haben sie viele) und Kunden im Prinzip ein riesen Vorteil.
Meine Fazit daraus:
Man darf die SPS und Visu nicht losgelöst betrachten sondern im Gesamtumfeld.

Gruß
Blockmove


----------



## oliver.tonn (15 März 2020)

@Draco: Da kenn ich auch was von.
Sollte eine relativ einfache Anlage zum Verschweißen von Kunststoffteilen von 0 an programmieren. Etwas was ich eigentlich nicht gerne mache, denn ich habe bis heute, trotz mehrjähriger Programmiererfahrung, keinen Plan wie man an sowas strukturiert herangeht von der Planung über die Durchführung. Ich fühle mich bei Firmen am wohlsten, wo es klare Strukturen und Vorgaben gibt an denen ich mich orientieren kann.
Außer eine Beschreibung wie die Anlage funktioniert und welche Bedienelemente es gibt gab es keine Vorgaben was die Sprache und andere Dinge angeht. Da ich meist in ST programmiert hatte nutzte ich diese Sprache und lieferte nach ein paar Tagen das Programm ab. Beim Anblick des ST Codes wurde mein Ansprechpartner etwas blass und meinte, dass er vielleicht noch einigermaßen mein Programm verstehen würde, der Monteur aber nur grafische Sprachen versteht. Da noch reichlich Zeit war stellte ich alles auf FUP um, um dann zu erfahren das bei grafisch eher an KOP gedacht wurde, autsch.
OK, wenn auch relativ schwer, aber das konnte ich noch halbwegs verstehen. Was dann folgte aber weit weniger. In der Anlage kamen zwei identische Baugruppen zum Einsatz, daher habe ich einen FB genutzt und den Instanzen jeweils die benötigten Eingänge übergeben und die Ausgänge der Hardware zugewiesen. Beim Blick auf mein Programm stellte man mir dann die Frage, wo denn der Code für die zweite Baugruppe sei. Meine Erklärung, dass es für beide nur ein Programm gebe und dann Instanzen angelegt werden, denen die Daten dann übergeben werden, sorgte für verständnislose Blicke. Man wollte alle Baugruppen direkt im Code sehen. Ich habe also alle FBs kopiert und in diesen dann die I/Os direkt genutzt. Richtig schön war dann die Fehlerkorrektur, weil ich dann nicht an einer Stelle Änderungen machen musste, sondern an vielen und prompt auch was übersehen hatte.
Dann habe ich mal deren anderen Programme gesehen. Das praktisch alles in KOP war hatte ich ja erwartet, aber ansonsten praktisch nur PRGs und alles über globale Variablen abgewickelt.

Von irgendwas mit Internetzugang gesendet.


----------



## Blockmove (16 März 2020)

@Oliver
FBs mit ellenlangen Parameterlisten sind jedem Instandhalter ein Graus.
Die Forderung nach direktem Verschalten der EAs kann ich verstehen.
Natürlich steigt der Aufwand für Programmierer erheblich.

Ähnliches gilt für komplette Programme in ST.
Nach einigen negativen Erfahrungen mit Anlagen, haben wir nun auch Programme komplett in ST verboten.
Man kann in ST / SCL verständlich programmieren, aber es erfordert viel Disziplin. 
In SCL hab ich schon mehr Murks als in AWL gesehen. Ganz besonders von SPS-Quereinsteigern mit IT-Hintergrund.


Deshalb fordern wir auch Schrittketten in Graph.
Der Instandhalter hat nur noch eine Art von Ketten und muß nicht erst analysieren wie die Kette funktioniert bevor er den eigentlichen Fehler suchen kann.

Letztlich gilt:
Wir schreiben die Programme nicht für uns.

Gruß
Blockmove


----------



## Draco Malfoy (16 März 2020)

Blockmove schrieb:


> @Draco
> 
> Die eigenen Inbetriebnehmer kommen damit zurecht, unsere Instandhaltung ist absolut zufrieden damit und der Preis liegt auf Wettbewerber-Niveau (trotz Made in Germany)
> Die Firma hat einen Standard, der über die letzten Jahrzehnte nur ganz moderat angepasst wurde.
> Für langjährige Mitarbeiter (und davon haben sie viele) und Kunden im Prinzip ein riesen Vorteil.



Lieber Blockmove

vielen Dank für deine höflichen Schlichtungsversuche (Ich stelle mir Blockmove immer mit so einer großen Feile vor, der herumgeht und scharfe Kanten zu glätten versucht. Macht er wahrscheinlich bei sich im Betrieb auch.). In dem konkreten Fall zerstört es aber eine sachorientierte Diskussion.


```
Meine Fazit daraus:
Man darf die SPS und Visu nicht losgelöst betrachten sondern im Gesamtumfeld.
```

Ich rede jetzt ausschließlich vom Gesamtumfeld. Meine Einwände wenden sich nicht gegen eine Kleinstanlage auf einer 315er CPU, die einen Scherenubtisch steuert, von der Firma Heinz & Kunz als Sublieferant vom Sublieferant geliefert. Was und wie auf solchen CPUs programmiert wird, ist mir völlig schnuppe.

Ich rede jetzt von wirklichen Industrieanlagen. 30 bis 40 hydraulische Proportionalventile aus FCs in KOP einzeln verdrahtet anzusteuern, ist ein wirtschaftlicher Schaden für die Firma und ein Armutszeugnis für die Qualitätssicherung in der Ekonstruktions-Abteilung. Ganz abgesehen davon, daß die Anlage damit nicht als Vorlage für spätere Projekte dienen kann, weder flexibel erweiterbar noch irgendwie wartbar durchschaubar oder modifizierbar ist. Diese Hunderte von Netzwerken müssen nämlich von irgendwelchen zu bessern Tippsen degradierten Heinys händisch angelegt und korrigiert werden. Die Stundenvolumina gehen da in die Hunderte, wenn nicht Tausende, alleine schon in der Projektierungsphase.  Und  was passiert, wenn da an einer Stelle von 1500 mal "Obertisch_Frachtwerk.Querausleger_Rechts_Unten.ILCK" mit "Obertisch_Frachtwerk.Querausleger_Links_Unten.ILCK" versehentlich vertauscht wird ?

Dem häufig geäußerten Einwand, "Inbetriebnehmer/instandhalter würden mit SCL nicht zurechtkommen", kann man eingentlich sachgemäß nur auf eine einzige Art begegnet werden: Herr, schicke Hirn vom Himmel. Nicht den Inbetriebnehmern - den Managern, die solche Argumente im Munde führen. 

Wir leben heute nicht mehr im Jahr 1990 - es ist eine irre Anmaßung, aufgrund von welch auch immer geführter Argumentation, von Lieferanten Programmierweisen von 1990, im Verbund aber mit der prozesstechnischen Technologie von 2020 zu verlangen. Die Technologie von 2020 und solche Sachen wie IO-Link, Kameradatenerfassung, RFID-Tracking, Materialflußberechnung, Predictive Maintenance können eben nicht (vernünftig) mit den Programmiermitteln von 1990 umgesetzt werden, sondern nur mit denen von 2020. Wenn man aber nach 2000h die Anforderungen in dem Stil der Oma Emma dennoch abgebildet hat, dann findet sich dort anschließend in der Regel überhaupt niemand mehr zurecht, weder die eigenen Leute noch die Fremden. Es ist dann schlicht und ergreifend undurchschaubar. Eine "einfache" Programmiersprache bringt eben nicht automatisch einfache Prozessabläufe mit sich. Es ist ja die Feldtechnologie, die den Konstrukteuren ihre Anforderungen an eine Programmiersprache aufzwingt, und nicht umgekehrt. Wenn wir heute noch wie 1990 bloß zwei White-Black 5/3 Wege Ventile für einen kompletten Tiefziehvorgang hin und her steuern würden, wäre das ja in AWL und KOP doch kein Problem. Aber es ist ja leider nicht so.

Weiterhin ist es also eine Zumutung, von einem ordentlich aufgestellten Lieferanten, der eine gut gedeihende Softwareabteilung mit tüchtigen Kerlen hat, die eben ihre Bibliotheken und Bildbausteine und SIVARc Vorlagen und Ähnliches schon angelegt haben, zu verlangen, dies alles hinzuschmeißen und zu einer Steinzeittechnologie zurückzukehren, nur weil der Endabnehmer es bislang nicht für nötig gehalten hat, seine Leute in sachen zeitgemäßer Programmierung zu ertüchtigen.

Darüber hinaus ist es so, daß in die allermeisten SCL-programmierten Bausteine ein Instandhalter eh nicht rein soll. Wenn die so programmiert sind wie die Philosophie hinter einer Library es verlangt, dann funktionieren diese Bausteine gemäß ihrer Beschreibung und ein Inbetriebnehmer oder Instandhalter hat da nichts dran verloren. Man könnte natürlich den IBN-Leuten die Quellen zugänglich machen der besseren Nachvollziehbarkeit willen, aber generell laufen die Schrittketten im GRAPH und alles wo EA-Variablen direkt beschaltet werden, in KOP.


----------



## Draco Malfoy (16 März 2020)

oliver.tonn schrieb:


> @Draco: Da kenn ich auch was von.
> Sollte eine relativ einfache Anlage zum Verschweißen von Kunststoffteilen von 0 an programmieren. Etwas was ich eigentlich nicht gerne mache, denn ich habe bis heute, trotz mehrjähriger Programmiererfahrung, keinen Plan wie man an sowas strukturiert herangeht von der Planung über die Durchführung. Ich fühle mich bei Firmen am wohlsten, wo es klare Strukturen und Vorgaben gibt an denen ich mich orientieren kann.



@Oliver: Nun, wie man so schön sagt, jedem das Seine. Ich bin als Softwareentwickler mittlerweile aus diesen Umfeld raus, wo man "Malen nach Zahlen" praktiziert, habe mich aber bereits zu Beginn meiner Karriere extrem schwer getan mit Firmen, wo man alles besser zu wissen glaubt und das gerne alles so bewahrt wissen möchte, wie es dort seit 35 Jahren praktiziert wird. Am besten noch, als "Standard" deklariert - was in Wirklichkeit überhaupt kein Standard ist, sondern bloß autistische Programmierweisen irgendwelcher 60-jähriger Knacker, die weder in sich stringent sind, noch eine innere Logik mitbringen, un dnatürlich schon gar nicht irgendwo kodifiziert sind. Meine Aufgabe ist die Entwicklung von Software, Konzepten und Architekturen und die Ausschöpfung von Verbesserungspotentialen.

Programmierer, die gerne klare Strukturen hätten,  wurden und werden weiterhin massenhaft im Mark gebraucht. Das sind die pflegeleichten Inbetriebnehmer, die in jedem noch so schwierigen Umfeld mit bescheuerten Managern und völlig unsachgemäßen Vorgaben einen ausgezeichneten Job machen, wenn nur das Gled fleißg fließt, immer alle noch so bescheuerten Vorgaben erfüllen, immer fleißig alle möglichen Listen führen und alle Emails beantworten, immer pünklich kommen, und eine Freude für jeden freizeitorientierten Manager sind, der auf die technischen Details mehr oder weniger verächtlich niederblickt. 

Wie auch immer, ich gehöre nicht zu solchen Menschen, die selbstvertändlich ihre Existenzberechtigung haben und guten Job machen mögen, aber dieser Job ist nicht meiner.



> Da noch reichlich Zeit war stellte  ich alles auf FUP um, um dann zu erfahren das bei grafisch eher an KOP  gedacht wurde, autsch.


Ist doch umschaltbar.



> OK, wenn auch relativ schwer, aber das konnte ich noch halbwegs  verstehen. Was dann folgte aber weit weniger. In der Anlage kamen zwei  identische Baugruppen zum Einsatz, daher habe ich einen FB genutzt und  den Instanzen jeweils die benötigten Eingänge übergeben und die Ausgänge  der Hardware zugewiesen. Beim Blick auf mein Programm stellte man mir  dann die Frage, wo denn der Code für die zweite Baugruppe sei. Meine  Erklärung, dass es für beide nur ein Programm gebe und dann Instanzen  angelegt werden, denen die Daten dann übergeben werden, sorgte für  verständnislose Blicke. Man wollte alle Baugruppen direkt im Code sehen.  Ich habe also alle FBs kopiert und in diesen dann die I/Os direkt  genutzt. Richtig schön war dann die Fehlerkorrektur, weil ich dann nicht  an einer Stelle Änderungen machen musste, sondern an vielen und prompt  auch was übersehen hatte.
> Dann habe ich mal deren anderen Programme gesehen. Das praktisch alles  in KOP war hatte ich ja erwartet, aber ansonsten praktisch nur PRGs und  alles über globale Variablen abgewickelt.



Wie gesagt, ich hätte dann argumetiert daß die Herren für solche Jobs gerne einen Wald-und Wiesen-Programmierer engaieren möchten, aber ich bin es nicht. Schrittketten in GRAPH, Kommunikation in SCL, Wartungsintensive Bausteine in KOP, Visualisierung in Bildbausteinen, Bibliotheken und Multiinstanzen sind das A und O. Aber vermutlich bei der Anlagengröße so oder so nicht mein Fall gewesen, sondern eher etwas für tüchtige Praktikanten unter strenger Aufsicht.


----------



## Ralle (16 März 2020)

@Draco

Jeder darf hier mitdiskutieren, auch wenn er nicht deiner Meinung ist. Darin sollten wir doch übereinstimmen. Ich zumindest gebe Blockmove hier Recht und gehe an Hand der von dir gestellten Fragen und deiner sonstigen Einlassungen inzwischen mal davon aus, dass du eigentlich Informatiker bist.  Und ja, ich bin keiner, gehe auch eher den praktischen Ansätzen nach, liebe aber durchaus auch Ordnung im Programm!


----------



## Draco Malfoy (16 März 2020)

Ralle schrieb:


> @Draco
> 
> Jeder darf hier mitdiskutieren, auch wenn er nicht deiner Meinung ist.



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



> gehe an Hand der von dir gestellten Fragen und deiner  sonstigen Einlassungen inzwischen mal davon aus, dass du eigentlich  Informatiker bist.



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.


----------



## Faceman (16 März 2020)

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 (16 März 2020)

Draco Malfoy schrieb:


> 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 (16 März 2020)

@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 (16 März 2020)

Faceman schrieb:


> 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 (16 März 2020)

Draco Malfoy schrieb:


> 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



Faceman schrieb:


> 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.
> 
> ...


----------



## Blockmove (16 März 2020)

Draco Malfoy schrieb:


> 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 (16 März 2020)

Blockmove schrieb:


> 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 (17 März 2020)

@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 (17 März 2020)

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 (17 März 2020)

Blockmove schrieb:


> @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 (17 März 2020)

Draco Malfoy schrieb:


> 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 (17 März 2020)

Blockmove schrieb:


> 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 (17 März 2020)

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 (17 März 2020)

Blockmove schrieb:


> 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 (17 März 2020)

Draco Malfoy schrieb:


> 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.
> 
> ...



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 (17 März 2020)

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 (17 März 2020)

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


----------



## ducati (17 März 2020)

Blockmove schrieb:


> 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 (17 März 2020)

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 (17 März 2020)

ducati schrieb:


> 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


----------



## Draco Malfoy (17 März 2020)

Blockmove schrieb:


> 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.
> ...



Ich denke mal, man könnte vielleicht einen flexiblen Baukasten bereitstellen, der so ähnlich wie SiVArc funktioniert. Dort ist ja auch sehr wenig vorgegeben und sehr viel in der Hand des Anwenders, alledrings gibt es auch einen gewissen Rahmen und kodifizierte Befehlssystematik.

Wenn man also eine ähnliche Anwendung hätte, die jedoch die Schnittstelle zwischen EPLAN-Exporten / Listen und der TIA-Welt bilden würde, dann könnte man damit innerhalb der jeweiligen Softwareabteilungen, wenn denn der Wille und der Verstand dafür da sind, schon ziemlich weit kommen. Das Übrigen würde dann der SiVArc in seiner jetzigen Form problemlos erledigen können.


----------



## Tol3l3e (15 April 2020)

Moin,

auch wenn jetzt die Antwort ein bisschen später hier mal mein Vorschlag. In unserer Firma arbeiten wir mit selbst geschriebenen FB's für Motoren (Schütz oder FU), Digitalsensoren und Analogsensoren (Standardelemente). Da uns irgendwann der Projektierungsaufwand zu hoch war, in der HMI Textlisten und HMI Meldungen zu erstellen, wobei die Informationen schon in der SPS in den FB's gespeichert sind, haben wir uns ein Programm geschrieben welches uns automatisch den Aufruf für solche Elemente generiert und HMI Textlisten und HMI Meldungen als Importdatei erstellt. 
Dazu haben wir uns ein Tool geschrieben, welches die von ePlan oder WSCAD exportierten EA Listen einliest. Für die Standardelementekann nun jeder Ein- und Ausgang verknüpft werden. Am Ende wird dann mithilfe von TIA Openess den Aufruf der Standardelemente generiert in TIA und Excel Datei erstellt für den Import von HMI-Meldungen und Textlisten in TIA. Die Visualsierung der Elemente findet dann mithilfe vom Multiplexen statt.
Dadurch sparen wir uns viel nervige Schreibarbeit


----------



## Draco Malfoy (15 April 2020)

Tol3l3e schrieb:


> Moin,
> 
> auch wenn jetzt die Antwort ein bisschen später hier mal mein Vorschlag. In unserer Firma arbeiten wir mit selbst geschriebenen FB's für Motoren (Schütz oder FU), Digitalsensoren und Analogsensoren (Standardelemente). Da uns irgendwann der Projektierungsaufwand zu hoch war, in der HMI Textlisten und HMI Meldungen zu erstellen, wobei die Informationen schon in der SPS in den FB's gespeichert sind, haben wir uns ein Programm geschrieben welches uns automatisch den Aufruf für solche Elemente generiert und HMI Textlisten und HMI Meldungen als Importdatei erstellt.
> Dazu haben wir uns ein Tool geschrieben, welches die von ePlan oder WSCAD exportierten EA Listen einliest. Für die Standardelementekann nun jeder Ein- und Ausgang verknüpft werden. Am Ende wird dann mithilfe von TIA Openess den Aufruf der Standardelemente generiert in TIA und Excel Datei erstellt für den Import von HMI-Meldungen und Textlisten in TIA. Die Visualsierung der Elemente findet dann mithilfe vom Multiplexen statt.
> Dadurch sparen wir uns viel nervige Schreibarbeit



Herzlichen Glückwunsch, ihr habt PCS7 erfunden.

Die Idee, Elemente aus EPLAN einzulesen, finde ich klasse. Bloß, finde ich, ist die Importierung irgendwelcher Excel-Dateien im TIA ein großer Müll. Dazu gibt es SiVArc. PCS7 arbeitet standardmäßig mit COMOS; dort wird die Instrumentierung und Hardware verplant, und anschließend Musterlösungen definiert, wie mit der Hardware zu verfahren ist. Diese Musterlösungen kann man nachher im PCS7 importieren und an einer zentralen Stelle verwalten.

Für EPLAN gibt es solche Tools bislang nicht, und da sehe ich noch ein hohes Entwicklungspotential. Allerdings sollen dann bitte keine Excel-Listen anschließend rauskommen. Ist unglaublich mühsam und fehlerträchtig damit zu arbeiten. Ich will als Automatisierungsingenieur jedenfalls keine Excel-Makros entwickeln oder editieren müssen. Dafür gibt es andere Werkzeuge.


----------



## Blockmove (16 April 2020)

@Draco
Excel als Austauschformat ist zwar nicht der Hit, aber es erfüllt eigentlich die Anforderungen.
Die Bearbeitung ist einfacher als mit XML oder JSON.
Für die Automatisierung kannst du Excelmakros nehmen oder du machst es in der Programmiersprache deiner Wahl.

Gruß 
Blockmove


----------



## Tol3l3e (16 April 2020)

> Herzlichen Glückwunsch, ihr habt PCS7 erfunden.


Das wussten wir noch nicht 

Zudem kann man ja auch aus ePlan Dateien generieren, so dass man die Hardwarekonfiguration einfach reinladen kann.

Ich finde der Vorteil bei der ganzen Excel Sache ist auch die, dass wir dann eine Importliste haben, die wir im späteren Verlauf immer noch bearbeiten können und uns diese auch lesbar durchlese


----------



## Torquee (2 Mai 2020)

Hallo allerseits,

ich bin neu hier im SPS-Forum, angemeldet habe ich mich hauptsächlich wegen dem Thema Code-Generierung für Simatic TIA Protal.

Habt ihr schon mal etwas mit TIA OPENNESS probiert ?

Gruß Torquee


----------



## rwbm (14 Mai 2020)

TIA-Openness wurde literally im ersten Post des Fadens erwähnt...


----------



## ms_gp (22 Mai 2020)

Einen Vorteil von Codegenerierung hat noch keiner erwähnt:
Man kann aus der gleichen Eingabemenge Code für verschiedene Systeme erzeugen (S7Classic, TIA, CodeSys, Allen Bradley, usw)
Das wird dann natürlich noch aufwendiger und das muss sich schon richtig lohnen.
Ich erzeuge z.B. mit Hilfe von Excel aus einem Schnittstellen Dokument Code für 3 Systeme. Das war sehr aufwendig, aber jetzt wo es geht, ist es schon eine tolle Sache.

Ein weiterer Vorteil ist die Korrektheit: Sofern der Generator gut arbeitet und die Eingangsdaten stimmen, kann man sich auf die Richtigkeit des Ergebnisses verlassen. Egal ob es 2, 10 oder 10000 Elemente sind, alle werden richtig sein. Seien wir doch ehrlich. Wie viel Zeit verbringt man normalerweise mit Kopieren und Anpassen (Langweilig) und hinterher mit Kontrollieren, weil irgendwann doch die Konzentration nachlässt.

Ob man ganze Programme so bauen kann, weiß ich nicht.
Aber für kleine Teilbereich, die sich gut automatisieren lassen, weil die Daten gleichmäßig und listenartig sind, würde ich einen Generator dem händischen erstellen und ändern immer vorziehen.


----------



## Draco Malfoy (23 Mai 2020)

ms_gp schrieb:


> Ich erzeuge z.B. mit Hilfe von Excel aus einem Schnittstellen Dokument Code für 3 Systeme. Das war sehr aufwendig, aber jetzt wo es geht, ist es schon eine tolle Sache.


Noch einmal: Ich möchte als Programmierer keine Office-Tools für die Erstellung meiner Software bemühen. Handelt es sich um eine prozesstechnische Applikation, existiert dafür PCS7. Prozess auf TIA-Steuerungen zu automatisieren widerspricht dem Entwicklungsgedanken dieser Steuerungen, die sind dafür im Moment nicht gedacht, jedenfalls solange es keinen CFC als Programmierwerkzeug dafür gibt. Handelt es sich um eine fertigungstechnische Anwendung, gibt es die Schnittstelle TIA Openess, und die müsste man bemühen und ensprechende Projektgeneratoren und Tools dafür schreiben.

Aber ich möchte als Anlagen-Ingenieur weder Excel-Makros programmieren, noch diese Tools selber entwickeln. Das ist einfach nicht mein Job. Außerdem ist der Wiederholungsgrad in den fertigungstechnischen Maschinen in der Regel relativ gering - oder es wiederholen sich ganze Einheiten, die man bei objektorientierter Programmierung auch ohne größeren Aufwand händisch kopieren kann.

Viel wichtiger ist die stringente, bibliotheksfähige Vorgehensweise über ein umfangreiches Pool mit allen notwendigen Typicals, und angebundenen Faceplates, die jegliche Art der eingesetzten Hardware und Module abbilden, und die ich dank existierender Bildbausteine nicht händisch im HMI verdrahten muss. Heißt aber im Umkehrschluß, daß es eine gegenseitig abgesegnete Liste mit Hardware gibt, die verbaut werden darf, und Abweichungen davon erst durch die Softwarekonstruktion freigegeben werden müssen. Damit haben aber die meisten Firmen ein Problem, die der festen Überzeugung sind, die Elektroingenieure wären bloß irgendwelche ulkige Nerds, mit denen man nach dem Prinzip "fressen was auf den Tisch kommt" umgehen müsste.


----------



## ms_gp (23 Mai 2020)

Der letzte Absatz spricht mir aus der Seele. Damit hast du den Kern des Problems genau getroffen. Aber von so etwas wie abgesegneten Listen sind die meisten Firmen bestimmt sehr weit entfernt. Und auch die "Strukturierung" der Anlage ist ein Problem. Die Struktur ist oft nicht softwarefreundlich, sondern richtet sich nach Beschaffung und Mechanischen/elektrischen Baugruppen.

Und auch mit dem Rest hast du eigentlich recht. Diese Excel-Programme können zwar praktisch sein, aber sie sind letztlich nicht viel mehr als kleine Helferlein, die nach ein paar Jahren wirklich kaum jemand warten kann. Ich schon mehrere solcher Dinger schon gemacht und alle sehen anders aus. Trotzdem würde ich sagen, dass das besser ist als nichts. Ich mache das eigentlich recht gern, weil das ein guter Ausgleich zum zähen Programmieren einer SPS ist, besonders, wenn man zu KOP gezwungen wird. 

Ich denke die Einstiegshürde in eine API wie OpenNess ist für die meisten einfach zu hoch. Excel kennt jeder und Excel hat auch jeder auf seinem PC. Das kostet gar nichts extra. Wenn aber erst einmal VisualStudio angeschafft werden muss, dass auch noch Lizenzkosten verursacht, dann wird die Bereitschaft schon kleiner. Und dann muss man es ja auch noch lernen.


----------



## Torquee (23 Mai 2020)

zum Thema "CFC in TIA Portal"

ich habe S.interne Dokumente gesehen, die darauf schließen lassen, daß ein CFC-Editor für TIAP bereits besteht oder sehr sehr  weit fortgeschritten ist.

Ich bin seit 21 Jahren bei Siemens und kann sagen, daß das gar nichts heißt.

Es gibt für alles Produktmanager. Deren Interessen haben mit den Bedürfnissen der Anwender nur perifer zu tun.

Treibende Kräfte für TIAP sind große Firmen wie BMW, VW, große ING-Büros und so weiter, die Automatisierung für diskrete Fertigung brauchen.

Die diskreten Fertiger brauchen kein CFC (meinen sie jedenfalls).

Der PM für PCS7 wird kein Interesse daran haben, daß CFC auch in TIAP integriert wird.

Nebenbei: Es gibt auch Interesse von Seiten der Gebäude-Automatisierung CFC mit TIAP zu nutzen.


Es steht also in den Sternen wann CFC in TIAP kommt, in Version V17, V27 oder V127 !


----------



## Torquee (23 Mai 2020)

zum Thema OPNENNESS

das ist meine persönliche "laienhafte" Sicht !!! 

Mein Interesse an TIAP und OPENNESS besteht in rein privater Natur. (Haus-Automatisierung für mich)

Ich habe zu Beginn meiner beruflichen Laufbahn mit AEG MODICON A250 Steuerungen gearbeitet.

Da war das, was man mit OPENNES erledigen will schon möglich (auf textueller Basis: Export - Modifikation - Import) 


Treibende Kräfte für OPENNES sind auch hier die großen Firmen wie BMW, VW, Bühler, große ING-Büros  und so weiter, die Code generieren wollen, warum auch immer.

Es gibt Anwendungen, zum Beispiel in der Fördertechnik, da geht es ohne Generierung gar nicht mehr.


Leider wird aus meiner Sicht die API "OPENNESS" nicht sauber umgesetzt.

Eine API muß auch dokumentieren, wie der Zusammenhang zwischen den Programm-internen Darstellungen (z. Bsp. FUP) und den Export- und Import-Strukturen ist (XML)

Hier hapert es noch bei OPENNESS.

*Für FUP existiert keine einzige offizielle Dokumentation dazu !*

Die großen Firmen setzen da dann Werksstudenten dran, die das Rätzel analysieren und dokumentieren.

Das gesammelte Wissen ist dann Firmen-internes Know-How, das nicht weitergegeben werden darf.

Der Klein- und Mitter-Programmierer hat dann Pech gehabt.


meine Meinung:

*Die Programmierer des Export-Inport-Algorithmus generieren die internen Datenstrukturen einfach in XML-Dateien und legen sie in Dateiverzeichnissen ab.
*
Das macht am wenigsten Arbeit.

Das Ergebnis sind XML-Strukturen die keiner versteht, auch wegen der fehlenden Dokumentation.

*Die internen Strukturen werden innerhalb TIAP ja von den Editoren interpretiert und dargestell, das ist dann für den TIAP Benutzer handlebar. 
*
Ich habe in TIAP V13 einen Export mit dem Sript-Generator gemacht, dann unverändert wieder importiert, der Import lief auf Fehler.

Auf Nachfrage teilte man mir mit, dass der OPENNESS Script-Generator kostenlos ist und man keine Rechte auf funktionierende Software daraus ableiten kann.


*Wenn man OPENNESS für alle nutzbar machen möchte, so wäre ein Gemeinschaftsprojekt nötig, in dem alle Intressierten ihr wissen austauschen und zusammentragen und pflegen.
*
Auf die Vervollständigung der Dokumentation von Seiten Siemens würde ich nicht hoffen.

Ich wünsche ein schönes WE !

P.S.: das mit dem laienhaften ist schon etwas übertrieben


----------



## Draco Malfoy (23 Mai 2020)

Zum Thema CFC:

Ich habe mal da extra ein Thema aufgemacht, aber da hat sich keiner von Siemens zu gemeldet. Ich habe das schon so vermutet - CFC gibt es, aber entweder nicht anwendungsreif, oder vom Produktmanagement nicht freigegeben, wahrscheinlich zweiteres weil ersteres.

Man muß auch festhalten, CFC wäre schön und gut, aber es ist bloß die halbe Miete. So richtig Prozess kann man auf diesen CPUs dann erst betreiben, wenn es auch Technologische Hierarchie und Musterlösungen gibt, und auch entsprechende Bibliotheken wie Basic Library und Advanced Prozess Library. Wie man eine Basic Library für TIA-CPUs schreiben will, ist mir indes schleierhaft, da die relevanten Systemfunktionen, mit denen diese Bibliothek in der Classic Welt funktioniert, in den TIA-CPUs fehlen.


----------



## Draco Malfoy (23 Mai 2020)

ms_gp schrieb:


> Der letzte Absatz spricht mir aus der Seele. Damit hast du den Kern des Problems genau getroffen. Aber von so etwas wie abgesegneten Listen sind die meisten Firmen bestimmt sehr weit entfernt. Und auch die "Strukturierung" der Anlage ist ein Problem. Die Struktur ist oft nicht softwarefreundlich, sondern richtet sich nach Beschaffung und Mechanischen/elektrischen Baugruppen.



Das Problem ist, daß es schlicht unehrlich ist, innerhalb der eigenen Firma, da man jeweils mit Kosten arbeitet, die entweder auf der einen oder auf der anderen Seite anfallen. Diese Kosten zu verschweigen, zu ignorieren oder der "fremden" Abteilung in die Schuhe zu schieben, ist letzten Endes ein Selbstbetrug. Wenn die MK (mechanische Konstruktion) tolle Antriebe von Faulhaber oder Festo anstelle von Siemens verbauen möchte, weil es ihnen nen Haufen Platz spart und die Baugruppen kompakter werden, müsste man eigentlich erst ausrechnen, welchen Kostenvorteil es tatsächlich bringt, und demgegenüber den Aufwand rechnen, welcher entsteht, wenn die EK (Elektrokonstruktion) diese Antriebe bespielen muss. Es werden dann nebenbei auch neue EPLAN-Makros, Überarbeitung von Softwarebasis und Ergänzung der Beschaffungsroutinen notwendig. Überwiegt der Kostenvorteil, oder sprechen andere Gründe für den Einsatz, dann muss die KE diesen Aufwand in Mann-Stunden quantifizieren und das Management es absegnen. Höchstwahrscheinlich werden dann bereits über die Hälfte solcher Anpassungen hinfällig, bevor es überhaupt zum Ausprobieren kommt.

Dasselbe gilt übrigens auch für den Pre-Sales, wenn der Kunde Automatisierung nach Wunschkonzert verlangt.



> besonders, wenn man zu KOP gezwungen wird.


Mein Beileid.


----------



## Kabeläffle (23 Mai 2020)

Draco Malfoy schrieb:


> Wenn die MK (mechanische Konstruktion) tolle Antriebe von Faulhaber oder Festo anstelle von Siemens verbauen möchte, weil es ihnen nen Haufen Platz spart und die Baugruppen kompakter werden, müsste man eigentlich erst ausrechnen, welchen Kostenvorteil es tatsächlich bringt, und demgegenüber den Aufwand rechnen, welcher entsteht, wenn die EK (Elektrokonstruktion) diese Antriebe bespielen muss. Es werden dann nebenbei auch neue EPLAN-Makros, Überarbeitung von Softwarebasis und Ergänzung der Beschaffungsroutinen notwendig.


 Bei deiner Aufzählung könnte man folgendes ergänzen:


Mehrfacher      Aufwand bei der Ersatzteilhaltung 
Fehle      Möglichkeit bei der Fehlersuche Komponenten der Nachbar-Anlage quer zu      tauschen 
Zusätzliche      Einarbeitung in Bedienung und Konfiguration 
Zusätzliche      3. IBN-Software und zusätzliche Sonder-Kabel und Adapter 
 
  Wenn in deinem Fall, Siemens nichts im Katalog hat, mit was die Ziele erreicht werden können, dann muss man die oben genannten Nachteile in Kauf nehmen. 

  Das Kernproblem sehe ich darin, dass einerseits eine Standardisierung festgelegt wird und im nächsten Atemzug, Flexibilität verlangt wird.


----------



## Onkel Dagobert (23 Mai 2020)

Kabeläffle schrieb:


> .. Das Kernproblem sehe ich darin, dass einerseits eine Standardisierung festgelegt wird und im nächsten Atemzug, Flexibilität verlangt wird.


Womit auch wieder beim Generieren sind. Einen flexiblen Standard finden, genau das ist die Kunst dabei  .


----------



## Draco Malfoy (23 Mai 2020)

Onkel Dagobert schrieb:


> Womit auch wieder beim Generieren sind. Einen flexiblen Standard finden, genau das ist die Kunst dabei  .



Es fängt schon damit an, daß ein Standard nicht dasselbe wie irgendwelche hysterisch gewachsene Handschriften autistischer Programmierer ist. Letzteres ist kein Standard, sondern Müll. Standard muß inhaltlich stringend, durchgehend, logisch nachvollziehbar und vernünftig dokumentiert sein. 

Man verlangt häufig von externen Kräften, "sich bitte an den Standard zu halten". Macht man den Fehler, diese Gutsherrenwünsche unhinterfragt hinzunehmen, findet man sich später in der Situation, völlig systemlose, abartig dokumentierte, gruselige Schmierereien schizoider Firmenprogrammierer auseinander zu nehmen und reverse engineeren zu müssen, und hinterher beschwert sich die Kundschaft, warum man es denn bitte nicht "genau so" gemacht hat, und will die Rechnung nicht bezahlen.

Intern aber scheinen die Wenigsten überhaupt das Verständnis dafür zu haben, warum die externen Kräfte mit der Soße nicht zurechtkommen, und intern die Abteilung regelmäßig horrende Stundenschätzung für jede Abweichung von ihrem "Standard" ausstellt. Es kann nämlich auch nicht sein, daß ein Wechsel der Gerätefamilie von SEW auf Siemens bei einfachsten Förderbandantrieben dazu führt, daß 1000h mehr im Projekt anfallen.


----------



## Ralle (23 Mai 2020)

Draco Malfoy schrieb:


> Es fängt schon damit an, daß ein Standard nicht dasselbe wie irgendwelche hysterisch gewachsene Handschriften autistischer Programmierer ist. Letzteres ist kein Standard, sondern Müll. Standard muß inhaltlich stringend, durchgehend, logisch nachvollziehbar und vernünftig dokumentiert sein.
> 
> Man verlangt häufig von externen Kräften, "sich bitte an den Standard zu halten". Macht man den Fehler, diese Gutsherrenwünsche unhinterfragt hinzunehmen, findet man sich später in der Situation, völlig systemlose, abartig dokumentierte, gruselige Schmierereien schizoider Firmenprogrammierer auseinander zu nehmen und reverse engineeren zu müssen, und hinterher beschwert sich die Kundschaft, warum man es denn bitte nicht "genau so" gemacht hat, und will die Rechnung nicht bezahlen.
> 
> Intern aber scheinen die Wenigsten überhaupt das Verständnis dafür zu haben, warum die externen Kräfte mit der Soße nicht zurechtkommen, und intern die Abteilung regelmäßig horrende Stundenschätzung für jede Abweichung von ihrem "Standard" ausstellt. Es kann nämlich auch nicht sein, daß ein Wechsel der Gerätefamilie von SEW auf Siemens bei einfachsten Förderbandantrieben dazu führt, daß 1000h mehr im Projekt anfallen.



Vielleicht hast du Recht. Aber kann es sein, dass du dich für den Gott der externen Programmierer hältst? Komm ruhig mal ein bisschen runter, nicht Alle sind gleich schizoid und minderbegabt, nur weil sie vielleicht nicht deinen Horiziont erreichen. Wenns denn böser Wille wäre, aber das ist es meißt nicht, eher wenig Zeit, unverständige Chefs, na gut und manchmal auch Unvermögen.


----------



## Draco Malfoy (24 Mai 2020)

Ralle schrieb:


> Vielleicht hast du Recht. Aber kann es sein, dass du dich für den Gott der externen Programmierer hältst? Komm ruhig mal ein bisschen runter, nicht Alle sind gleich schizoid und minderbegabt, nur weil sie vielleicht nicht deinen Horiziont erreichen. Wenns denn böser Wille wäre, aber das ist es meißt nicht, eher wenig Zeit, unverständige Chefs, na gut und manchmal auch Unvermögen.



Ralle, abgesehen davon, daß die Höflichkeit in deiner Anspache stark nachgelassen hat, der Punkt, auf den ich aufmerksam machen will, ist ein gänzlich anderer. Die Standardsituation in den Firmen ist, künstlerisch überzeichnet, ungefähr so:

- Abteilungsleiter, selber bereits weit weg sowohl von den technischen Realitäten als auch vom inhaltlichen Verständnis, kümmert sich nur noch um die Stunden der Mitarebeiter, politische Intrigen innerhalb der Firma, Projektplanung und Beschaffung von Inbetriebnahmekräften;
- Ingenieure, meistens seit 10-15 Jahren in der Firma, kennen weder die neuesten Technologien noch den technischen Fortschritt auf dem Mark, bilden sich selber nicht weiter, interessieren sich nicht für technische Neuerungen, und generell für kaum etwas, außer ihrer Freizeit und Konstanz der Kaffeetemperatur im Büro;
- Projektmanager und höhere Manager haben überhaupt keine Ahnung wie Automatisierung funktioniert und was die Firma konkret braucht, um dort mehr Effizienz und Anschluß an die Realitäten der heutigen Welt zu erreichen;
- Interne Mitarbeiter, die etwas auf dem Kasten haben und die Zustände eigentlich auch gerne beseitigen würden, werden jahrelang ausgebremst und resignieren am Schluß, weil deren Meinung niemanden interessiert und ihnen nichts anvertraut wird;
- Externe Kräfte werden nur gebucht, um drohenden Personalmangel abzufangen, und haben ohnehin nichts zu sagen.

In Ausnahmefällen bucht so eine Firma, auch mal einen externen Berater, wenn der Unmut über die fehlende Flexibilität und hohe Stundenvolumina irgendwo in den Führungsetagen Überhand nimmt. Dann kommt so ein externer Berater da hinein, und erzählt von Graph, Prodiag, SiVArc, T-CPUs, Bibliotheken, Bildbausteinen usw. Die Leute hören dann in bunten Workshops gelangweilt zu und sorgen dann auf kurz oder lang dafür, daß dieser Mensch dort nichts real bewegen und bewirken kann. Es wird lang und ausufernd diskutiert, warum die Räder, die innerhalb des Mikrokosmos dieser Firma erfunden worden sind, ganz spezielle Räder sind, die nichts mit den Rädern der Firma Siemens zu tun haben, und deswegen kann man davon leider nichts einsetzen.

Als Sahnehaube kommen dann dem einen oder anderen jungen und dynamischen Abteilungsleiter die Ideen, zum Beispiel eine einheitliche Visualisierung quer über alle Steuerungen anzuschaffen, und/oder sich von Produkten der Firma Siemens zu trennen, und stattdessen ganz tolle Phoenix Visu 2+ (minus, sinus, cosinus) und Beckhoff Schießmichtot einzusetzen, weil Siemens ja Boko Haram ist. Noch Fragen ?


----------



## Ralle (24 Mai 2020)

Draco Malfoy schrieb:


> Ralle, abgesehen davon, daß die Höflichkeit in deiner Anspache stark nachgelassen hat,



Ja soll ich  jetzt noch Hand auflegen?
Was genau bitte war unhöflich?


----------



## wollvieh (24 Mai 2020)

@Draco Malfoy : Stringent schreibt man mit "t" am Ende. Ist Standard. 
;-) immer schön cool bleiben, am Ende wird alles gut.
Edit.: @Draco M. : 
Deine Beschreibung der herrschenden Strukturen ist einwandfrei formuliert! Dem ist nichts hinzuzufügen.


----------



## HauDraufWieNix (29 Juni 2020)

Draco Malfoy schrieb:


> Mal ein Feedback aus der Praxis.
> 
> Ich frage mich: Wer bezahlt sowas ? Sind die Ingenieure, die sowas veranstalten, völlig bescheuert ? Brauchts denn hier einen Codegenerator oder eher einfach mal ne Schulklasse zum Thema "Umgang mit Librarys" ?



Verrückterweise denkt da niemand über ein redesign des aktuellen Quellcodes nach. Das passiert meist nur im Zusammenhang mit einem Wechsel
des Steuerungslieferanten wenn der alte Code nicht mehr verwendet werden kann. "Gewachsene Strukturen" sieht man ja recht häufig... ich muss
mich selber immer mal wieder maßregeln das reingehackte auch mal wieder in Frage zu stellen.

Code generieren ist nicht für jede Applikation ein Vorteil, aber mit der richtigen Architektur kann das gut und leserlich funktionieren.


----------



## selmotino (19 August 2020)

Hallo zusammen, 

ich habe zufällig eure Diskussion gelesen. Ich beschäftige mich selbst schon seit Jahren mit dem Thema code aus einem Modell zu generieren. 
Ich schaffe es den Prozess in Logikablauf - Systemaufbau - parameter - und Display Layer zu modellieren und dann ein fertige Schrittkette erzeugen. keine mauelles tippen und immer gleich strukturiert.
Nix kopiert und 100 % ausprogrammiert.

Ich weiß nicht wie weit ich hier unsere Technologie ansprechen soll, aber es funktioniert. Besonder gut bei Retrofit -anlagen wo nur die SW und HMI getauscht wird.
Wenn jemand näheres wissen möchte oder uns helfen will Meinungen zu sammeln bin ich dankbar.

Ein SPS Programmierer 

selmo steht für sequence logic modelling (ablauflogisches modellieren) ist eine absolut cool lösung

lg


----------



## Heinileini (19 August 2020)

selmotino schrieb:


> Besonder gut bei Retrofit -anlagen wo nur die SW und HMI getauscht wird.


Nur die SW und HMI getauscht? Die PLC bleibt dieselbe? Das ist wohl eher ungewöhnlich bei Retrofits.
Wozu dann überhaupt die SW tauschen? Um sie zum neuen HMI passend zu machen?
Welche Informationen müssen die alte PLC und das alte HMI mitbringen bzw. von sich geben, um sie "maschinell" analysieren zu können, so dass man daraus etwas modellieren kann?
Oder analysiert ihr nur bzw. auch den SchaltPlan?


----------



## Ralle (19 August 2020)

selmotino schrieb:


> Hallo zusammen,
> 
> ich habe zufällig eure Diskussion gelesen. Ich beschäftige mich selbst schon seit Jahren mit dem Thema code aus einem Modell zu generieren.
> Ich schaffe es den Prozess in Logikablauf - Systemaufbau - parameter - und Display Layer zu modellieren und dann ein fertige Schrittkette erzeugen. keine mauelles tippen und immer gleich strukturiert.
> ...



Na, ist doch gernial. Noch ein paar Jahre und du hast dich und den Rest der Programmierer hier im Forum mal eben so abgeschafft.
Ich kenn mindestens 4 Chefs, die genau das denken, wenn sie das hier lesen und sich schon die Hände reiben. Die wissen auch nicht wirklich, was wir so tun, mich fragte einer, warum ich mit TIA jetzt nicht viel schneller bin und meine Angebote nicht in Preis und Stunden runtergehen. Der hatte einer Marketing-Veranstaltung von Siemens beigewohnt.  Vielleicht solltest du bei Siemens anheuern, dann müssen die sich nicht mehr mit uns dummen Programmieren rumärgern und könnten ihr TIA auch gleich einstampfen. Mit deiner neuen Software verdienst du dann woran genau? Ach ja, du verkaufst das an unsere Chefs  Viel Spaß.
Integriere das doch am Besten ins CAD (auch hier gibt es schon Ansätze), dann fällt das fertige Programm gleich bei der Konstruktion mit ab.
Weiß zwar kaum noch jemaand wie das geht oder wie man was ändert und anpaßt, aber schau dich um, davon gibt es überall immer mehr. 

/Ironie aus

Ich denke mal, es gibt sicher Aufgaben für die das ganz gut funktioniert und sicher kommt der Tag, da braucht uns Alle niemand mehr, aber das werde ich wohl nicht mehr miterleben, ich bin zu alt, um mich nochmal völlig umorientieren zu wollen. Und Fortschritt kann man ja bekanntermaßen kaum aufhalten. ;-)

PS: Der Deutsche Name für deine Lösung gefällt mit jedenfalls besser als dieser englische Sch...

Grüße, noch ein SPS-Programmierer


----------



## DeltaMikeAir (20 August 2020)

selmotino schrieb:


> Hallo zusammen,
> 
> ich habe zufällig eure Diskussion gelesen. Ich beschäftige mich selbst schon seit Jahren mit dem Thema code aus einem Modell zu generieren.
> Ich schaffe es den Prozess in Logikablauf - Systemaufbau - parameter - und Display Layer zu modellieren und dann ein fertige Schrittkette erzeugen. keine mauelles tippen und immer gleich strukturiert.
> ...



Gibt es denn mehr Referenzen ( oder nur die 5 auf genannten auf eurer Website, wo eine Schule dabei ist ), Videos oder Handbücher wo man sich dass mal etwas anschauen kann?


----------



## Blockmove (20 August 2020)

Extrahiert man Comics und Marketingversprechen von der Selmo-Website und den YouTube-Videos, dann ist es wohl ein Framework / Toolkit ähnlich Bosch Neexed Control plus. Das Ganze kann in vielen Fällen funktionieren.


----------



## selmotino (20 August 2020)

*Demo einer Beta Version*



DeltaMikeAir schrieb:


> Gibt es denn mehr Referenzen ( oder nur die 5 auf genannten auf eurer Website, wo eine Schule dabei ist ), Videos oder Handbücher wo man sich dass mal etwas anschauen kann?



Ja, wir haben selber eine Maschine mit 300 Eingängen - 250 Ausgängen, 12 Servo Achsen, 15 FU Antriebe -- 23 Schrittketten gemacht. INFO werden wir Online stellen.

In der Demo kann man sich anmelden. Wir sind im Moment selber überzeugt, dass es eine Vereinfachung ist. 

Ab 15.9 geht eine erste Release Online. DEMO - TEST und Doku

https://selmo-modeler.eprozess.org/account/register (link Demo BETA )

lg


----------



## selmotino (20 August 2020)

Hallo, Ironie aus ,

wir wollen in der SPS Programmierung die lästige copy und paste sparen. SPS Programmierung fokussiert bei uns auf die wichtigen Funktionen - umsetzten der Steuerungsaufgabe und das schon so früh wie möglich und programmieren der TREIBER - Logik der Schrittkette steuert die Funktion - diese Treiber sind wie die FB oder PRG die wir sowieso immer verwenden und Anpassen.

Es geht um die Aufwertung von Software in der Maschine - ich kenne es so- wenn alles fertig ist brauchst es noch jemanden der es programmiert - Meist bei der IBN der erste und der Letzte - und am Ende nie wirklich fertig - weil bei Problemen ist es immer zuerst ein Software Problem.

Es ist auch lästig wenn ich die Variablen in der PLC deklariere - dann noch in der HMI und so weiter...

Wir machen so einfach eine Standardstruktur und sind in der Lage eine statemachine 100% zu beschreiben - das ist einfach der Grund - damit wird eine Software sicher!
Ich habe vor 30 Jahren schon immer wieder befürchtet, dass SPS Programmierer ersetzt werden - bin heute immer noch am Programmieren 

Ich nutze einfach für allgemeine Struktur einen Generator - SELMOtino


----------



## selmotino (20 August 2020)

ja, natrürlich wird die PLC getauscht. habe ich hier bei Experten vorausgesetzt. 

SW tausch wegen der Digitalen Anbindung  - schlechtes Bedienkonzept - Auslauf von Produkten (S5 Siemens) - Bedienkonzepte standardisieren

Wir filmen die laufende Maschine - Prozess beschreiben
Wir setzten die E/A in den SYSTEM Layer um und verknüpfen diese über das Bitcontrol 
Parameter erfassen (Eingaben Ausgaben) Flexibilisierung der Schrittkette
Fertig
HMI generieren wir aus dem Modell - Anpassung der Übersichtbilder und spezial Bilder auf Basis der Datenpunkte aus dem Modell (kann nur eingeben und anzeigen was in der Software ist )


----------



## DeltaMikeAir (20 August 2020)

selmotino schrieb:


> Ja, wir haben selber eine Maschine mit 300 Eingängen - 250 Ausgängen, 12 Servo Achsen, 15 FU Antriebe -- 23 Schrittketten gemacht. INFO werden wir Online stellen.



Das heißt die Referenz ist erst eine Maschine??



selmotino schrieb:


> https://selmo-modeler.eprozess.org/account/register (link Demo BETA )



Sorry aber ich melde mich da jetzt nicht an um mir dass mal 10 Minuten anschauen zu können.

Ich persönlich würde euch auch empfehlen, die Comics wegzulassen. Das macht nicht unbedingt einen professionellen Eindruck


----------



## Ralle (20 August 2020)

selmotino schrieb:


> Wir machen so einfach eine Standardstruktur und sind in der Lage eine statemachine 100% zu beschreiben - das ist einfach der Grund - damit wird eine Software sicher!



So 100%, na das ist ja mal eine Behauptung. Lassen wir uns überraschen. Kann mit kaum vorstellen, dass das wirklich so 100% funktioniert, wenn man Werkstückträger, Schreib- Leseeinheiten mit strukturierten Daten, Deltapicker, Siemens-Servos, Keyence-Scanner, Keyence-Kameramodule usw. in einer Anlage zu bedienen hat. Wieviel Zeit benötigt man für das Erstellen von Standardmodulen, die deine Softwarecdann verwenden kann? Ich kann das ja auch von der Boch-Seite her, aber da muß man auch mal sagen, Kosten und Aufwand sind erheblich. Auch das Korsett ist extrem starr. Vorteil, es ist eine Art Standardisierung.


----------



## DeltaMikeAir (20 August 2020)

Ralle schrieb:


> So 100%, na das ist ja mal eine Behauptung. Lassen wir uns überraschen. Kann mit kaum vorstellen, dass das wirklich so 100% funktioniert, wenn man Werkstückträger, Schreib- Leseeinheiten mit strukturierten Daten, Deltapicker, Siemens-Servos, Keyence-Scanner, Keyence-Kameramodule usw. in einer Anlage zu bedienen hat. Wieviel Zeit benötigt man für das Erstellen von Standardmodulen, die deine Softwarecdann verwenden kann? Ich kann das ja auch von der Boch-Seite her, aber da muß man auch mal sagen, Kosten und Aufwand sind erheblich. Auch das Korsett ist extrem starr. Vorteil, es ist eine Art Standardisierung.



Das war auch mein erster Gedanke, Beispiel unsere Ablüffanlagen für Flaschen, 60.000ér Stundenleistung.
Es gibt Sorten, pro Sorte Eigenheiten im Ablauf, SAP Anbindung, spezielle Seiten für Wartung, Diagnose,
jede Maschine anders da individuell für Kunde produziert wird. CSV Handling über Panel und so weiter und so fort.

100% halte ich mal für unmöglich denn wir liefern funktionierende Anlagen aber der Kunde hat trotzdem
immer noch Wünsche für Programmablauf / Stauschaltungen / Kontaktaustausch / Bedienung usw. usw.
100% bedeutet für mich, Programm wird generiert, geladen, funktioniert und muss nicht mehr angefasst werden.
Daran zweifel ich jetzt einmal.

Und vor allem F-Steuerung, wird der F-Teil etwa auch automatisiert generiert?


----------



## testor (20 August 2020)

Ralle schrieb:


> So 100%, na das ist ja mal eine Behauptung. Lassen wir uns überraschen. Kann mit kaum vorstellen, dass das wirklich so 100% funktioniert, wenn man Werkstückträger, Schreib- Leseeinheiten mit strukturierten Daten, Deltapicker, Siemens-Servos, Keyence-Scanner, Keyence-Kameramodule usw. in einer Anlage zu bedienen hat. Wieviel Zeit benötigt man für das Erstellen von Standardmodulen, die deine Softwarecdann verwenden kann? Ich kann das ja auch von der Boch-Seite her, aber da muß man auch mal sagen, Kosten und Aufwand sind erheblich. Auch das Korsett ist extrem starr. Vorteil, es ist eine Art Standardisierung.



Eine 100%ige generierte Lösung ist denke ich aus der Luft gegriffen. Ich finde das muss aber auch nicht zwingend sein. Die Generierung eines soliden Korsetts, dass die Möglichkeit bietet entsprechende Module aufzurufen vereinfacht unser Leben schon ungemein. Das ein Standardisiertes Korsett starr ist, ist immer so ein Nachteil. Hast du tiefergehende Erfahrungen mit Bosch? Ich habe mir das mal zeigen lassen und fand es auf jeden Fall klasse, weil ich bis dato leider auch nichts vergleichbares kenne.
Wie sind da deine Erfahrungen was die Erweiterbarkeit von Standardmodule angeht? Genau daa war mein größte Sorge, da von den Nexeed Jungs immer nur gesagt wurde das es einfach geht und das Nexeed Team das auch übernehmen könne.


----------



## DeltaMikeAir (20 August 2020)

Ich finde automatisierte Codegenerierung vor allem ( in meinem Fall ) interessant im Bereich Logistig. Wir bauen auch viel Palettentransport /
Transportbänder / Kommissionieranlagen für Paletten. Da ist die Programmerstellung / Visu tatsächlich eine reine Kopierarbeit bei der
natürlich auch Fehler passieren da irgendwann alles gleich aussieht. Da wären für mich 80% der Codeerstellung schon völlig ausreichend,
den Rest würde ich selber manuell für den Kunden anpassen.

EDIT:
Aber dann brauche ich einen Lieferant für eine solche Generiersoftware, der etwas realistisches liefert und mir auch ehrlich sagt: "100% werden nicht möglich sein, vielleicht 90/95%"


----------



## Blockmove (20 August 2020)

Ralle schrieb:


> S Wieviel Zeit benötigt man für das Erstellen von Standardmodulen, die deine Software dann verwenden kann? Ich kann das ja auch von der Boch-Seite her, aber da muß man auch mal sagen, Kosten und Aufwand sind erheblich. Auch das Korsett ist extrem starr. Vorteil, es ist eine Art Standardisierung.



Letzlich funktioniert das auch nur mit einer starren Standardisierung.
Bosch wollte uns auch schon zu OpCon bzw. jetzt Neexed Control Plus "bekehren".
Als wir unsere Standardbausteilelisten vorgelegt haben, war das Thema schnell erledigt. 
Für Scanner, Antriebe und vieles mehr müssten Module geschrieben werden.
Das Ganze bietet Bosch als Dienstleistung an. Ist natürlich das Geschäftsmodell.
Das Toolkit verkaufst du einmal ... Jedes Modul ausserhalb des Standards kostet Geld.
Klar kannst du selber Module schreiben, wenn du tiefgreifende Kenntnisse des Frameworks hast.
Und das nicht nur auf der SPS-Seite sondern besonders in der PC-Entwicklung.
Jetzt kannst du natürlich auf die Idee kommen, deine "Nicht-Standard-Hardware" direkt in das SPS-Programm einzubinden.
Bei der nächsten großen Änderung fällt dir das auf die Füsse weil dein Projekt nicht mehr kompatibel ist.

Nächster Punkt ist der erzeugte SPS-Code.
In wie weit ist er "menschenlesbar"?
In wie weit kann man mit Tia oder Codesys Fehlersuche betreiben?

Also das Thema Codegenerierung ist spannend und sicher wird es in diese Richtung gehen.
Aber die Aspekte und Rahmenbedingungen sind vielfältig.

@selmotino


> Ich persönlich würde euch auch empfehlen, die Comics wegzulassen. Das macht nicht unbedingt einen professionellen Eindruck



Dem schliesse ich zu 100% an!
Durch so was fühle ich mich ehrlich gesagt verars...
Für mich persönlich ist das typisches Startup-Gehabe.
Vom fertigen Produkt weit entfernt, aber Comics und Präsentationen sind schon fertig 

Gruß
Blockmove


----------



## selmotino (20 August 2020)

DeltaMikeAir schrieb:


> Das heißt die Referenz ist erst eine Maschine??
> 
> 
> Wir haben mit unserem Tool nun eine Maschine gemacht. Ich persönlich mache solche Maschinen schon seit 20 Jahren. Früher eben manuell, aber immer auf Basis von verschiedenen erprobten Standards aus der Automobil und Luftfahrt.
> ...



Unser Selmotino ist unser Generator - vielleicht Freund und Helfer für Programmierer. Professionell ist das Thema (patent - Produkt - akademisch)


----------



## selmotino (20 August 2020)

Durch die Trennung der Logik von der Funktion ergibt sich ein neuer Blickwinkel.

Für eine Schrittkette gilt: Ablauflogik = Wann eine Achse von a nach b fährt - wenn ein Druck druckt - wenn was bewegt wird ....
Der Treiber organisiert die Umsetzung - Wie beim PC -- egal welcher Drucker die Logik sagt drucken = Treiber übersetzt für Funktion 
Wir haben im letzten Projekt 4 Treiber verwendet (Generisch für DS402 SoftMotion Servo Achsen Position, FU ansteuerung generisch, SternDreisck anlauf und einen Drucker für Schrit RS232)
Diese Treiber verwenden wir nun weiter für die Zukunft. Die Treiber haben alle ERROR Meldung, Daten vom Kontroller usw. beim laden dieser Treiber werden automatisch die Datenpunkte definiert.

Wir haben einen Prototypen bei uns der hat 5 Zylinder und 4 Tasten: die Programmierung für den reine Schrittkette mit HMI fix fertig  ca. 25min


----------



## selmotino (20 August 2020)

DeltaMikeAir schrieb:


> Das war auch mein erster Gedanke, Beispiel unsere Ablüffanlagen für Flaschen, 60.000ér Stundenleistung.
> Es gibt Sorten, pro Sorte Eigenheiten im Ablauf, SAP Anbindung, spezielle Seiten für Wartung, Diagnose,
> jede Maschine anders da individuell für Kunde produziert wird. CSV Handling über Panel und so weiter und so fort.
> 
> ...



Nein Sicherheitsrelevante SPS darf nicht generiert werden!! Ist wohl ein Test

Das Modell beschreibt den Prozess - wenn der Prozess klar ist dann ist der Ablauf klar 
Das System ergibt sich aus den notwendigen Baugruppen (Sensoren, Aktoren) alles diskret aufgetragen und beschrieben
Parameter sind Eingabe und Ausgabe Daten (REAL, INT, Bool usw....)
Display alle Datenpunkte und Bits werden im HMI angezeigt 

Änderungen, wenn der Prozess sich verändert im Modell - ein klick import und läuft 

Geht. 60.000 = 16,6 / Sekunde = 60ms / Flasche bei einer Zylkuszeit von 1ms schon leistbar


----------



## Heinileini (20 August 2020)

DeltaMikeAir schrieb:


> Aber dann brauche ich einen Lieferant für eine solche Generiersoftware, der etwas realistisches liefert und mir auch ehrlich sagt: "100% werden nicht möglich sein, vielleicht 90/95%"


Ich schätze, Michael, der Lieferant kann sich eigentlich nicht auf eine halbwegs präzise Angabe festlegen, da er die SonderWünsche Deiner Kunden nicht kennt und deren ErfinderGeist regelmässig unterschätzen wird. 

Neben der Vielfalt der KundenWünsche wäre sicherlich auch die Vielfalt der Steuerungs- und CPU-Typen, der ProgrammierSprachen, der (oft zu häufigen) updates etc., der auf- und abtauchenden Notwendigkeit von Workarounds ein Faktor, der nicht spurlos am ProgrammGenerator vorüber gehen kann.
Der generierte Code sollte deshalb schon "menschenlesbar" sein, da sich jederzeit ein Grund für "Handarbeit" ergeben kann, auch wenn der generierte Code schon fünf Jahre fehlerfrei funktioniert hat.


----------



## Blockmove (20 August 2020)

selmotino schrieb:


> Durch die Trennung der Logik von der Funktion ergibt sich ein neuer Blickwinkel.
> 
> Für eine Schrittkette gilt: Ablauflogik = Wann eine Achse von a nach b fährt - wenn ein Druck druckt - wenn was bewegt wird ....
> Der Treiber organisiert die Umsetzung - Wie beim PC -- egal welcher Drucker die Logik sagt drucken = Treiber übersetzt für Funktion
> ...



Auf SPS-Seite verwenden viele von uns "Treiber" mit einheitlichen Schnittstellen zum - sagen wir mal - Rest des SPS-Programmes.
Egal ob nun Schrittkette oder Regelung oder was auch immer.
Ihr habt nun ein PC-Programm erstellt um das zu automatisieren. 
Sowas kann ganz klar viel Arbeit sparen. 
Die ersten Ansätze dazu kenne ich schon aus S5-Zeiten.
Soweit - für mich persönlich - nix Aussergewöhliches.
Schwachpunkte der meisten Ansätze und Lösungen die mir bislang untergekommen sind, waren die Themen Anlagen-Erweiterung und nicht Standard-Treiber.
Welche Ansätze habt ihr dazu?
Darf die Bearbeitung des SPS-Programmes nur durch eure Software erfolgen?
Wie bindet ihr nicht Standard Hard- und Software in euere Software ein?
So mancher Hersteller verwendet geschützte Bausteine zur Kommunikation mit seiner Hardware.

Gruß
Blockmove


----------



## selmotino (20 August 2020)

ja, das war für mich der Anstoß. Ich möchte nicht kopieren sonder von NUll den Code generieren.

Die Struktur ist damit immer gleich und die Variablen immer einheitlich benannt - Bedienkonzept ist fix.

Lieferant? Du selbst nutzt das Tool. Modell erstellen - klick und IEC code erhalten


----------



## Ralle (20 August 2020)

selmotino schrieb:


> j Du selbst nutzt das Tool. Modell erstellen - klick und IEC code erhalten



Das heißt, was nicht im Modell ist kann nicht in die SPS, weil jede Änderung am Modell auch nachträgliche externe Änderungen in der SPS überschreiben würde.
Dazu muß es ein Konzept geben, also Bereiche im Code, die vom Programmierer geändert werden können und von einem neuen Modell nicht überschrieben werden.


----------



## selmotino (20 August 2020)

Unser Ansatz ist der Prozess ist im Ablauf (Logik und SYSTEM) da ist der Treiber nicht relevant.
Bei uns zeigt sich, wenn die Schrittkette beschreiben ist, ist der Prozessablauf programmiert.
Die Verknüpfung mit dem Treiber ( Position, Velo, Acc, und Execute) als Beispiel ist für jeden Treiber einer Achse gegeben.
Weitere Daten aus dem Treiber wie ERR - Betriebsdaten können müssen aber nicht vorhanden sein. Wenn nicht vorhanden durch fremd Treiber, dann einfach per Hand ausprogrammiren..


es braucht immer uns als Experten - aber wir haben ein Tool das eine Schrittkette fertig generiert ( wie früher ein Excel oder am A4 Block beschrieben) heute im Modeler beschreiben und ein Klick zur Umsetzung der Rest ist Experten wissen aber offen.

Wir liefern einen IEC Code der kann immer manuell gelesen bzw angepasst werden, wir strukturieren und generieren = IBN ist zusammen bringen von Hardware und Logik in Form von euren Funktionsbausteinen


----------



## Blockmove (20 August 2020)

Ralle schrieb:


> Das heißt, was nicht im Modell ist kann nicht in die SPS, weil jede Änderung am Modell auch nachträgliche externe Änderungen in der SPS überschreiben würde.
> Dazu muß es ein Konzept geben, also Bereiche im Code, die vom Programmierer geändert werden können und von einem neuen Modell nicht überschrieben werden.



Genau diese Aspekte würden mich auch interessieren.
Automatische Codegenerierung (egal ob nun ein simples Excel-Makro oder ein komplexes System wie Bosch Nexeed) darf nicht nur ein Grundgerüst erstellen, sondern muss auch mit Ergänzungen und Modifikationen im SPS-Programm umgehen können. Wenn ich die letzte Jahre zurück denke, dann waren vielleicht 2 Maschinen dabei, die Standardfunktionalität hatten.
Bei allen gab immer irgendwelche Spezialitäten oder auch Schweinereien


----------



## testor (20 August 2020)

selmotino schrieb:


> Unser Selmotino ist unser Generator - vielleicht Freund und Helfer für Programmierer. Professionell ist das Thema (patent - Produkt - akademisch)


Handelt es sich da um ein schon veröffentlichtes Patent?



selmotino schrieb:


> Nein Sicherheitsrelevante SPS darf nicht generiert werden!! Ist wohl ein Test


Woher kommt die Annahme? Die DGUV arbeitet nach meiner Kenntnis sogar aktiv daran Sicherheitslogik zu generieren.


----------



## selmotino (20 August 2020)

testor schrieb:


> Handelt es sich da um ein schon veröffentlichtes Patent?
> 
> 
> Woher kommt die Annahme? Die DGUV arbeitet nach meiner Kenntnis sogar aktiv daran Sicherheitslogik zu generieren.



Patent ist erteilt. Veröffentlichung liegt bei Patentamt in Österreich - international 2021 veröffentlichen (dauert eben in den Ämtern)

Ja, ich habe davon gehört. Aber bis dato darf diese nicht generiert werden und muss auch klare Regeln folgen. Unser Konzept in der nicht sicherheits relevanten Software ist aber ungefähr ähnlich:
wir sorgen dafür das jedes Bit immer überwacht ist in jedem zustand und in jedem Zustandübergang und wir machen jedes Bit sichtbar.
Jedes Bit muss im Durchlauf einer Sequence den Signalzustand wechseln.

Beispiel: 16 Zylinder = 32 Input --> SW sieht 2 hoch 32 = mehr als 4 Milliarden Möglichkeiten --< Frage welche Bitmuster ist richtig oder falsch?

Wir generieren eine exakte statemachine (schrittkette) die jedes Bit überwacht bzw den Bediener informiert was zu tun ist und im Fehlerfall (abweichung vom Bitmuster) jedes Bit klar zuordnet was fehlt

Du kannt manuell programmieren oder automatisch erstellen = spart zeit und Nerven = Fokus auf unser Kernkompetenz Gute Treiber entwickeln


----------



## selmotino (20 August 2020)

Blockmove schrieb:


> Genau diese Aspekte würden mich auch interessieren.
> Automatische Codegenerierung (egal ob nun ein simples Excel-Makro oder ein komplexes System wie Bosch Nexeed) darf nicht nur ein Grundgerüst erstellen, sondern muss auch mit Ergänzungen und Modifikationen im SPS-Programm umgehen können. Wenn ich die letzte Jahre zurück denke, dann waren vielleicht 2 Maschinen dabei, die Standardfunktionalität hatten.
> Bei allen gab immer irgendwelche Spezialitäten oder auch Schweinereien



Bosch Nexeed ist ein Versuch im Level Oberhalb von PLC zu arbeiten, so eine schnelle Anaylse. Ist OK.
Wir setzen auf der PLC an. Dann sind die Daten in einer gleichen Struktur da und können von MES usw, zusammengefasst werden.

Im Feld muss es passen, das digitale ist die SW in der Maschine.


Ja es gibt immer Spezialitäten  aber Einigkeit gibt es darüber das nur ein logischer Prozess programmierbar ist! 
Wenn der Prozess definiert ist können die Treiber natürlich speziell werden, dass macht uns ja aus.

Spar dir Zeit bei Standardstrukturen und verwende diese speziell


----------



## selmotino (20 August 2020)

Cool Frage - wir machen es so.

Wir liefern ein PRG in PLCOPEN XML --> import in PLC Änderungen an der Logik - Prozess im Modell einfach und schnell 
Verknüpfung in deinem Programm unberührt!

In Zukunft liefern wir gesamte Anlagenstruktur als XML und aufrufe - selbes Prinzip PRG tauschen ohne Beeinflussung von manuellen Programmierungen - Cool oder. wir machen uns ja nicht mehr Arbeit


----------



## DeltaMikeAir (20 August 2020)

selmotino schrieb:


> Geht. 60.000 = 16,6 / Sekunde = 60ms / Flasche bei einer Zylkuszeit von 1ms schon leistbar


Das wäre halt ein normaler Abfüller, es geht auch schneller ( 80.000 / h )  

https://www.khs.com/produkte/detail/innofill-glass-drs-eco


----------



## selmotino (20 August 2020)

Ich möchte gerade von Experten die Meinung haben, dafür besten Dank. Wir starten mit dem Tool und haben es selbst im Einsatz.
Ziel ist es Schrittketten in From von PRG Bausteinen zu generieren - die dann einfach eingesetzt werden -- wie ein Schaltwerk


----------



## DeltaMikeAir (20 August 2020)

selmotino schrieb:


> Ich möchte gerade von Experten die Meinung haben, dafür besten Dank. Wir starten mit dem Tool und haben es selbst im Einsatz.
> Ziel ist es Schrittketten in From von PRG Bausteinen zu generieren - die dann einfach eingesetzt werden -- wie ein Schaltwerk



Ja, mich interessiert es zumindest. Vielleicht erstellt ihr einmal ausführliche Videos, so dass man sich dass in Ruhe Abends mal anschauen kann.


----------



## selmotino (20 August 2020)

Heinileini schrieb:


> Ich schätze, Michael, der Lieferant kann sich eigentlich nicht auf eine halbwegs präzise Angabe festlegen, da er die SonderWünsche Deiner Kunden nicht kennt und deren ErfinderGeist regelmässig unterschätzen wird.
> 
> Neben der Vielfalt der KundenWünsche wäre sicherlich auch die Vielfalt der Steuerungs- und CPU-Typen, der ProgrammierSprachen, der (oft zu häufigen) updates etc., der auf- und abtauchenden Notwendigkeit von Workarounds ein Faktor, der nicht spurlos am ProgrammGenerator vorüber gehen kann.
> Der generierte Code sollte deshalb schon "menschenlesbar" sein, da sich jederzeit ein Grund für "Handarbeit" ergeben kann, auch wenn der generierte Code schon fünf Jahre fehlerfrei funktioniert hat.



Grundsätzlich ist das Modell des Prozesses unabhängig von der Hardware = es wird erst beim Generieren entschieden welche PLC es wird.

Der Code ist immer lesbar und verständlich als IEC Code.

Cool ist es, dass wir nun so den Prozess bzw. die SW ohne hardwarebezug modellieren und sichern können.  
Wer kennt es nicht S5 Programme wurden umgearbeitet auf S7 - oder für ein und das selbe mechanische System werden verschieden PLCs eingesetzt, weil der Kunde es fordert, alles extra zu programmieren. Das könnte sich in Zukunft ändern. Ich Wünsche es mir, weil es Zeit und Nerven spart


----------



## selmotino (20 August 2020)

DeltaMikeAir schrieb:


> Ja, mich interessiert es zumindest. Vielleicht erstellt ihr einmal ausführliche Videos, so dass man sich dass in Ruhe Abends mal anschauen kann.



Ja, wir arbeiten im Moment genau an dem. DEMO geführt und erklärt - Workplace zum selber Probieren 

Ich lade euch gerne ein zu helfen - Fragen und wir versuchen antworten zu geben 

Das Thema ist aber spannend uns wenn es uns das Leben leichter macht.


----------



## codemonkey (20 August 2020)

Der Einsatz von externen Codegeneratoren ist für mich eher uninteressant. Schon der Gedanke zusätzliche Tools mit Im-/Exportfunktionen zu verwenden ist mir ein Graus. Dazu kommt, dass ich in der Regel die SPS und HMI Bestandteile als Einheit betrachte. Fällt mir schwer den Vorteil zu erkennen, den die Generierung von Schrittketten bietet, wenn man es mit den grafischen Tools aus der SPS IDE vergleicht.

Eine integrierte Codegenerierung in der IDE von TIA/TwinCAT/Codesys/usw. hingegen finde ich schon interessanter, wenn mach nicht zwingend erforderlich. Eine Art Makro das ein Formular abarbeitet um die Anzahl von Stationen, Achsen, Subsystemen in SPS und Visu vorzukonfigurieren. Derzeit löse ich dies allerdings mit einigen Konstanten, die mir die Größe von Arrays bestimmen und damit bin ich auch schon sehr zufrieden.


----------



## Ralle (20 August 2020)

@SelmoTino

Schätze die Codegenerierung schließt so etwas wie Graph aus?
Können eure Schrittketten Alternative Verzweigungen, z. Bsp. Produktabhängig etc.?


----------



## Blockmove (20 August 2020)

selmotino schrieb:


> Ich möchte gerade von Experten die Meinung haben, dafür besten Dank. Wir starten mit dem Tool und haben es selbst im Einsatz.
> Ziel ist es Schrittketten in From von PRG Bausteinen zu generieren - die dann einfach eingesetzt werden -- wie ein Schaltwerk



Wenn ich meine Arbeitsweise betrachte, dann ist das Programmieren der Schrittketten beinahe der geringste Aufwand.
Nimmt man Tools wie Graph und ProDiag dann spart man ungeheuer Zeit. Diagnose im HMI ist bei der Kombination quasi ein Abfallprodukt und erfordert nahezu keinen Aufwand.

Für das Erstellen der Handfunktionen inklusive der Verriegelungen geht deutlich mehr Zeit drauf.
Und das obwohl wir auch Treiber-Bausteine verwenden.


----------



## selmotino (20 August 2020)

Blockmove schrieb:


> Wenn ich meine Arbeitsweise betrachte, dann ist das Programmieren der Schrittketten beinahe der geringste Aufwand.
> Nimmt man Tools wie Graph und ProDiag dann spart man ungeheuer Zeit. Diagnose im HMI ist bei der Kombination quasi ein Abfallprodukt und erfordert nahezu keinen Aufwand.
> 
> Für das Erstellen der Handfunktionen inklusive der Verriegelungen geht deutlich mehr Zeit drauf.
> Und das obwohl wir auch Treiber-Bausteine verwenden.



Verriegelungen werden bei uns mit modelliert und stehen dem User als Meldung zur Verfügung, wenn er etwas ausführen möchte was nicht erlaubt ist.
Ich würde gerne deine Einschätzung für eine einfach Schtittkette Zeit?


----------



## Blockmove (20 August 2020)

selmotino schrieb:


> Verriegelungen werden bei uns mit modelliert und stehen dem User als Meldung zur Verfügung, wenn er etwas ausführen möchte was nicht erlaubt ist.
> Ich würde gerne deine Einschätzung für eine einfach Schtittkette Zeit?



Da wir, so wie du auch, Treiberbausteine mit entsprechenden Strukturen verwenden, ist eine einfache Graphkette auch in kurzer Zeit (20 - 30min) erstellt.
Für Betriebsarten haben wir auch fertige Templates. Grösster Zeitaufwand steckt im Beschalten der Treiberbausteine mit den ganzen E/As und dem Erstellen der Verriegelungen.
HMI ist auch ein Zeitfresser, da aus den CAD-Modellen erst passende PNGs erstellt werden müssen. Für den Rest haben wir auch Bildbausteine.

Programmiert man klassische Schrittketten und ohne Treiberbausteine, dann kann eure Lösung ganz massiv Zeit und Aufwand sparen.


----------



## selmotino (21 August 2020)

Blockmove schrieb:


> Da wir, so wie du auch, Treiberbausteine mit entsprechenden Strukturen verwenden, ist eine einfache Graphkette auch in kurzer Zeit (20 - 30min) erstellt.
> Für Betriebsarten haben wir auch fertige Templates. Grösster Zeitaufwand steckt im Beschalten der Treiberbausteine mit den ganzen E/As und dem Erstellen der Verriegelungen.
> HMI ist auch ein Zeitfresser, da aus den CAD-Modellen erst passende PNGs erstellt werden müssen. Für den Rest haben wir auch Bildbausteine.
> 
> Programmiert man klassische Schrittketten und ohne Treiberbausteine, dann kann eure Lösung ganz massiv Zeit und Aufwand sparen.



danke für die Einschätzung. Es fehlt aber ein entscheidender Faktor. Graphketten beruhen auf State und Transition - schalte weiter wenn das und das usw. 
Wie schaffst du es mit dem Graph (Petrinetz) alles möglichen Bitmuster abzubilden ?
Wie schaffst du es mit dem Graph das System ständig zu überwachen und jedes Bit in der Schrittkette zu überwachen?
Wir haben eben genau das in unserem Tool geschafft. Jedes Bit ist immer überwacht und nur die Zustände (damit meine ich jede Kombination von Bitmuster ) die wir definierten sind erlaubt.
Damit erzeugen wir eine Qualität die Schrittketten 100% definiert.

Wie schafft ihr es das alle Programmierer die Strukturen und Nomenklatur der Variablen einhalten?
Wie schafft ihr es das jede abweichende Bit am HMI steht?

Entschuldige die vielen Fragen, aber ich möchte offen diskutieren und auch die Dinge ansprechen die faktisch da sind.


----------



## selmotino (21 August 2020)

codemonkey schrieb:


> Der Einsatz von externen Codegeneratoren ist für mich eher uninteressant. Schon der Gedanke zusätzliche Tools mit Im-/Exportfunktionen zu verwenden ist mir ein Graus. Dazu kommt, dass ich in der Regel die SPS und HMI Bestandteile als Einheit betrachte. Fällt mir schwer den Vorteil zu erkennen, den die Generierung von Schrittketten bietet, wenn man es mit den grafischen Tools aus der SPS IDE vergleicht.
> 
> Eine integrierte Codegenerierung in der IDE von TIA/TwinCAT/Codesys/usw. hingegen finde ich schon interessanter, wenn mach nicht zwingend erforderlich. Eine Art Makro das ein Formular abarbeitet um die Anzahl von Stationen, Achsen, Subsystemen in SPS und Visu vorzukonfigurieren. Derzeit löse ich dies allerdings mit einigen Konstanten, die mir die Größe von Arrays bestimmen und damit bin ich auch schon sehr zufrieden.



Klar, auch wir sehen die Zukunft das unsere Idee und Tool integriert wird in der IDE. Jetzt arbeiten wir eben mit PLCOpen XML import und es ist sehr einfach und am Ende hast PLC und HMI, wie du sagst in einem gemacht. 

Ich komme noch aus einer Zeit da hat es noch keine Lade Transferiere gegeben - wir haben solche Funktionen auch noch manuell gemacht - später wurde es Standard und es gibt heute noch Anhänger von selbst programmieren.

Was ich sagen möchte - Dinge ändern sich


----------



## selmotino (21 August 2020)

Ralle schrieb:


> @SelmoTino
> 
> Schätze die Codegenerierung schließt so etwas wie Graph aus?
> Können eure Schrittketten Alternative Verzweigungen, z. Bsp. Produktabhängig etc.?



Der Graph schaltet wenn das und das  - Transition / Wie schalten wenn nix dagegen spricht, damit ist die Anzeige möglich

Ja, alternative Verzweigungen = synchrone Schrittketten  Diese Frage kommt immer von AS Programmierer:wink:


----------



## Blockmove (21 August 2020)

selmotino schrieb:


> Es fehlt aber ein entscheidender Faktor. Graphketten beruhen auf State und Transition - schalte weiter wenn das und das usw.
> Wie schaffst du es mit dem Graph (Petrinetz) alles möglichen Bitmuster abzubilden ?
> Wie schaffst du es mit dem Graph das System ständig zu überwachen und jedes Bit in der Schrittkette zu überwachen?


Wozu soll ich in der Schrittkette alle Bitmuster überwachen? Mir erschliesst sich hier nicht ganz der Sinn.
Die Schrittkette startet aus definierten Bedingungen heraus und führt dann die programmierten Aktionen aus.
Zum Ausführen bzw. beim Ausführen der Aktionen müssen die Verriegelungen erfüllt sein. Diese werden überwacht.
Zum einen durch die Kette selbst und zum anderen durch die Treiberbausteine.
Unabhängig von den Verriegelungen überwachen die Treiber den Verlust einer Endlage permanent.

Das komplette Überwachen aller Zustände habe ich auch schon Ende der 90er mal programmiert.
War mal ein Konzept für Kleinanlagen um Abläufe direkt am Panel (damals Textdisplay OP17) ohne Programmierung zu erstellen.
Jedem Schritt konnten bis zu 16 Aktoren zugeordnet werden, 32 Bits für die Verriegelung und 32 Bits fürs Weiterschalten.
Einfach ein paar Array mit Doppelworten.



> Wie schafft ihr es das alle Programmierer die Strukturen und Nomenklatur der Variablen einhalten?


Gar nicht. Wir haben Grundregeln aber jeder von uns hat auch etwas seinen eigenen Stil



> Wie schafft ihr es das jede abweichende Bit am HMI steht?


Die Diagnose erfolgt über Treiberbausteine und ProDiag.
Jedes abweichende Bit interessiert mich überhaupt nicht.
Mich interessieren nur Bits die aktuell Einfluß auf den Prozess haben.
Alles andere führt u.U. zu Fehlalarmen.


----------



## Ralle (21 August 2020)

selmotino schrieb:


> Der Graph schaltet wenn das und das  - Transition / Wie schalten wenn nix dagegen spricht, damit ist die Anzeige möglich
> Diese Frage kommt immer von AS Programmierer:wink:



Das erklärst du dem Idioten AS-Programmiere mal genauer. Graph schaltet wenn was dagegenspricht? Wenn ihr Schrittkettenabläufer erstellt, ist das dann was anderes als AS? 



selmotino schrieb:


> Ja, alternative Verzweigungen = synchrone Schrittketten



Nein, keine sychrone Schrittkette, alternative Schrittkette, war gemeint.
Parallelverzweigung und "gleichzeitige" Abarbeitung ist natürlich auch sinnvoll, sollte schon gehen.

Ich hätte schon mal gerne mehr als Worthülsen und allgemeines rumgelaber gehört. Bisher hast du nichts wirklich zufriedenstellend beantwortet.
Man hört nur das is cool, dies ist besonders cool. Easy, nur ein Klick. Es ist sehr einfach. 
Danker Herr Alles Cool, ich weiß niun für meinen Teil bescheid.


----------



## Heinileini (21 August 2020)

selmotino schrieb:


> Ich komme noch aus einer Zeit da hat es noch keine Lade Transferiere gegeben - wir haben solche Funktionen auch noch manuell gemacht - später wurde es Standard und es gibt heute noch Anhänger von selbst programmieren.


 War das jetzt zur Zeit der Zuse 1 oder bei S3?
Ich komme aus der S5-Zeit. Da gab es schon Lade und Transferiere. L MW0 T MW2 z.B. oder U M0.0 = M0.1. 
Bei WordStar gab es schon die Vorgänger von Copy und Paste, die auch heute noch funktionieren, nämlich ^C und ^V (wobei mit ^ die CTRL- bzw. Strg-Taste gemeint ist).
Teile von S5-Bausteinen konnte man allerdings nicht in den Editor des PGs laden oder von dort irgendwohin transferieren. Nur komplette Projekte, sowie komplette Bausteine oder Gruppierungen davon (z.B. alle DBs oder alle PBs u.s.w.) von einem Projekt in ein anderes. Ins AG und aus dem AG, in EPROMs und aus EPROMs konnten nur die "abgespeckten" MC5-BestandTeile der Bausteine geladen bzw. transferiert werden.
QuellCode im Sinne eines Menschen-lesbaren Textes bzw. mit aus ASCII-Zeichen gebastelten Kästchen oder Symbolen (FUP/KOP) gab es in DateiForm nur, wenn man eine DruckAusgabe in eine Datei umgeleitet hat.
Ob es überhaupt irgendwann möglich wurde bzw. seit wann man evtl. per Paste und Copy Teile von Bausteinen innerhalb eines S5-Editors oder von einem S5-Editor in einen "normalen" Editor oder umgekehrt "transferieren" konnte, weiss ich gar nicht mehr. An Einsparung von TippArbeit, ggfs durch Kopieren und Anpassen von Vorlagen, oder an vor- und aufbereiten in Excel war nicht zu denken.
Aber handgemachte Lade- und Transfer-Funktionen? Aus was gemacht? Laden und Transferieren eines Wortes durch Laden und Transferieren 16 einzelner Bits? Allenfalls die integrierte PLC der 810er NC hätte Anlass zu ähnlich umständlichen Aktionen gegeben, hatte aber nicht den für solche Exzesse nötigen ProgrammSpeicherPlatz.

Ja, es gibt tatsächlich heute noch Anhänger von selbst programmieren. Denn das Suchen von vorgefertigten Funktionen, die auch noch für den gewünschten Zweck passen und trotzdem nicht hoffnungslos überdimensioniert sind, ist oft viel zeitraubender, als das SelbstProgrammieren. 



Blockmove schrieb:


> Wozu soll ich in der Schrittkette alle Bitmuster überwachen? Mir erschliesst sich hier nicht ganz der Sinn.
> ...
> Jedes abweichende Bit interessiert mich überhaupt nicht.
> Mich interessieren nur Bits die aktuell Einfluß auf den Prozess haben.
> Alles andere führt u.U. zu Fehlalarmen.


Das ist was für alle Skeptiker, die sich einerseits vor kippenden Bits in SpeicherMedien (HW!) fürchten und andererseits vor bislang unbemerkten DoppelBelegungen (z.B. Überschneidungen von belegten Bereichen) in der SW. 
Das sind dann FehlAlarme nur in dem Sinne, dass sie mit der eigentlichen Funktion nix zu tun haben, aber die gemeldeten - weil zufällig nebenbei gefundenen - Fehler sollten durchaus nicht ignoriert werden. 
Man muss sich schliesslich dagegen absichern, dass die Funktion des generierten Codes durch den AmateurCode drumherum zerschossen wird.


----------



## Thomas_v2.1 (21 August 2020)

Ralle schrieb:


> Das erklärst du dem Idioten AS-Programmiere mal genauer. Graph schaltet wenn was dagegenspricht? Wenn ihr Schrittkettenabläufer erstellt, ist das dann was anderes als AS?



Jemand mit Informatik-Hintergrund wird bei der automatischen Codegenerierung vermutlich nicht etwas wie eine handgeschriebene Schrittkette erzeugen, sondern etwas was auch aus dem Compilerbau bekannt ist, mit Parsertabellen die einige Parser wie z.B. yacc erzeugen. Im Parser sind dann nur noch ein oder mehrere Arrays mit den Zuständen und Transitionen, der Code für den eigentlichen Automaten ist dann immer gleich.


----------



## testor (21 August 2020)

Thomas_v2.1 schrieb:


> Jemand mit Informatik-Hintergrund wird bei der automatischen Codegenerierung vermutlich nicht etwas wie eine handgeschriebene Schrittkette erzeugen, sondern etwas was auch aus dem Compilerbau bekannt ist, mit Parsertabellen die einige Parser wie z.B. yacc erzeugen. Im Parser sind dann nur noch ein oder mehrere Arrays mit den Zuständen und Transitionen, der Code für den eigentlichen Automaten ist dann immer gleich.


Die Befürchtung habe ich auch. In die Richtung gehen auch einige Forschungsarbeiten die ich kenne. So wie ich mir das dann vorstelle, fehlt mir aber die menschliche Nachvollziebarkeit und entsprechend auch die Möglichkeit dies selber zu Programmieren. Wenn die Transitionen ALLE bits betrachten, kann das ja schnell unübersichtlich werden.


----------



## Ralle (21 August 2020)

Und wenn es kracht (was schon mal ab uns an passiert sein soll), begibt man sich in der Modelldefinition auf die Suche. Bin ich dann doch mal gespannt auf erste "Selbst"-Tests, wenn es denn mal irgendwann möglich ist.


----------



## Thomas_v2.1 (21 August 2020)

Das Prinzip ist aber schon sehr alt. Das ist auch im Drachenbuch beschrieben, und dessen Erstausgabe ist von 1977.
Was erzeugt denn Siemens Graph für einen Code, hat sich das schon einmal jemand angesehen? Ich kann mir nicht vorstellen, dass dort die gesamte Schrittkette wie in AWL/FUP etc. auscodiert generiert wird.


----------



## Blockmove (21 August 2020)

testor schrieb:


> Die Befürchtung habe ich auch. In die Richtung gehen auch einige Forschungsarbeiten die ich kenne. So wie ich mir das dann vorstelle, fehlt mir aber die menschliche Nachvollziebarkeit und entsprechend auch die Möglichkeit dies selber zu Programmieren. Wenn die Transitionen ALLE bits betrachten, kann das ja schnell unübersichtlich werden.



Ich frag mich nur was daran patentwürdig ist.
Was selmotiono hier bisher preisgegeben hat, ist doch eigentlich nichts grundlegend Neues.
Schrittabhängige Überwachung des gesamten Prozessabbildes kenne ich noch aus S5-Zeiten.
Damals noch auf einem eigenen Rechner.
Die Forschungsansätze von Siemens, Fraunhofer usw. gehen teilweise in die selbe Richtung.
Bei der virtuellen Inbetriebnahme am 3D-CAD-Modell werden die Aktoren verfahren, die Sensoren erfasst und Zustände so geteached.
Daraus werden dann Statemachines erzeugt.

Sind östereichische Patente eigentlich kostenlos einsehbar?


----------



## testor (21 August 2020)

Blockmove schrieb:


> Ich frag mich nur was daran patentwürdig ist.
> Was selmotiono hier bisher preisgegeben hat, ist doch eigentlich nichts grundlegend Neues.
> Schrittabhängige Überwachung des gesamten Prozessabbildes kenne ich noch aus S5-Zeiten.
> Damals noch auf einem eigenen Rechner.
> ...



Laut Patentamt noch nicht erteilt und nicht veröffentlicht:
http://see-ip.patentamt.at/NPatentSuche/Details/93fefb4d-4df3-453e-8dcd-c98aff28818b

In Deutschland dauert es 18 Monate von Einreichung bis zur Veröffentlichung.

Die Disskussion geht meiner Meinung nach nur in die falsche Richtung. Ich bin ja eigentlich ein Freund von sinnvoller Codegenerierung zu Vereinfachung des Engineerings. Allerdings nicht auf Kosten der Vorteile von SPS Programmierung.


----------



## Ralle (21 August 2020)

testor schrieb:


> Laut Patentamt noch nicht erteilt und nicht veröffentlicht:
> http://see-ip.patentamt.at/NPatentSuche/Details/93fefb4d-4df3-453e-8dcd-c98aff28818b
> 
> In Deutschland dauert es 18 Monate von Einreichung bis zur Veröffentlichung.
> ...



Das hat mit vor 20 Jahren (wirklich) schon einmal jemand gezeigt, der hat das damals mit Delphi programmiert. Das "Modell" damals waren praktisch die Bezeichnungen der E/A. Aber er hat dann wohl auch irgendwann damit aufgehört, viel Arbeit, dafür zu geringer nutzen damals. Denn das Problem ist immer, wer kauft das Korsett...
Patentwürdig finde ich persönlich daran auch nichts,  aber schaut euch manche Apple-Patente an. (Abgerundete Ecken am Smartphone).


----------



## Blockmove (22 August 2020)

testor schrieb:


> Ich bin ja eigentlich ein Freund von sinnvoller Codegenerierung zu Vereinfachung des Engineerings. Allerdings nicht auf Kosten der Vorteile von SPS Programmierung.



Ich bin da mittlerweile etwas zwiegespalten. Einer der Hauptvorteile der SPS ist das Online-Beobachten (Status).
Aber gerade durch die immer besseren Möglichkeiten zur Diagnose und Fehlererkennung benötigt man das im Störungsfall immer seltener.
Schönes Beispiel ist hier Siemens ProDiag.
Ich habs bei einer der letzten Anlagen verglichen. Ich hab vor einigen eine ähnliche Anlage mit Classic und Bitmeldungen gemacht. Ca. 250 Störmeldungen.
Die ähnliche Anlage nun mit TIA und ProDiag. Es gibt nun über 600 Störmeldungen. Ein Großteil automatisch erzeugt.
Bin mal gespannt, wo die Reise hin geht.


----------



## selmotino (24 August 2020)

testor schrieb:


> Laut Patentamt noch nicht erteilt und nicht veröffentlicht:
> http://see-ip.patentamt.at/NPatentSuche/Details/93fefb4d-4df3-453e-8dcd-c98aff28818b
> 
> In Deutschland dauert es 18 Monate von Einreichung bis zur Veröffentlichung.
> ...



Patentprozess dauert 18 Monate. Die Veröffentlichung bestimmt das Amt. Im SPS Forum geht es ja nicht um Patentprozess oder.

Das Verfahren ist ganz einfach neu und ist eben nicht einfach vergleichbar mit altbekannten. Wir haben uns aber bemüht auf der Website das Thema zu beschreiben.


----------



## selmotino (24 August 2020)

Blockmove schrieb:


> Ich bin da mittlerweile etwas zwiegespalten. Einer der Hauptvorteile der SPS ist das Online-Beobachten (Status).
> Aber gerade durch die immer besseren Möglichkeiten zur Diagnose und Fehlererkennung benötigt man das im Störungsfall immer seltener.
> Schönes Beispiel ist hier Siemens ProDiag.
> Ich habs bei einer der letzten Anlagen verglichen. Ich hab vor einigen eine ähnliche Anlage mit Classic und Bitmeldungen gemacht. Ca. 250 Störmeldungen.
> ...



ProDiag schein ein Tool zu sein, dass ohne Bezug auf die Logik einzelne Signale überwacht. (Bei uns sind das CMZ und werden ständig und schritt unabhängig überwacht).

Der Vorteil der SPS Programmierung ist in allen Fällen nicht in Frage gestellt. Wir reden von Tools für die leichter erstellen von CODE.


----------



## selmotino (24 August 2020)

Ralle schrieb:


> Das erklärst du dem Idioten AS-Programmiere mal genauer. Graph schaltet wenn was dagegenspricht? Wenn ihr Schrittkettenabläufer erstellt, ist das dann was anderes als AS



AS passiert auf Petri Netze oder auf Zustandsautomaten. Da dient die Transition der Weiterschaltung = wenn das und das ... dann weiterschalten
Damit ist mit jedem Signal das am Automaten angeschlossen ist eine Potenz mehr 2 hoch Anzahl der Signale

Das löst du bitte nun so in der AS das immer jedes Signal (Bitmuster ) richtig ist. In jedem Zustand und bei jedem Übergang.

Wir wollen nur aufzeigen, dass es eine einfach Möglichkeit gibt, muss ja nicht so machen - wenn du dich nicht damit beschäftigen willst. Es gibt eben immer einen Fortschritt.


----------



## rostiger Nagel (24 August 2020)

selmotino schrieb:


> ProDiag schein ein Tool zu sein, dass ohne Bezug auf die Logik einzelne Signale überwacht. (Bei uns sind das CMZ und werden ständig und schritt unabhängig überwacht).
> 
> Der Vorteil der SPS Programmierung ist in allen Fällen nicht in Frage gestellt. Wir reden von Tools für die leichter erstellen von CODE.



Wie definiert ihr den welche Signale überwacht werden sollen?
Und was soll überwacht werden?


----------



## selmotino (24 August 2020)

Ralle schrieb:


> Nein, keine sychrone Schrittkette, alternative Schrittkette, war gemeint.
> Parallelverzweigung und "gleichzeitige" Abarbeitung ist natürlich auch sinnvoll, sollte schon gehen.



Wir halten uns an Timer - Ablauf - Schleife - Entscheidung (deine Frage ist dann mit Entscheidung zu beantworten)

alternativ ist eine Entscheidung


----------



## selmotino (24 August 2020)

rostiger Nagel schrieb:


> Wie definiert ihr den welche Signale überwacht werden sollen?
> Und was soll überwacht werden?



Jedes Bit ist überwacht - Jede Schrittkette verarbeitet Bits und es gibt schrittbezogene und schrittunabhängige Überwachung.
Überwacht wird der richtige Zustand = 0 oder 1 

Beispiel: wenn eine Lichtschranke im ersten Schritt belegt werden soll und dann belegt bleibt bis Schritt 5 dann wird das exakt überwacht (1 wird 1 - bis 5 auf 1 dann bis ende 0 )
Jedes Bit wird auf Belegt und nicht Belegt definiert ! So ist zu jedem Zeitpunkt das Signal überwacht und bei Abweichung sofort klar was fehlt.


----------



## selmotino (24 August 2020)

testor schrieb:


> Die Befürchtung habe ich auch. In die Richtung gehen auch einige Forschungsarbeiten die ich kenne. So wie ich mir das dann vorstelle, fehlt mir aber die menschliche Nachvollziebarkeit und entsprechend auch die Möglichkeit dies selber zu Programmieren. Wenn die Transitionen ALLE bits betrachten, kann das ja schnell unübersichtlich werden.



Am Punkt schnell unübersichtlich und fast unmöglich. Ist aber nicht Grund genug eine Lösung zu suchen. Das zeichnet den PLC Programmierer aus. Offen und lösungsorientiert.


----------



## Blockmove (24 August 2020)

selmotino schrieb:


> Damit ist mit jedem Signal das am Automaten angeschlossen ist eine Potenz mehr 2 hoch Anzahl der Signale
> Das löst du bitte nun so in der AS das immer jedes Signal (Bitmuster ) richtig ist. In jedem Zustand und bei jedem Übergang.



Die 2 hoch n - Signale machen sich vielleicht im Marketingprospekt gut, in der Realität mappe ich Ein- und Ausgänge auf Doppelworte und arbeite dann mit den Bitmustern.


----------



## Ralle (24 August 2020)

Nichts für ungut. Ich bin raus aus dem Thema, für das ganze Gesülze ist mir meine Zeit zu schade. Heiße Luft pur. Das ist Alles weit ab jeder praktischen Anwendung. Ich glaube kaum, dass so eine "ALLES überwachte" Maschine wirklich stabil läuft. Mit etwas Glück wirft die nur alle 20 Sekunden irgendeinen Fehler. Hab ich übrigens auch schon mal sehen dürfen/müssen. Wenn du an Station 18 einen INI-Fehler an einer Luftklappe hast, bleibt der Servo an Station stehen oder crasht mal eben. Viel Spaß und viel Erfolg. Ihr schafft das.


----------



## DeltaMikeAir (24 August 2020)

Blockmove schrieb:


> Die 2 hoch n - Signale machen sich vielleicht im Marketingprospekt gut, in der Realität mappe ich Ein- und Ausgänge auf Doppelworte und arbeite dann mit den Bitmustern.



Ja, ich muss sagen als der Satz kam:


selmotino schrieb:


> Beispiel: 16 Zylinder = 32 Input --> SW sieht 2 hoch 32 = mehr als 4  Milliarden Möglichkeiten --< Frage welche Bitmuster ist richtig oder  falsch?



war ich zwischen entäuscht und belustigt zugleich und habe mich gefragt wie wir unsere Anlagen mit > 50 Pneumatikzylindern á 2 Abfragen je zu laufen
bekommen haben. Das wären ja > 1.1258999e+15 Möglichkeiten.

Soviel dazu. Oder braucht man da einen Quantencomputer für Anlagen mit > 100 Zylindern.


----------



## rostiger Nagel (24 August 2020)

Vor allen Dingen wer braucht so etwas..?


----------



## SPSKILLER (24 August 2020)

Ihr blickts bloß net ROFLMAO

Vom Generieren der Automatikbedingungen halte ich nicht viel.
Entweder man programmiert die Logik dann in irgendeinem Tool nach, dann kann ich’s gleich im S7 machen... oder das Tool weiß automatisch welche Logik ich benötige!? Passt nie 100%, und das Korrigieren und Prüfen baucht auch Zeit und Nerven... dann kann ich’s gleich im S7 sauber und richtig machen.
Da ich aber eigentlich ein fauler Sack bin, generiere ich mir meine Symbolik und die Bausteinaufrufe (Motoren, Ventile, Binär-/Analogwerte usw. - die ganze Fleißarbeit bei einem Projekt halt) auch automatisch via Excel.

Grüße

Micha


----------



## Blockmove (25 August 2020)

DeltaMikeAir schrieb:


> Soviel dazu. Oder braucht man da einen Quantencomputer für Anlagen mit > 100 Zylindern.



Und wir meckern die Ganze Zeit an Siemens rum.
In Wirklichkeit sind unsere Steuerungen zu solchen Höchstleistungen fähig 

Ich hab auch schon mit der skizzierten Dauerüberwachung gearbeitet.
Das Thema Fehlalarme bzw. nicht relevante Alarme wurde ja schon angesprochen.
Und das Erste was ich damals nachgerüstet hab, war die Möglichkeit diese zu verhindern.

Letztlich haben wir die Entwicklung des Systems gestoppt, da der Benefit zu gering war.


----------



## selmotino (26 August 2020)

OK. Es war ein Versuch mit PLC Profis zu diskutieren. Wir arbeiten an einer Lösung die für Einsteiger und Profis funktioniert und den Prozessablauf ins Zentrum stellt. Die Struktur und Software die dann entsteht ist eben neu und nicht leicht zu greifen. Es liegt mir auch fern die Vergangenheit zu bewerten. wir sehen in die Zukunft und es gibt ein breites Feld für einfache Schrittketten die anstatt manuell programmiert einfach modelliert werden. Excel Listen und dann übersetzten in PLC Code ist scheinbar noch State of the art. Ich habe vieles von dem erlebt und realisiert. Ich blieb offen und innovativ, habe mich mit neuen Methoden auseinander gesetzt und dann bewertet. Das führt zu unserer Idee. 

Wir machen es für TwinCat 3 und auf Windows und für weitere Ideen frag ich dann einfach nochmal nach. Besser ist leichter.


----------



## rostiger Nagel (26 August 2020)

Ähm, du hast es doch noch nicht einmal vorgestellt, so das man es beurteilen kann.
Eure HomePage gibt auch keine Info preis. Wer will den so etwas kommerziell einsetzen?
Man hat doch den Kunden gegenüber eine gewisse Verpflichtung und Verantwortung.


----------



## DeltaMikeAir (26 August 2020)

selmotino schrieb:


> OK. Es war ein Versuch mit PLC Profis zu diskutieren. Wir arbeiten an einer Lösung die für Einsteiger und Profis funktioniert und den Prozessablauf ins Zentrum stellt. Die Struktur und Software die dann entsteht ist eben neu und nicht leicht zu greifen. Es liegt mir auch fern die Vergangenheit zu bewerten. wir sehen in die Zukunft und es gibt ein breites Feld für einfache Schrittketten die anstatt manuell programmiert einfach modelliert werden. Excel Listen und dann übersetzten in PLC Code ist scheinbar noch State of the art. Ich habe vieles von dem erlebt und realisiert. Ich blieb offen und innovativ, habe mich mit neuen Methoden auseinander gesetzt und dann bewertet. Das führt zu unserer Idee.
> 
> Wir machen es für TwinCat 3 und auf Windows und für weitere Ideen frag ich dann einfach nochmal nach. Besser ist leichter.



Ganz ehrlich, von dir kommen keine konkrete Beispiele, mal ein Video oder vernünftige Antworten auf konkrete Fragen. Überwiegend
nur Worthülsen und wie toll dass doch ist.

Und dann noch dass hier:


selmotino schrieb:


> Patent ist erteilt.






testor schrieb:


> Laut Patentamt noch nicht erteilt und nicht veröffentlicht:
> http://see-ip.patentamt.at/NPatentSuche/Details/93fefb4d-4df3-453e-8dcd-c98aff28818b





selmotino schrieb:


> Patentprozess dauert 18 Monate. Die Veröffentlichung bestimmt das Amt. Im SPS Forum geht es ja nicht um Patentprozess oder.



Zuerst ist das Patent erteilt, dann auf einmal doch nicht.....


Naja


----------



## rostiger Nagel (26 August 2020)

DeltaMikeAir schrieb:


> Zuerst ist das Patent erteilt, dann auf einmal doch nicht.....



„Erteilt“ oder „Beantragt“ sind beim Patent schon gravierende Punkte.


----------



## selmotino (26 August 2020)

rostiger Nagel schrieb:


> „Erteilt“ oder „Beantragt“ sind beim Patent schon gravierende Punkte.



Scheinbar ist hier nicht die Technik Thema, sondern das Patent. Ich gehe davon aus das nach 18 Monate die Veröffentlichung passiert. Nicht beeinflussbar vom Erfinder.
PLC Programmierer mit Patent Erfahrung? OK. Hast auch schon patentiert?

Nichts für ungut, aber das tut hierzu nichts zur Sache.


----------



## selmotino (26 August 2020)

DeltaMikeAir schrieb:


> Ganz ehrlich, von dir kommen keine konkrete Beispiele, mal ein Video oder vernünftige Antworten auf konkrete Fragen. Überwiegend
> nur Worthülsen und wie toll dass doch ist.
> 
> Und dann noch dass hier:
> ...




Naja, lese unseren Techblog und lass dann etwas zur Sache hören. Ich denke es ist nicht wirklich angebracht so abwertend zu sein. Neu ist eben nicht immer angenehm. Aber lesen bringt auch dich weiter. Sorry, aber ich versuche mal deutlich zu sein. Ich höre von dir nur altes. Lesen ist fast so gut wie Video schauen


----------



## DeltaMikeAir (26 August 2020)

Ja, passt schon.

Viel Erfolg

PS.
Ich finde keinen TechBlog


----------



## selmotino (26 August 2020)

Danke. Bin für jede Meinung dankbar. Sollte aber fachlich und bemüht sein.


----------



## testor (27 August 2020)

selmotino schrieb:


> Scheinbar ist hier nicht die Technik Thema, sondern das Patent. Ich gehe davon aus das nach 18 Monate die Veröffentlichung passiert. Nicht beeinflussbar vom Erfinder.
> PLC Programmierer mit Patent Erfahrung? OK. Hast auch schon patentiert?
> 
> Nichts für ungut, aber das tut hierzu nichts zur Sache.



PLC Programmierer sind also zu dumm um zu erfinden? 
Ich kenne einige Kollegen, die bereits "patentiert" haben. Das bringt der Job nunmal so mit sich. 
Ich habe so ein wenig das Gefühl das du dem gemeinen PLC Programmierer wenig zu traust.
Das Patent ist interessant, weil es nunmal aufzeigen muss was dort gemacht wird. Etwas was anscheinend einige hier von dir selbst vermissen. Wir wollen halt stabile Anlagen programmieren und gerade wenn es in den Bereich Code Generierung geht, braucht man als Nutzer vertrauen in das zu Grunde gelegte Verfahren. Alles was ich aus den zugänglichen Informationen rauslese, lässt vermuten das euer Code generierungs tool einfach nur ein Black Box System schafft. Das wäre für mich ein KO Kriterium. 
Mich persönlich interessiert das Patent, weil ich aus eigener Erfahrung weiß wie schwer es ist Verfahren zur Code Generierung (zumindest in Deutschland) patentieren. Das liegt zum einen an der Prior art zum anderen an den höheren Hürden für "Softwarepatente".


----------



## rostiger Nagel (27 August 2020)

selmotino schrieb:


> OK. Hast auch schon patentiert?



Nein habe ich noch nicht, ich habe aber auch noch nicht behauptet das
ich ein Patent habe, was ich eigentlich erst beantragt habe.
Es ging nicht um das Patent an sich, sondern um deine Aussage, die
einfach nicht richtig war.
So wie ein Bit ist "1" was eigentlich "0" ist, wird aber bald gesetzt.
Oder die Wand ist "Schwarz" aber ist "Weiß" und wird noch Schwarz gestrichen.
Beantragt ist nicht erhalten.


----------



## DeltaMikeAir (27 August 2020)

Wie kommt man denn auf den genannten TechBlog?


----------



## marlob (27 August 2020)

DeltaMikeAir schrieb:


> Wie kommt man denn auf den genannten TechBlog?


Vielleicht meint er den SelmoBlog


----------



## DeltaMikeAir (27 August 2020)

Danke,

habe mir folgendes Video einmal angeschaut:
https://selmo.at/demo-tour-selmomodeler/


----------



## DeltaMikeAir (27 August 2020)

Hier gibts auch Videos zu dem patentierten System
https://www.youtube.com/watch?v=1XfV1SyMlYU


----------



## Hohlkörper (27 August 2020)

Wie viele Softwarefehler darf das Tool selbst haben um damit noch den versprochenen fehlerfreien Code erzeugen zu können?


----------



## rostiger Nagel (27 August 2020)

DeltaMikeAir schrieb:


> Danke,
> 
> habe mir folgendes Video einmal angeschaut:
> https://selmo.at/demo-tour-selmomodeler/



Habe ich mir auch mal Angeschaut, was ist den da schneller,
als wenn ich das in TIA und Graph löse. Wenn ich im Schritt
den Aktor mit "N" zuweise, kann ich davon ausgehen das dieser
auch nur in diesen Schritt gesetzt wird. Da benötige ich keine
weiteren Überwachungen.
Den Graph FB könnte ich auch Instanzieren.
Wenn jetzt daraus eine HMI entstanden wäre, könnte es Intressant
werden. Allerdings war zeigt sich das nicht.


----------



## DeltaMikeAir (27 August 2020)

> Habe ich mir auch mal Angeschaut, was ist den da schneller



Kann ich nicht sagen, wird dort auch nicht gesagt. Mit so 2 Zylinderchen Maschinen scheint es ja zu klappen,
die sollen mir dass mal für eine Palettieranlage mit Sortenvorwahl, Rezepturen 4 verschiedenen Palettentypen
vorführen, wie lange da modeliert wird.


----------



## rostiger Nagel (27 August 2020)

DeltaMikeAir schrieb:


> Kann ich nicht sagen, wird dort auch nicht gesagt. Mit so 2 Zylinderchen Maschinen scheint es ja zu klappen,
> die sollen mir dass mal für eine Palettieranlage mit Sortenvorwahl, Rezepturen 4 verschiedenen Palettentypen
> vorführen, wie lange da modeliert wird.



Es geht ja nicht mal um die Komplexität, es ist doch in Prinzip ein verbogenes Graph.
Vier Schritte wo nur einfach ein Aktor von A nach B fährt, bekomme ich doch genauso
schnell hin mit Graph und auch genauso Fehlerfrei.
Wo ist der Vorteil, ich kann ihn einfach nicht finden?


----------



## DeltaMikeAir (27 August 2020)

selmotino schrieb:


> Beispiel: 16 Zylinder = 32 Input --> SW sieht 2 hoch 32 = mehr als 4 Milliarden Möglichkeiten --< Frage welche Bitmuster ist richtig oder falsch?



RN,
du hast bei 16 Zylindern mit Abfrage mehr als 4 Mrd Möglichkeiten. Das kann ein "normaler" SPS-Programmierer nicht mehr umsetzen.

Verstehst du dass denn nicht


----------



## DeltaMikeAir (27 August 2020)

rostiger Nagel schrieb:


> ....Wenn jetzt daraus eine HMI entstanden wäre, könnte es Intressant
> werden. Allerdings war zeigt sich das nicht.



Bedienkonzept ist fix, was auch immer das bedeutet. Bei uns ist jede Bedienoberfläche anders, je nach Kunde und Sonderwünsche...



selmotino schrieb:


> ja, das war für mich der Anstoß. Ich möchte nicht kopieren sonder von NUll den Code generieren.
> 
> Die Struktur ist damit immer gleich und die Variablen immer einheitlich benannt - Bedienkonzept ist fix.
> 
> Lieferant? Du selbst nutzt das Tool. Modell erstellen - klick und IEC code erhalten


----------



## rostiger Nagel (27 August 2020)

DeltaMikeAir schrieb:


> RN,
> du hast bei 16 Zylindern mit Abfrage mehr als 4 Mrd Möglichkeiten. Das kann ein "normaler" SPS-Programmierer nicht mehr umsetzen.
> 
> Verstehst du dass denn nicht



das sind auch ganz schön viele, ich muss aber in der Tabelle immer noch
Eintragen, bei welchen Schritt der Aktor aktiv ist. In Graph machen wir PLC-
Programmierer mit einer Direkten zuweisung. 
Siemens hat sich darum gekümmert, das der Aktor auch nur im zugewiesenen
Schritt aktiv ist (hoffe ich mal). 
Wenn ich mich darauf verlassen kann, das Graph Funktioniert, wozu muss ich
dann noch diese Tabelle ausfüllen?
Diese Tabelle kann auch mal schnell unübersichtlich werden, wenn es mehr
als 100 Schritte und mehr als 50 Aktoren sind .... Oder?

Was ist eigentlich wenn ich beim ausfüllen der Tabelle einen Fehler mache, wer
überwacht das?


----------



## Blockmove (27 August 2020)

Ich hab mir das Video nun auch angesehen und sehe das gar nicht so abwertend.
Die Ideen dahinter passen zum Großteil schon. Letztlich arbeiten wir so ähnlich, nur eben ohne Oberfläche und direkt in TIA.
Die permanente Überwachung ist natürlich in der Praxis Quatsch.
Hier ist unser Konzept deutlich besser.

Ich bin aber wirklich mal auf das Patent gespannt. Ich sehe bislang nichts, was patentwürdig wäre oder nicht durch Prior Art zu Fall gebracht werden könnte.
Die permantente Überwachung kann es definitv nicht sein. Die Zuordnung eines - sagen wir mal - "Sensor-Aktor-Pool" zu einer Schrittkette kenne ich schon lange.
Weiterschalten und Überwachen mit Doppelworten anstellte der Verknüpfung von Einzelbits inklusive.
Aber aus Startup-Sicht macht sich natürlich ein Patent  schon gut bei Investoren.
Ob der ganze Aufwand für das Patent sinnvoll war / ist, naja ...
Ich persönlich lehne Patente im SPS-Umfeld ab und sollte der erzeugte SPS-Quell-Code in irgendeiner Form vom Patent betroffen sein, dann ist es definitiv ein Grund die Software nicht zu nutzen.

Gruß
Blockmoe


----------



## Ralle (27 August 2020)

Doch noch eine Frage von mir: Läuft der Modeler (wie in der Demoe) übers Web und kauft man den Zugang oder bekommt man ein Standallone-Programm?


----------



## Hohlkörper (27 August 2020)

Könnte auch eine Kombination aus beidem sein. Die Anwendung läuft auf einem Webserver im lokalem Netzwerk und der Zugriff erfolgt per Browser.


----------



## wollvieh (27 August 2020)

Einfache,  saubere Y/S Diagnose für jedes Zylinderchen, Opcon oder Nexeed Automation, und gut ist. ;-)
Keep it stupid an simple.
KISS Regel.


----------



## Blockmove (27 August 2020)

wollvieh schrieb:


> Einfache,  saubere Y/S Diagnose für jedes Zylinderchen


Und selbst damit stolperst du in der Praxis immer wieder über Fälle in denen es zu Fehlalarmen kommt.
Du kannst als SPSler noch so schöne Abläufe modellieren ... Es gibt immer einen Mechaniker der dir dich austrickst


----------



## wollvieh (27 August 2020)

Net, wann mer's richtig macht. Saubere Diagnose, Bediener schulen, findigen Mechanikern, (falls es die geben sollte) ;-) auf die Finger klopfen. Die Maschinen sollen ja laufen,  und nur dann ne Störung rauswerfen, wenn's wirklich angebracht ist. Immer möglichst nach KOR Regel Programmieren. (Keep On Running). ;-)


----------



## Mrtain (27 August 2020)

Blockmove schrieb:


> Und selbst damit stolperst du in der Praxis immer wieder über Fälle in denen es zu Fehlalarmen kommt.
> Du kannst als SPSler noch so schöne Abläufe modellieren ... Es gibt immer einen Mechaniker der dir dich austrickst



Dagegen ist wohl keine Schrittkette gefeilt


----------



## Ralle (27 August 2020)

@Wollvieh
Ich kenn zwar senie ganzen netten Anglizismen nicht ;-)  , aber deren Inhalt sollte für jeden halbwegs vernünftig denkenden SPS-Programmierer doch normales Tagwerk sein.


----------



## selmotino (27 August 2020)

rostiger Nagel schrieb:


> Nein habe ich noch nicht, ich habe aber auch noch nicht behauptet das
> ich ein Patent habe, was ich eigentlich erst beantragt habe.
> Es ging nicht um das Patent an sich, sondern um deine Aussage, die
> einfach nicht richtig war.
> ...



Ich möchte mich nochmals versuchen auszudrücken. Eingereicht - vom Prüfer bestätigt - und in Veröffentlichung 
Ämter brauchen dann Zeit und bis 18 Monate muss das Patent veröffentlicht sein. Eingereicht und bestätigt = Schutz und somit geschützt. Haben nicht wir erfunden - vielleicht die Schweiz.

Patent hin oder her - wir sind Programmierer und möchten ein einfaches Tool anbieten. Copy und Paste oder mit unserem Tool die Schrittketten einfach modellieren und generieren.
Wir machen es so und jeder ist eingeladen es zu probieren. Wenn es Blödsinn ist - dann einfach nicht nutzen.

Besten Dank aber für die Interesse.


----------



## selmotino (27 August 2020)

Mrtain schrieb:


> Dagegen ist wohl keine Schrittkette gefeilt


Vielleicht unsere Methode? Probieren und dann Prognosen abgeben. Das gesamte System muss zu jedem Zeitpunkt stimmen und wenn nicht dann melden! Stoppen oder zumindest warnen, oder?


----------



## Blockmove (27 August 2020)

selmotino schrieb:


> Das gesamte System muss zu jedem Zeitpunkt stimmen und wenn nicht dann melden! Stoppen oder zumindest warnen, oder?



Die Aussage "das *gesamte System* muss zu *jedem Zeitpunkt* stimmen" ist bei vielen unserer Maschinen nicht zutreffend.
Ich habe oft den Fall, dass während bestimmter Bearbeitungsprozesse Zylinder ihre Endlage verlassen können (und auch dürfen), obwohl die Ventile angesteuert sind.
Nahezu die selbe Diskussion hatte ich schon vor ca. 2 Jahren mit unseren KI- und Dataanalytics-"Experten". Hier gab es nämlich genau die selbe Idee zur Gesamtüberwachung. Wir sollten das gesamte Prozessabbild plus Achspositionen und -Ströme der Anlage im 100ms-Raster in die Cloud schieben und durch KI werden Abweichungen erkannt und gemeldet. Ich denke diese hochttrabenden I4.0 Vorstellungen werden einige von uns kennengelernt haben und bei den wenigsten werden sie das "Proof of Cencept"-Stadium verlassen haben, oder hat jemand so was im produktiven Einsatz?

Gruß
Blockmove


----------



## Mrtain (28 August 2020)

Ich habe die Funktionsweise dieser Überwachung noch nicht ganz verstanden. Gibt es dazu ein Schlagwort, nach dem ich googeln kann?


----------



## Draco Malfoy (30 August 2020)

selmotino schrieb:


> ProDiag schein ein Tool zu sein


Jemand, der nicht einmal weiß, wie geläufige Programiermmittel auf Steuerungen funktionieren, wie die heißen und was sie tun, erzählt mir von einem voll-innovativen Konzept zur automatischen Codegenerierung. 

No comment, Alter.


----------



## Draco Malfoy (30 August 2020)

> Ich habe so ein wenig das Gefühl das du dem gemeinen PLC Programmierer wenig zu traust.


Das macht er an dieser Stelle ausnahmsweise mal richtig. Die gemeinen SPS-Programmierer sind häufig durch ihr Umfeld und vorgeschriebene Arbeitsweisen zu unternehmensinternen Prügelknaben und Programmiernegern degradiert. In dieser Position noch klaren Verstand und eigene, sachlich begründete Meinung, auf Dauer zu behalten, erfordert eine hohe charakterliche Stärke und bemerkenswerten Durchhaltewillen.


----------



## Blockmove (31 August 2020)

Draco Malfoy schrieb:


> Das macht er an dieser Stelle ausnahmsweise mal richtig. Die gemeinen SPS-Programmierer sind häufig durch ihr Umfeld und vorgeschriebene Arbeitsweisen zu unternehmensinternen Prügelknaben und Programmiernegern degradiert. In dieser Position noch klaren Verstand und eigene, sachlich begründete Meinung, auf Dauer zu behalten, erfordert eine hohe charakterliche Stärke und bemerkenswerten Durchhaltewillen.



Auch wenn viele Betonköpfe in der Branche sind, so sind sie doch letztlich die Kunden


----------



## Mrtain (31 August 2020)

Draco Malfoy schrieb:


> Das macht er an dieser Stelle ausnahmsweise mal richtig. Die gemeinen SPS-Programmierer sind häufig durch ihr Umfeld und vorgeschriebene Arbeitsweisen zu unternehmensinternen Prügelknaben und Programmiernegern degradiert. In dieser Position noch klaren Verstand und eigene, sachlich begründete Meinung, auf Dauer zu behalten, erfordert eine hohe charakterliche Stärke und bemerkenswerten Durchhaltewillen.


----------



## ducati (1 September 2020)

Naja, es ist halt Arbeit und keine Selbstverwirklichung ☺
Man könnte ja auch ne eigene Firma gründen, wo dann bestimmt alles viel besser ist ☺
Jedenfalls, wenn Du den ganzen Tag gegen Windmühlen kämpfst, hast nach 10 Jahren auch einen an der Klatsche ☺
Soviel zum Wort zum Dienstag ☺


----------



## Draco Malfoy (1 September 2020)

ducati schrieb:


> Naja, es ist halt Arbeit und keine Selbstverwirklichung ☺
> Man könnte ja auch ne eigene Firma gründen, wo dann bestimmt alles viel besser ist ☺
> Jedenfalls, wenn Du den ganzen Tag gegen Windmühlen kämpfst, hast nach 10 Jahren auch einen an der Klatsche ☺
> Soviel zum Wort zum Dienstag ☺



Du verkennst die Realitäten, wenn Du alles gleich schwarz malst. Arbeit muss nicht "Stupides Befolgen von idiotischen Vorschriften" bedeuten, Programmierer ist nicht gleich Programmierer, Firma nicht gleich Firma. Eigene Firma gründen liegt nicht jedem, sich eine vernünftige Ecke zu suchen, ist auch eine Möglichkeit. Wenn Leute allerdings sich selbst als "kleines Rädchen im Getriebe" sehen, klein, unbedeutend und nichts wert - und mit dieser Überzeugung im Kopf leben - dann werden sie wahrscheinlich ihr Leben lang auch so arbeiten.


----------



## Heinileini (6 September 2020)

Draco Malfoy schrieb:


> ducati schrieb:
> 
> 
> > Naja, es ist halt Arbeit und keine Selbstverwirklichung ?
> ...


Komischerweise gebe ich euch beiden Recht, ducati und Draco.

@Draco Malfoy
Ich sage es mal ganz krass und unverblümt. Oft klingst Du in Deinen Beiträgen recht überheblich und despektierlich. Für mein Verständnis ist dieses Forum nicht der crème de la crème der SPS-Branche vorbehalten und es muss auch nicht jeder Experte auf allen unmittelbar oder nur mittelbar benachbarten Gebieten gleichermassen bewandert sein, um sich hier mal mit seiner ganz persönlichen Meinung oder Frage melden zu dürfen, ohne dafür a Watschen zu kassieren. Nicht nur der Ton macht die Musik, auch ein bisschen Takt gehört dazu! 

Gruss, Heinileini


----------



## Blockmove (6 September 2020)

Heinileini schrieb:


> Komischerweise gebe ich euch beiden Recht, ducati und Draco.



So sehe ich es auch. Es liegt einfach ganz viel an der Firma, Abteilung und Arbeitsklima.
In einem guten Umfeld kann mann sich durchaus verwirklichen.



Heinileini schrieb:


> Nicht nur der Ton macht die Musik, auch ein bisschen Takt gehört dazu!


Das macht das Leben leichter ohne Zweifel ... 
Aber jeder hat auch ein Recht auf Ecken und Kanten.
Ich zitiere hier mal meinen früheren Landesfürsten Franz Josef Strauß: "Everybody's Darling is everbody's Depp" 

Das Ansehen von "normalen" SPS-Programmieren ist in den letzten Jahren - meiner Meinung nach - sowieso stark gesunken.
Sieht man z.B. an Einstiegsgehältern und Stundensätzen. 
Ich hab mich bei Siemens mal heftig über die Newsbeiträge mit der Überschrift "Automatisieren in 10min" und die TIA-Werbung mit fiktiven Produktionssteierungen beschwert.
Manager glauben so einen Sch...

Gruß
Blockmove


----------



## zako (6 September 2020)

Blockmove schrieb:


> Ich zitiere hier mal meinen früheren Landesfürsten Franz Josef Strauß: "Everybody's Darling is everbody's Depp"


Okay dann versuche ich mal Thomas Müller sinngemäß zu zitieren:
"Wir haben die Champions League auch deshalb gewonnen, weil jeder darauf brennt den Fehler des Mitspielers zu korrigieren"


----------



## Blockmove (7 September 2020)

zako schrieb:


> Okay dann versuche ich mal Thomas Müller sinngemäß zu zitieren:
> "Wir haben die Champions League auch deshalb gewonnen, weil jeder darauf brennt den Fehler des Mitspielers zu korrigieren"



Guter Konter


----------

