Ja das habe ich mir gedacht.
Die klassische Programmierung in der SPS Welt geht halt leider immer davon aus, dass man Fehler im Code hat und der Kunde diese bitte selber beheben soll.
Wenn man immer wieder auf Programmodule (Objekte) zurückgreift, kann man nach einer gewissen Zeit davon ausgehen, dass nahezu alle Fehler behoben sind. Das ist die Idee, wo man hin will.
Den Source Code kann der Kunde von mir aus auch haben, jedoch glaube ich nicht, dass er es im Detail verstehen kann. Wenn am den Code jedoch so einfach schreiben muss, dass jeder Instandhalter es versteht, wird man nie zum OOP hinkommen.
Der ewige Kreis, den ich schon seit Jahren versuche zu durchbrechen.
Der Fachkräftemangel, wird mich hierbei jedoch unterstützen.
Grüße
Hans
Das Problem sind nicht die Fehler im Code, sondern ganz so wie auch rostiger Nagel schrieb, fehlende Verknüpfungen.
Ich hab hier aktuell eine NC-Achse bei der rund 80 - 100 Bedingungen für den Start erforderlich sind. Ein Teil davon hängt an Sensoren, ein Teil an Typdaten, ein Teil Bearbeitungsergebnissen. Einen Großteil habe ich sicher durch die Visualisierung dargestellt, einen weiteren Teil durch den PLC-Code-Viewer von ProDiag, aber ich bin mir sicher, dass der Fall eintreten wird, wo ein Instandhalter einen Blick in den Code werfen muss. Und sei es nur um festzustellen, dass der Schlosser bei der Wartung am Wochenende die Lichtschranke auf den falschen Reflektor eingestellt hat.
In so einem Fall macht instandhaltungsfreundlicher Code den Unterschied, ob ich am Montag um 5Uhr morgens schlafen kann oder ob das Telefon klingelt.
Was mich ärgert, ist die geringe Wertschätzung von Instandhaltern.
Die Kollegen müssen Fehler an Anlagen finden, an die wir als Programmierer überhaupt nicht gedacht haben.
Hätten wir daran gedacht, dann hätten wir ja eine Fehlerroutine / Fehlermeldung programmiert.
Also kann man die Frage stellen, wer den nun das bessere Verständniss für Anlagen und Prozesse hat.
Ein weiteres Thema im Umfeld von OOP sind Anpassungen und Änderungen.
Klassisches Beispiel für OOP ist ja immer Fördertechnik. Einmal einen Template für einen Riemenförderer erstellt, kann man ja sogar Codegeneratoren erstellen und aus dem 3D-CAD automatisch SPS-Programme erzeugen. Zustimmt in der Theorie.
Blöd nur wenn man während der Inbetriebnahme feststellt, dass man eine neue Variante braucht und alles an Biblotheken hängt.
Will man es ordentlich machen, dann ist ein Tag damit verbraten. Muss es schnell gehen, dann entstehen Murkslösungen, die einem beim Update der Bibliothek um die Ohren fliegen und der nächste Kollege überhaupt nicht versteht.
Mein Fazit:
OOP ist in der SPS absolut sinnvoll ... wenn man sie mit Sinn und Verstand nutzt.
) .
