@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.
Code:
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.