# Willkommen in der TIA-Hoelle



## Techpriester (8 September 2020)

Hallo, liebe Forengemeinde.

Ich habe vor einigen Monaten eine neue Stelle angetreten und stehe quasi vor einem unloesbar scheinenden Problem. Es geht hierbei viel weniger um Code als um Struktur.

Folgendes ist mein Problem:
In unserer Firma werden grosse Anlagen programmiert. Die Programme gelten in unserem Industriezweig als "cutting edge",
Die Programme sind fuer einen Normalsterblichen allerdings nicht zu verstehen:

-Kaum bis gar keine Dokumentation,
-hunderte Netzwerke mit einem Labyrinth aus Merkern, absoluten und relativen Adressen und "Testmerker" an jeder Ecke.
-jede Maschine verarbeitet sehr viel unnoetigen Code, egal ob physische Komponenten vorhanden sind, oder nicht. 
(z.B. eine Andruckrolle, die es nicht in jeder Anlage gibt, wird im Programm dennoch bearbeitet, auch wenn es keinen physisch schaltbaren Ausgang dazu gibt)
-aufeinandertreffen komplett unterschiedlicher Programmierstile und immer wieder neuschreiben von Anlagenteilen, weil einem Programmierer der Code eines anderen nicht passt oder diesen nicht versteht. (Funktionierender SCL Baustein wird geloescht weil Programmierer2 SCL fuer unverständlich hält und wird durch AWL ersetzt)
-Flickenteppicharbeit in der an verschiedenen Stellen unterschiedliche, parallel programmierte Staende angelegt werden, die miteinander konkurrieren.

Die Liste ist schier endlos. 

Meine Frage ist daher, wie werden diese Probleme anderorts gehandhabt? Ich bin zwar an der SPS ausgebildet, aber meine Tätigkeit dient vielmehr der Optimierung von Prozessen.
Es gibt doch sicherlich einige Ansätze, wie man innerhalb einer Abteilung die Mitarbeiter auf einen gemeinsamen Nenner bringt, sodass die fabrizierten Programme sowohl verständlich als auch wartbar bleiben und nicht bei "X funktioniert nicht" sofort ganze FBs und DBs geloescht und neu geschrieben werden muessen.


----------



## DeltaMikeAir (8 September 2020)

> Die Programme sind fuer einen Normalsterblichen allerdings nicht zu verstehen:
> 
> -Kaum bis gar keine Dokumentation,
> -hunderte Netzwerke mit einem Labyrinth aus Merkern, absoluten und relativen Adressen und "Testmerker" an jeder Ecke.
> ...



Tja, so ging es mir bei meinem ersten Job auch. Sei froh, da lernt man dann erst mal Programme zu lesen und zu verstehen.
Danach kann man es ja einfach selber besser machen, dokumentieren, strukturieren usw.

Zum Titel "TIA Hölle", da kann TIA aber nichts dafür. Solche Problemchen hat man auch mit Step5, Step7, CoDeSys oder was auch immer


----------



## Techpriester (8 September 2020)

> Zum Titel "TIA Hölle", da kann TIA aber nichts dafür. Solche Problemchen  hat man auch mit Step5, Step7, CoDeSys oder was auch immer


Ich weiß, das habe ich nur geschrieben weil es halt TIA ist, mit dem ich mich herumschlagen muss...  Hat tatsächlich nix mit TIA also Programm an sich zu tun.

Zum Rest: An und für sich hast du evtl. recht. Aber wenn du dann einen Informatikexperten, der den Mist studiert hat an die Hand bekommst, der dir was erklären sollen und der dann nur sagt: 
"Viel Glück. Das KANNST du nicht verstehen. Ich verstehe es selbst nicht."
Dann ist das ganze eine sehr entmutigende Erfahrung und denke, es muss sich grundlegend was ändern in der Firma. Nicht zuletzt weil die betreffenden Personen die das Chaos fabrizieren bald alle hintereinander in Rente gehen und dann können wir die Programmierabteilung dicht machen, wenn keiner mehr durch den Code durchsteigt...


----------



## DeltaMikeAir (8 September 2020)

> "Viel Glück. Das KANNST du nicht verstehen. Ich verstehe es selbst nicht."


Das ist eine Frage der Einstellung und der Selbstsicherheit. Dann beweise ihm halt das Gegenteil.



> es muss sich grundlegend was ändern in der Firma.


Das denken viele, vor allem wenn sie neu irgendwo anfangen. Das wird halt schwer.



> Nicht zuletzt weil die betreffenden Personen die das Chaos fabrizieren bald alle hintereinander in Rente gehen


Na ist doch super, das ist doch deine Gelegenheit es in die Hand zu nehmen und besser zu machen.



> und dann können wir die Programmierabteilung dicht machen


Meine Erfahrung der letzten Jahrzehnte:
Es gab immer wieder mal die Situation, dass einer der TOP-Programmierer gekündigt hat und dann alle gedacht haben,
danach ist es vorbei, es wird nichts mehr klappen. Aber es ging immer weiter und es hat auch immer geklappt. Leute
haben sich dann damit einfach intensiver beschäftigt und waren dann irgendwann selber die gefragten TOP-Programmierer..



> wenn keiner mehr durch den Code durchsteigt


Dann muss man sich damit länger beschäftigen, überlegen, Kommentare reinschreiben usw. usw...


----------



## Blockmove (8 September 2020)

Techpriester schrieb:


> Informatikexperten



Hier liegt das Problem ... Zeigt sich regelmässig hier im Forum 
Duck und Weg


----------



## DeltaMikeAir (8 September 2020)

Blockmove schrieb:


> Hier liegt das Problem ... Zeigt sich regelmässig hier im Forum
> Duck und Weg



Ja, ich warte auch schon auf die Kommentare ganz bestimmter Personen. Vor allem weil die Wörter Merker, AWL und indirekte Adressierung gefallen sind.

Ok, auch duck und weg


----------



## Techpriester (8 September 2020)

Haha. Danke für die Antworten.

Ich spreche nicht von einem forenexperten, sondern von jemandem, der tatsächlich 1A SCL Programme schreibt. Die Seniorprogrammierer löschen das aber sofort wieder raus, weil sie nur AWL und KOP können. XD

An sich stimmt es wohl: Einfach kann jeder. Später werden wir wohl oder übel die ganzen Programme neu schreiben müssen...


----------



## PN/DP (8 September 2020)

Techpriester schrieb:


> Ich spreche nicht von einem forenexperten, sondern von jemandem, der tatsächlich 1A SCL Programme schreibt. Die Seniorprogrammierer löschen das aber sofort wieder raus, weil sie nur AWL und KOP können. XD


... oder weil im Problemfall beim Kunde/Fernwartung Programme in SCL völlig ungeeignet zur schnellen Fehlersuche sind? 

Harald


----------



## Techpriester (8 September 2020)

PN/DP schrieb:


> ... oder weil im Problemfall beim Kunde/Fernwartung Programme in SCL völlig ungeeignet zur schnellen Fehlersuche sind?



Naja, evtl. Aber selbst wenn es das wäre, dann müssten sich die Parteien miteinander absprechen anstatt sich gegenseitig die Netzwerke zu löschen. Wenn dann mir die selben Leute erzählen das sie nie SPS Programmieren o.ä. gelernt haben sondern es nur "learning by doing" machen, habe ich zwar schon Respekt davor, dass man damit 30 Jahre im Business überleben kann, es sagt aber auch viel aus wenn die gleichen Personen noch nichtmal gewisse Grundfunktionen der SPS und der Software kennen. Genau so sehen dann aber auch hinterher die Programme aus. XD


----------



## rostiger Nagel (8 September 2020)

Techpriester schrieb:


> -aufeinandertreffen komplett unterschiedlicher Programmierstile und immer wieder neuschreiben von Anlagenteilen, weil einem Programmierer der Code eines anderen nicht passt oder diesen nicht versteht. (Funktionierender SCL Baustein wird geloescht weil Programmierer2 SCL fuer unverstÃ¤ndlich hÃ¤lt und wird durch AWL ersetzt)
> -Flickenteppicharbeit in der an verschiedenen Stellen unterschiedliche, parallel programmierte Staende angelegt werden, die miteinander konkurrieren.



Du bist der nächste der einen Neuen Stil reinbringt, aber anscheinend doch
keine Lösung parat hat, so das der Senior Programmierer „*HURRA*“ schreit.


----------



## JesperMP (8 September 2020)

Techpriester schrieb:


> -jede Maschine verarbeitet sehr viel unnoetigen Code, egal ob physische Komponenten vorhanden sind, oder nicht.


Das ist eine bekannte Dilemma.
Entweder Sonderprogramme erstellen, genau angepasst an die aktuelle Maschine.
Oder ein Standardprogramm erstellen, der Optionen hantieren kann. Komplizierter, aber den Vorteil ist dass man diesen Standardprogramm über die Dauer entwickeln und Warten kann.
Wie versuchen den letztere Weg zu gehen.



Techpriester schrieb:


> -aufeinandertreffen komplett unterschiedlicher Programmierstile und immer wieder neuschreiben von Anlagenteilen, weil einem Programmierer der Code eines anderen nicht passt oder diesen nicht versteht. (Funktionierender SCL Baustein wird geloescht weil Programmierer2 SCL fuer unverstÃ¤ndlich hÃ¤lt und wird durch AWL ersetzt)


 https://xkcd.com/927/


----------



## Mrtain (8 September 2020)

Eigentlich ist das ein Thema für deinen Vorgesetzten....


----------



## DeltaMikeAir (8 September 2020)

Mrtain schrieb:


> Eigentlich ist das ein Thema für deinen Vorgesetzten....



Im Prinzip ja, ein heißes Eisen. Er hat gerade erst angefangen dort.
Und wer weiß wie es wirklich ist. Ist doch überall so. Mechaniker schimpfen
über Elektriker und anders herum, beide meckern dann gemeinschaftlich gegen 
den Konstrukteur usw. usw.
Aber eigentlich macht jeder seinen Job, es wird halt gerne gemeckert.
Da jetzt beim Geschäftsführer ein Fass aufmachen? Da hat man ganz schnell alle gegen sich, inkl. GF


----------



## Mrtain (8 September 2020)

Ich dachte auch mehr an seinen Abteilungsleiter


----------



## ms_gp (8 September 2020)

Der hat das Ganze doch bestimmt mit verbrochen.


----------



## gerribaldi (8 September 2020)

JesperMP schrieb:


> Das ist eine bekannte Dilemma.
> Oder ein Standardprogramm erstellen, der Optionen hantieren kann. Komplizierter, aber den Vorteil ist dass man diesen Standardprogramm über die Dauer entwickeln und Warten kann.
> Wie versuchen den letztere Weg zu gehen.



In meiner alten Firma haben wir das nur so gelöst. Das hat sehr gut funktioniert. Allerdings muss man auch dazu sagen, dass wir u.a. einen Art zentralen "Server" hatten, den jede SPS beim Booten kontaktiert hat. Dort hat sie dann Ihre Konfig abgeholt bzw. die passenden Bits wurden an- oder ausgeschaltet.
Auch wurde hier Konsequent jede Funktion in einen FB gelegt, welcher von einer Person gepflegt wurde. Hat man diesen FB benötigt, wurde er einfach in das Programm importiert und verwendet. 

Aber das bedeutet halt auch, dass man ein paar Grundlegende Programmierregeln aufstellt, die Verbindlich für alle gelten. Und ja, dass funktioniert nur nach vorne oder wenn man eine Steuerungsgeneration wechselt.....


----------



## DeltaMikeAir (8 September 2020)

Mrtain schrieb:


> Ich dachte auch mehr an seinen Abteilungsleiter



Das ist dann der IT Mann


----------



## Fluffi (8 September 2020)

gerribaldi schrieb:


> Allerdings muss man auch dazu sagen, dass wir u.a. einen Art zentralen "Server" hatten, den jede SPS beim Booten kontaktiert hat. Dort hat sie dann Ihre Konfig abgeholt bzw. die passenden Bits wurden an- oder ausgeschaltet.


Das finde ich interessant. Könntest du das technisch genauer erläutern?


----------



## Draco Malfoy (8 September 2020)

PN/DP schrieb:


> ... oder weil im Problemfall beim Kunde/Fernwartung Programme in SCL völlig ungeeignet zur schnellen Fehlersuche sind?
> 
> Harald



Wenn diese Bausteine sachgemäß angelegt und verwendet werden, dann hat doch Kunde / Fernwartung im Normalfall eh nichts dran verloren.


----------



## Blockmove (8 September 2020)

Draco Malfoy schrieb:


> Wenn diese Bausteine sachgemäß angelegt und verwendet werden, dann hat doch Kunde / Fernwartung im Normalfall eh nichts dran verloren.



Naja, das ist in der Theorie so.
Aber ich hab gelernt, dass der Normalfall der Sonderfall ist 
Spaß beiseite. Setzt man SCL sinnvoll ein, steigt die Qualität deutlich im Vergleich zu AWL.
Aber unsere Erfahrung zeigt auch, dass bei Verwendung von SCL für simple logische Verknüpfungen mehr Fehler auftreten als bei KOP/FUP. Ich denke viele kennen die if-then-elsif-else-endif-Orgien. Wir diskutieren, ob wie wir unsere Liefervorgaben sinnvoll anpassen können.

Gruß
Blockmove


----------



## Mrtain (9 September 2020)

deltamikeair schrieb:


> das ist dann der it mann



 ..............


----------



## Mrtain (9 September 2020)

ms_gp schrieb:


> Der hat das Ganze doch bestimmt mit verbrochen.



Wahrscheinlich schon....


----------



## Mrtain (9 September 2020)

Blockmove schrieb:


> Ich denke viele kennen die if-then-elsif-else-endif-Orgien.



Ja, kenn ich. Deswegen versuche ich, die Dinge kurz zu halten. 
Aber zig und / oder Verknüpfungen in einem Netzwerk machen es meiner Erfahrung auch nicht überschaubarer.


----------



## de vliegende hollander (9 September 2020)

Hört sich an nach ein versautes Standart Programm wo alles drin ist und jeder schon jahrenlang reingekotzt hat.

Sind euer Anlagen da so groß das ein neu schreiben mehr Zeit kost?


----------



## Draco Malfoy (9 September 2020)

de vliegende hollander schrieb:


> Hört sich an nach ein versautes Standart Programm wo alles drin ist und jeder schon jahrenlang reingekotzt hat.
> 
> Sind euer Anlagen da so groß das ein neu schreiben mehr Zeit kost?



Erst mal müssen ja die „erfahrenen Herren“ in Rente gehen, sonst sorgen die schon dafür, daß der Kollege dort nicht mehr arbeitet. Wie groß ist eure E-Konstruktion Abteilung ?


----------



## gerribaldi (9 September 2020)

Fluffi schrieb:


> Das finde ich interessant. Könntest du das technisch genauer erläutern?



Ich probiere es mal zu erklären. Es gab zwei Varianten dieser Funktion. Bei beiden Varianten sind folgende Bedingungen immer gleich:
Wir hatten in unsere Maschinen mehrere SPSen verbaut. Diese haben alle mit einer zentralen SPSen kommuniziert, welche für die u.a. Achsensteuerung zuständig war. Zusätzlich habe alle SPSen auch noch mit einem normalen PC [PC-1] kommuniziert, auf dem noch ein Stück Software lief, wo u.a. die ganze Kommunikation verwaltet hat. Zusätzlich lief auf diesem PC auch ein weiteres Stück Software, welche Einstellungen und Parameter wo der Benutzer an der Visualisierung eingegeben hat, hinterlegt wurden. Fehlermeldesystem inkl. der historischen Datenbank lief auf einem weiteren PC. 


V1: Kommunikation via Arcnet. Hier wurde auf dem PC-1 ein Textfile hinterlegt, in dem man mit Hilfe von Dezimalwerten angeben konnte, ob bzw. welche Funktion vorhanden ist. In dem Textfile konnte man in zu Beginn anhand eines Headers festlegen, für welches Steuerung das File gedacht war. Die Software auf PC-1 hat diese Textfiles bei jedem Neustart neu eingelesen. Dieses Textfile musste für jede SPS vorhanden sein.
Werte wo der Benutzer aus an der Visu eingegeben hat, wurden direkt in die SPS geschickt und auch an PC-1 -> auf diesem auch gesichert. Nach einem Neustart der SPS hat die bei PC-1 nachgefragt und alle notwendigen Einstellungen/Parameter wieder geholt.

V2: Kommunikation via Ethernet und UDP. Hier war es im Prinzip genauso, nur dass die Datei anders aufgebaut war. Hier wurde nicht mehr mit Dezimalwerten gearbeitet, sondern mit Variablennamen. Das war dann soweit durchstrukturiert, dass man mit einer zentralen Konfig-Datei die Funktion und Konfiguration von zig verschiedenen SPSen steuern und beeinflussen konnte. Hier wurden die Dateien zur Laufzeit eingelesen bzw. wenn der IBN-Mensch vor Ort dies angestoßen hat.
Hier wurde dann auch alle innerhalb der SPS konsequent mit FBs realisiert, die dann so oft aufgerufen wurden, wie eine Funktion vorhanden war. Dies war bei V1 noch nicht ganz so ausgeprägt
Werte wo der Benutzer aus an der Visu eingegeben hat, wurden auch hier direkt in die SPS geschickt und auch an PC-1 -> auf diesem auch gesichert. Nach einem Neustart der SPS hat die bei PC-1 nachgefragt und alle notwendigen Einstellungen/Parameter wieder geholt. Wurde die SPS einen anderen Rechner zugeordnet, konnte man so auch die Werte von dort holen, Bsp PC-2.

Von Prinzip kannst du dir das wirklich wie ein File- oder DB-Server vorstellen, der die Werte zur VErfügung gestellt hat und auf dem man auch Werte ablegen konnte.

Noch ein Hinweis zum Abschluss
Codeform der SPS war immer ST (vereinzelt FUP), es war KEINE Siemens Steuerung im Einsatz! Bei Neuanlagen hatten wir seit ca. 1998 kein AWL mehr im Einsatz, was jetzt schon über 20 Jahre sind. Von daher habe ich teilweise kein Verständnis dafür, dass sich noch immer so viele Leute an diesem grauenhaften AWL festhalten.... :???::roll::???::roll:


----------



## de vliegende hollander (10 September 2020)

Draco Malfoy schrieb:


> Wie groß ist eure E-Konstruktion Abteilung ?



3 E-Planer,
und 10 programmieren inbetriebsetzer.


----------



## Draco Malfoy (10 September 2020)

de vliegende hollander schrieb:


> 3 E-Planer,
> und 10 programmieren inbetriebsetzer.


Ich meinte eher denjenigen, der sich hier über die veralteten Programmierweisen beschwert hat.


----------



## Techpriester (11 September 2020)

MoinMoin.

Danke, für die Antworten.

Als allererstes: Ich bringe (zumindest derzeit) keinen neuen Stil mit  rein. Ich bin Technologe und QS-Mann der sich ein wenig mit SPS  auskennt. Mein mein Job ist es, die Maschinen zu kennen, nicht sie zu  programmieren. Ich versuche auch nicht die Geschäfts- oder  Abteilungsleitung zu nerven. Die Abteilungsleitung ist E-Konstrukteur  und findet gut, wie es derzeit läuft. Ich agiere nicht als "verärgerter  Nachwuchsprogrammierer" sondern im Auftrag einer neuen Geschäftsleitung,  die, anders als die alte, genau weiß, dass in der Programmierung das  Chaos herrscht.



> Hört sich an nach ein versautes Standart Programm wo alles drin ist und jeder schon jahrenlang reingekotzt hat.
> Sind euer Anlagen da so groß das ein neu schreiben mehr Zeit kost?


Den Nagel auf den Kopf getroffen. Jahrelang wird das selbe Programm  benutzt und beliebig erweitert und gestutzt. Problematisch ist hierbei,  dass es sich um große Anlagen mit 10+ einzelmaschinen handelt mit  jeweils gefühlt 100 Varianten, die alle im Programm eingepflegt sind und  wenn sie nicht gebraucht werden, via Testmerker o.ä. totgelegt werden.  Besonders schlimm sind dann so Situationen, in denen eine Fräsanlage  nach einer Nachrüstung rumspinnt, weil die Eingänge bereits anderweitig  abgearbeitet werden.

Beispiel: Service will eine Lichtschranke nachrüsten. Der "freie  Eingang" der gewählt wird, arbeitet aber bereits eine inexistente  Schutzeinrichtung ab. Hierdurch kommt es später zu "unerklärlichen  Maschinenstillständen". Die Maschine hält einfach ohne Störmeldung an,  weil sie denkt, jemand hat manuell Einlass ins Schutzgitter angefordert.  Der Fehler tritt aber nur sporadisch auf, da die LS oftmals wieder frei  wird, BEVOR die Anlage endgültig herunterfährt. Danach fährt ein  weiteres Serviceteam von Norddeutschland fast nach Slowenien runter,  weil keiner einen Plan hat, was los ist. Kurz drauf musste dann auch die  Technologieabteilung mit, weil die zweite Produktionslinie sich später  gleich mit verabschiedet hatte. Es ist leider kein Spaß, wenn in der  Großindustrie deine nicht abgenommene Anlage plötzlich spastische  Anfälle entwickelt und Service und Fernwartung im Dunkeln tappen... 



> Ich meinte eher denjenigen, der sich hier über die veralteten Programmierweisen beschwert hat.


Wir haben in der E-Kontruktion 3,5 Mitarbeiter und 3+(2x0,5) SPS  Programmierer (3,5 und 4 weil ein E Planer zum Teil auch als  SPS-Aushilfe arbeitet und ein weiterer SPS Mann eigentlich ein  zweckentfremdeter Serviceprogrammierer ist. Sie sind heillos überfordert  da sie sowohl Neuanlagen und Fernwartung machen. Wir haben auch  Einrichter mit SPS Ausrüstung, die können aber höchstens mal einen  Eingang ändern. Eine Zeile AWL und sie schmeißen den Laptop weg.  

MfG


----------



## Mrtain (11 September 2020)

Techpriester schrieb:


> Den Nagel auf den Kopf getroffen. Jahrelang wird das selbe Programm  benutzt und beliebig erweitert und gestutzt. Problematisch ist hierbei,  dass es sich um große Anlagen mit 10+ einzelmaschinen handelt mit  jeweils gefühlt 100 ...



Kenn ich nur zu gut... Und dann diskutiert mit dem Vertrieb, was Standard ist und was nicht...

Aber grundsätzlich sollten Komponenten, die nicht vorhandenen sind, nicht im Programm sein. Oder zumindest deaktiviert.

Nur der Interesse halber, in welcher Branche seid ihr tätig?


----------



## rostiger Nagel (11 September 2020)

Mann könnte das Pferd auch einmal andersherum aufzäumen.
Ist die E-Konstruktion wirklich so unfähig oder will nicht?
Oder liegt es an der Geschäftsführung die nicht weiß was Sie will
oder wie Ziele aussehen was Entwickelt werden soll.
Wenn die E-Konstruktion schon seit gestern so überlastet ist liegt
das nicht an ihnen selber!


----------



## ms_gp (11 September 2020)

Positiv ist, dass die Geschäftsleitung das Problem offensichtlich erkannt hat.

Wie die Software so geworden ist, kann ich nur vermuten. Ich gehe mal davon aus, dass die Programmierer irgendwann keine Lust mehr hatten bei jedem Projekt wieder Dinge in die Software einzubauen, die dann beim nächsten mal wieder raus müssen, dann wieder rein, dann wieder raus, dann wieder anders, dann wieder rein....da ist es einfacher alles drinzulassen und dann Projektabhängig zu aktivieren. Wenn man das richtig macht, dann kann das bestimmt funktionieren und ist weniger Arbeit. Ab einer bestimmten Komplexität, kann man es anders gar nicht mehr handhaben.
Ich habe das vor vielen Jahren auch begonnen in einem Teil unserer Software zu machen. Ich habe damit nur gute Erfahrungen gemacht. Aber es erfordert viel Disziplin. Man muss sehr aufpassen, wenn man etwas ändert. Quick&Dirty fürs aktuelle Projekt ist das nicht mehr.

Die Frage ist natürlich auch, wieso immer so viele Varianten vom gleichen existieren. Das kann ja wieder verschiedene Ursachen haben. Ich habe oft den Eindruck, dass außerhalb der Softwareabteilungen niemanden klar ist, wie komplex die Auswirkungen kleinster Änderungen sein können. Da meint es jemand gut und erzeugt damit Chaos.

Darf ich fragen auf welcher Plattform das ganze läuft?


----------



## Blockmove (12 September 2020)

Ich bring hier mal noch einen weiteren Spieler auf's Feld:
Der Kunde mit seiner Instandhaltung.

Wir als Kunde fordern das SPS-Programm ohne Bausteinschutz oder ähnliches.
Kommt die Instandhaltung nicht mit dem SPS-Programm zurecht, dann kann das durchaus Folgen haben.
Aufgrund von negativen Erfahrungen wurden und werden die Liefervorschriften (und ich denke nicht nur bei uns) immer weiter verschärft.
Mittlerweile musste der erste Lieferant seine Software komplett neu schreiben.
Ein anderer Lieferant hatte aufgrund seiner Software so ein mieserables Scoring, dass er jahrelang keine Anlage mehr an uns verkauft hat.
Erst nachdem er seine Standardsoftware überarbeitet hat, kam er wieder zum Zug.

Fazit:
Die Ausführung von Hard- und Software ist auch ein Verkaufsargument ... Zumindest für Folgeanlagen.

Gruß
Blockmove


----------



## Draco Malfoy (13 September 2020)

Blockmove schrieb:


> Ich bring hier mal noch einen weiteren Spieler auf's Feld:
> Der Kunde mit seiner Instandhaltung.
> 
> Wir als Kunde fordern das SPS-Programm ohne Bausteinschutz oder ähnliches.
> ...



Mmm... die Wünsche sind hehr, es ist alles schön & gut

Aber es gibt da so n Paar Nuancen:

- 1) Wenn ich als Lieferant geschützte Bibliotheken in SCL habe, die für eure Instandhaltung nicht relevant sind, warum muss ich diese für euch öffnen ? Es ist unser geistiges Eigentum.
- 2) Wenn eure Instandhalter nicht mit SCL in diesen Bibliotheken zurechtkommen - ist es mein Problem oder deren Problem ? Im anderen Fällen und bei anderen Kunden müssen die da auch nicht dran.
- 3) Man sollte schon noch in der Lage sein, auch andere als gewohnte Software zu akzeptieren, wenn sie denn vernünftig strukturiert, sachgemäß, einheitlich, sinnvoll, stringend und auf hohem Niveau ausgeführt ist. Für Hersteller von Anlagen ist es ein Super-Gau, wenn eurer Speziallfall eine komplett kundenspezifische Software erfordert. Hersteller haben ja Hunderte von zum Teil ähnlichen oder baugleichen Anlagen. Da lässt sich kein Geschäft machen, wenn man für jeden Kunden die Software neu schreiben muss. Das könnte dann der Kunde vielleicht selber machen, oder diesen Mehraufwand entsprechend bezahlen.

Nichtdestotrotz sind mir die Schwierigkeiten für einen Anlagenbetreiber durchaus bewusst. Dann kommt halt irgendeine Firma XY aus WasWeißIch, und stellt ihm eine Anlage, wo noch auf dem Niveau von 1980 in absoluten Adressen, indizierten Zeigern und Merkern programmiert wird. Das muss man auch irgendwie noch unterbinden können.


----------



## Heinileini (13 September 2020)

Draco Malfoy schrieb:


> - 1) Wenn ich als Lieferant geschützte Bibliotheken in SCL habe, die für eure Instandhaltung nicht relevant sind, warum muss ich diese für euch öffnen ? Es ist unser geistiges Eigentum.


Es wird mir wohl ewig ein Rätsel bleiben, wo die Grenze zwischen "für die Instandhaltung relevant" und "für die Instandhaltung irrelevant" verläuft. Besser gesagt: warum die Ansichten hierüber manchmal so eklatant auseinanderklaffen - z.B. zwischen Lieferanten und Kunden.
Mal ganz abgesehen von der Diskussion um "geistiges Eigentum", welcher Lieferant möchte tolerieren, wenn ein Instandhalter auf seiner verzweifelten Suche nach der Ursache eines Problems sich in "BlackBox"-Bereiche verrennt und dort anfängt, an Symptomen herumzudoktern, statt die Ursache einzukreisen und sich ggfs an den Lieferanten zu wenden?


----------



## Draco Malfoy (13 September 2020)

Heinileini schrieb:


> Es wird mir wohl ewig ein Rätsel bleiben, wo die Grenze zwischen "für die Instandhaltung relevant" und "für die Instandhaltung irrelevant" verläuft. Besser gesagt: warum die Ansichten hierüber manchmal so eklatant auseinanderklaffen - z.B. zwischen Lieferanten und Kunden.
> Mal ganz abgesehen von der Diskussion um "geistiges Eigentum", welcher Lieferant möchte tolerieren, wenn ein Instandhalter auf seiner verzweifelten Suche nach der Ursache eines Problems sich in "BlackBox"-Bereiche verrennt und dort anfängt, an Symptomen herumzudoktern, statt die Ursache einzukreisen und sich ggfs an den Lieferanten zu wenden?



Weil es eine klare Abgrenzung zwischen den Verantwortungsbereichen verschiedener Servceebenen gibt. Im Normalfall sollte es so eine Abrenzung geben. Der Service des Kunden sollte Zugang haben zu:

- Schrittkettenprogrammierung;
- Stellungsüberwachung von Pneumatik, Endlagen, Schutztüren, Zuhaltungen;
- Rückmeldungen von Sicherungen, Schützen, elektronischen Selektivitätsmodulen;
- Ansteuerung von Peripherie, Magnetventilen, Zylindern etc.
- Sicherheitsprogrammierung.

Der Service des Kunden hat kein eigentlich sinvolles Anrecht darauf, solche Sachen wie Kommunikationstreiber, Standardbausteine zum Einlesen/Schreiben von AI / AQ, Treiberbausteine für die Kommunikation mit anderen busfähigen Geräten, Diagnosebasuteine für die Feldperipherie, Treiberbausteine für die Antriebstechnik, Materialtracking, Datenhandling, IO-Link Datenanbindung usw. auseinanerpflücken zu können. Diese Bausteine sollten aus einer zentralen Library kommen und bereits umgänglich getestet sein und einfach funktionieren. Ggf. mit einer Beschreibung dazu.

S. auch, wie das zum Beispiel im VW Standard (VASS) gelöst ist. Dort hats zwar auch Quellen zu den FBs, dort geht aber vom Service in der Regel niemand dran, und das dürfen sie auch nicht so ohne Weiteres.


----------



## Blockmove (13 September 2020)

Draco Malfoy schrieb:


> Mmm... die Wünsche sind hehr, es ist alles schön & gut
> 
> Aber es gibt da so n Paar Nuancen:
> 
> ...



Wir verbieten keine Form von moderner Programmierung, ganz im Gegenteil.
Es gibt aber Vorgaben, wie:

Schrittketten in Graph
Bausteine mit überwiegend logischen Verküpfungen (Betriebsarten, Verriegelung, ...) in KOP / FUP
Gliederung der Programms entsprechend der Anlagenstruktur
...


Das Thema Know How Protect führt natürlich zu Diskussionen und natürlich gibt es auch berechtigte Interessen auf Lieferantenseite. Aber bislang gab es immer eine Lösung.

Es zeigt sich eigentlich bei dem Thema Programmierung das selbe Bild wie hier im Forum:
Es sind oft die "alten" Programmierer, die wesentlich aufgeschlossener und innovativer sind, als die Jungen.
Ist letztlich auch klar. Jemand der von der Hochsprachenprogrammierung kommt, tut sich mit Graph, KOP und FUP einfach schwerer.

Die Programme im S5-Stil haben in den etzten Jahren deutlich abgenommen.

Gruß
Blockmove


----------



## Heinileini (13 September 2020)

Blockmove schrieb:


> Jemand der von der Hochsprachenprogrammierung kommt, tut sich mit Graph, KOP und FUP einfach schwerer.


... und auch mit SCL/ST, sobald es um BitVerknüpfungen ("BOOL") geht. Die BitVerknüpfungen scheinen mir der gemeinsame Nenner des SchwerTuns zu sein. Das fällt natürlich besonders bei KOP, FUP und Graph auf, die sich für BitVerknüpfungen eher anbieten als SCL/ST.


----------



## Blockmove (13 September 2020)

Heinileini schrieb:


> ... und auch mit SCL/ST, sobald es um BitVerknüpfungen ("BOOL") geht. Die BitVerknüpfungen scheinen mir der gemeinsame Nenner des SchwerTuns zu sein. Das fällt natürlich besonders bei KOP, FUP und Graph auf, die sich für BitVerknüpfungen eher anbieten als SCL/ST.



Natürlich kann man mit SCL genauso Bits verküpfen.
Aber bei der Fehlersuche ist's halt nervig.
Die SCL-Statusdarstellung bei TIA (und auch Codesys) ist nicht sonderlich gut.

Gruß
Blockmove


----------



## gerribaldi (13 September 2020)

Blockmove schrieb:


> Die SCL-Statusdarstellung bei TIA (und auch Codesys) ist nicht sonderlich gut.



Also bei CodeSys 2.x war es bescheiden, aber ab 3.x ist die Darstellung doch eigentlich ziemlich gut. Von daher finde ich das nicht problematisch....


----------



## Ralle (14 September 2020)

gerribaldi schrieb:


> Also bei CodeSys 2.x war es bescheiden, aber ab 3.x ist die Darstellung doch eigentlich ziemlich gut. Von daher finde ich das nicht problematisch....



Meinst du Twincat oder wirklich rein Codesys?


----------



## Techpriester (14 September 2020)

Die Instandhaltung des Kunden ist bei uns irrelevant. Die Software darf nicht eingesehen werden, da auf Baustellen etc. auch viele Konkurrenten mit uns Seite an Seite arbeiten und diese sich theoretisch auch den Programmstand ziehen bzw. der Kunde diesen weitergeben könnte. Eine Schrittkette o.ä. gibt es ohnehin nicht. Nur waren alle Programmstände bisher immer ungesichert aufrufbar, da der Programmierer nicht wusste, wie man den Zugriff einschränkt. (Außer Passwortschutz bei safety)

Hauptproblem wird sein, dass es keine richtigen Vorgaben gibt. Der Programmierer hat alle Freiheiten der Welt wie der die Maschine steuert und solange die Anlage läuft, wurden unter der alten Geschäftsleitung auch keine Fragen gestellt.

Programmiert wird über TIA und TwinCAT. TwinCAT wird aber von anderen Leuten verwaltet und läuft relativ reibungslos.


Am Rande: Es gibt Kunden, die Zugriff auf die Safetybausteine bekommen? Riskant, immerhin kann so das Sicherheitskonzept ausgehebelt werden. Hinterher wirds zurückgesetzt und deine Firma bekommt den schwarzen Peter...


----------



## JesperMP (14 September 2020)

Techpriester schrieb:


> Am Rande: Es gibt Kunden, die Zugriff auf die Safetybausteine bekommen? Riskant, immerhin kann so das Sicherheitskonzept ausgehebelt werden. Hinterher wirds zurückgesetzt und deine Firma bekommt den schwarzen Peter...


Die Checksumme von Safety-Programm muss beim Maschinen-Übergabe notiert und in Übergabe-Protokoll eingetragen werden. Dann sieht man ob spähter das Sicherheitsprogramm geändert wurde.
Abgesehen davon, ob der Kunde das Quell-Program haben soll, darüber habe ich eine Meinung, aber denke es pass nicht zum Thema "Wilkommen in der TIA-Hölle".


----------



## Draco Malfoy (14 September 2020)

Techpriester schrieb:


> Am Rande: Es gibt Kunden, die Zugriff auf die Safetybausteine bekommen? Riskant, immerhin kann so das Sicherheitskonzept ausgehebelt werden. Hinterher wirds zurückgesetzt und deine Firma bekommt den schwarzen Peter...



Nein, natürlich nicht zum freien Rumändern. Durch das Saferty-Passwort können Änderungen unterbunden werden. Aber ein lesender Zugriff sollte schon noch möglich sein. Safety-Programmierung enthält in der Regel kein besonderes Know-How und muss für alle Seiten transparent sein.


----------



## Captain Future (14 September 2020)

Bei uns ist die Frage was bekommt der Kunde und wann bekommt er es nicht ganz klar geregelt.

Sondermaschinenbau -> bekommt er alles
Serien -> bekommt er nichts

Das ist aber schon vor der Bestellung geklärt.


----------



## gerribaldi (14 September 2020)

kein Twincat, sondern direkt Codesys oder IndraWorks von Bosch-Rexroth


----------



## Schievel (28 September 2020)

Draco Malfoy schrieb:


> Mmm... die Wünsche sind hehr, es ist alles schön & gut
> 
> Aber es gibt da so n Paar Nuancen:
> 
> ...





Immer wieder toll, wenn man Kunden hat, die einem genau vorschreiben wie Variablen, Bausteine etc.pp. benannt werden sollen. Und jeder Kunde will was anderes.
Das geht irgendwie nicht mit der Bausteinbibliothek zusammen, es sei denn man will für jeden Kunden eine eigene Bibliothek schreiben... also besser Bausteinschutz drauf und hoffen dass er es nicht merkt 

Dem Threadstarter möchte ich vorschlagen die Programmierer zu Maintainern von jeweils eigenen Bausteinen/ Maschinenteilen zu ernennen. Dann ist der Programmierer für seinen Teil der Software verantwortlich, und niemand sonst pfuscht in seinen Bausteinen rum, löscht Code weils nicht gefällt etc. 
Wenn da jeder erstmal sein Baby hat, dass er umsorgt, steigt da schon die Qualität. Hoffe ich.


----------



## Teebow (29 September 2020)

Mal mein Erfahrungsbericht seit 1 Jahr als Siemens SPS Techniker in unserer Halle: 

Sondermaschine wurde bestellt und es gab ein Meeting wo der Programmierer mich fragt welche Sprache ich möchte.
Habe mit SCL/ST geantwortet weil ich darin mich verbessern möchte und den Rest  gut beherrsche.

Patzige Antwort mit "kann ich nicht, ich nehme AWL" habe ich nicht erwartet ^^


Am Ende wurde es ein Mix aus allen Sprachen die Siemens zu bieten hat ^^


----------



## Mrtain (29 September 2020)

Teebow schrieb:


> Mal mein Erfahrungsbericht seit 1 Jahr als Siemens SPS Techniker in unserer Halle:
> 
> Sondermaschine wurde bestellt und es gab ein Meeting wo der Programmierer mich fragt welche Sprache ich möchte.
> Habe mit SCL/ST geantwortet weil ich darin mich verbessern möchte und den Rest  gut beherrsche.
> ...



Multilingual ist doch modern


----------



## Captain Future (30 September 2020)

Teebow schrieb:


> Habe mit SCL/ST geantwortet weil ich darin mich verbessern möchte und den Rest  gut beherrsche.



haha..... ich bestelle auch immer was ich selber nicht kann. 
Jeder sollte halt seine eigene Maschine zum Üben haben.


----------



## Teebow (1 Oktober 2020)

Captain Future schrieb:


> haha..... ich bestelle auch immer was ich selber nicht kann.
> Jeder sollte halt seine eigene Maschine zum Üben haben.



Ich lerne an meinen eigenen Anlagen so ist es nicht. Aber es ist interessant zu sehen was andere Programmierer so für Strategien haben und wie deren Programme aufgebaut sind.


----------



## Heinileini (1 Oktober 2020)

Teebow schrieb:


> Ich lerne an meinen eigenen Anlagen so ist es nicht.


So ist es nicht? Also ist es doch so!?
Das Lernen an eigenen Anlagen bzw. Fehlern kann man doch nicht einfach so abschalten. Sollte man auch nicht, denn das durch eigene Fehler Gelernte bleibt viel "nachhaltiger" im Gedächtnis haften.


----------



## Teebow (1 Oktober 2020)

Heinileini schrieb:


> So ist es nicht? Also ist es doch so!?
> Das Lernen an eigenen Anlagen bzw. Fehlern kann man doch nicht einfach so abschalten. Sollte man auch nicht, denn das durch eigene Fehler Gelernte bleibt viel "nachhaltiger" im Gedächtnis haften.



Ich glaube du hast nicht verstanden was ich sagen wollte, oder ich hab es falsch formuliert ^^


----------



## Onkel Dagobert (2 Oktober 2020)

Techpriester schrieb:


> .. Beispiel: Service will eine Lichtschranke nachrüsten. Der "freie Eingang" der gewählt wird, arbeitet aber bereits eine inexistente Schutzeinrichtung ab. Hierdurch kommt es später zu "unerklärlichen Maschinenstillständen". ..


Mal abgesehen davon, dass ich dir mit deiner bisherigen Problemschilderung völlig recht gebe, sind hier von verschiedenen Personen schwere Fehler gemacht worden.



Der "freie Eingang" hätte in der Symboltabelle mit Adresse und Kommentar für seinem Verwendungszweck erkennbar sein müssen.
Der Service hätte vor der Verwendung des "freie Eingangs" dessen Querverweise checken müssen.

Es gibt hier also eine Verkettung mehrerer Fehler. So etwas führt im Allgemeinen sehr oft zu Unfällen! Das ist vergleichbar mit einer ungesicherten Baugrube. Der eine sichert nicht ab, der andere klotzt nicht und fällt rein.


----------



## Tommi (2 Oktober 2020)

Blockmove schrieb:


> Naja, das ist in der Theorie so.
> Aber ich hab gelernt, dass der Normalfall der Sonderfall ist
> Spaß beiseite. Setzt man SCL sinnvoll ein, steigt die Qualität deutlich im Vergleich zu AWL.
> Aber unsere Erfahrung zeigt auch, dass bei Verwendung von SCL für simple logische Verknüpfungen mehr Fehler auftreten als bei KOP/FUP. Ich denke viele kennen die if-then-elsif-else-endif-Orgien. Wir diskutieren, ob wie wir unsere Liefervorgaben sinnvoll anpassen können.
> ...


Späte Antwort, aber *ACK*


----------

