Ich bin auch schon an viele fremde SPS-Programme herangekommen, sei es zur Fehlerbehebung, zur Erweiterung oder Optimierung.
Ich kann nur Blockmove aus vollem Herzen zustimmen:
Es gibt Programmierer, die haben das Talent schönen Code zu schreiben. Programm öffnen und sich wohlfühlen.
Es gibt andere, da machst du das Programm auf und fragst dich ob es überhaupt zu der Anlage gehört.
Meine Erfahrung möchte ich dabei so zusammenfassen:
Geht es um Maschinen (auch Sondermaschinen), die von Firmen gebaut werden, die solche Art Maschinen als Haupteinnahmequelle bauen, ist der Code meistens grottenschlecht. Was sich dann auch wieder nach außen auswirkt, weil das Personal dann sagt: Die Maschine lief noch nie fehlerfrei bzw. der Inbetriebnehmer hat monatelang an der Anlage gesessen und Fehler gesucht bzw. behoben.
Das geht über Bausteine, die nur in AWL ohne jeglichen Kommentar vorhanden sind über Bausteine, die per Instanzdaten verschaltet werden anstatt über In/Outs bis zu unverständlichen Spaghetticode. Oder "Handshakesignale", die nach Zeit x automatisch zurückgesetzt werden, ohne zu wissen, ob die Gegenstelle die registriert hat.
Grund sind hier eben der wiederverwendete Code (ohne daß dieser auch in Jahrzehnten mal überarbeitet, verbessert oder kommentiert wurde), sowie interne "Vorschriften", die dann aber auch nur die internen Mitarbeiter verstehen, oder aber Werkstudenten in solchen Läden: Du machst das schon, mach das mal so wie in Anlage XY, dann klappt das schon. Oder eben auch Zeitmangel, weil der Vertrieb sagt: Sowas haben wir doch schon X Mal gebaut, da kann doch die Programmierung nicht so lange dauern. Also wird der Code hingerotzt.
Ist eine Anlage individuell programmiert, weil es ein Einzelstück ist, wird der Code von Grund auf geschrieben und ist meistens auch strukturiert, kommentiert und man "fühlt sich wohl" darin.
Der Grund ist eben, daß der Programmierer sich für genau diese Anlage Gedanken macht und das Programm auch entsprechend aufbaut. Oft gibt es dann auch nicht
den Baustein, den man aus seiner eigenen Bibliothek wiederverwenden kann,
den eierlegenden Wollmilchbaustein. Dadurch wird das Programm übersichtlicher. Meistens ist hier dann auch die entsprechende Zeit im Projekt einkalkuliert und man setzt nicht "mal eben" einen Werksstudenten dran.
Klar hat jeder Programmierer seine Eigenarten. Klar sagt man bei dem ein oder Anderen: Was hat der da gemacht? Aber das ist bei jedem Handwerker so und schlußendlich gibt es viele Wege nach Rom.
Was ich aber denke, was ausschlaggebend ist, ist immer die Vorgeschichte zum Programm, wie auch
@rostiger Nagel in #43 schreibt. Da kommt vieles zusammen:
Ist eine realistische Zeit für die Programmierung (und ihrer Planung) einkalkuliert?
Werden die "richtigen" Personen mit der Erstellung beauftragt?
Ist die Mechanik korrekt geplant und ausgereift oder muß der Programmierer die Mängel der Mechanik ausgleichen?
Hat der Kunde korrekte Vorgaben gemacht oder soll die Maschine nach IBN völlig andere Anforderungen (zusätzlich) erfüllen, als bei Bestellung?
Wer pflegt das Programm? 1, 2, 3 Personen oder jede Woche jemand Anderes?
Hallo Zusammen,
Gerne würde ich mit euch das Thema Software Resilienz im Bereich SPS diskutieren!
Glaub ihr es ist ein Bereich der für SPSen Sinn ergibt? Glaub ihr es gibt generell Programmierstrategien die eine Software stabiler macht? Und glaubt ihr es ist messbar, wenn man diese anwendet?
Ich habe sehr oft den Eindruck, dass in meinem Bereich so programmiert wird: "Hauptsache die Anlage läuft und besteht die Abnahme - egal wie!"
Auch jeder programmier hat seinen eigenen Stil und hält den für den besten!?
Aber gibt es Herangehensweisen die man Newbys mitgeben kann, damit eine Software stabiler läuft? Und welche sind diese?
Freue mich auf eure Ideen!
Ich denke "Sinn" macht es, sich mit dem Thema zu beschäftigen, genauso wie "Styleguides" Sinn machen.
Am Ende muß aber lesbarer Code herauskommen, egal wie die Variablen benannt sind oder das Programm aufgebaut ist. Signale müssen nachvollzogen werden können, Signalwege müssen klar sein, Code sollte durch Einrücken und Kommentare strukturiert werden, Netzwerke Überschriften bekommen.
Ich glaube, die beste Programmierstrategie ist die, daß die Zeit für die Programmierung realistisch kalkuliert wird und der Programmierer vor Beginn seiner Arbeit einmal in sich geht und überlegt, wie er das Programm am besten aufbauen kann und nicht einfach drauf losprogrammiert und vor allem, daß die Anforderungen an die Mechanik und das Programm eindeutig formuliert sind. Denn was nützt mir das schönste Programm, wenn ich am Ende alles umstricken muß, von hinten durch die Brust ins Auge, weil die Anforderungen der Mechanik oder des Kunden sich plötzlich völlig verändern.
www.plcopen.org
und wenn der nicht wirr ist, in der Regel auch nachvollziehbar und gut beobachtbar 
