Also wer behauptet, dass es keine Objektorientierung in der SPS-Programmierung gibt, der hat entweder die letzten Jahre verschlafen oder ist ignorant. In der IEC sind objektorientierte Erweiterungen definiert, sowohl Klassen (hier dann eben in Form des FB), Methoden, Interfaces, Vererbung, etc.
Fakt ist aber, dass diese Erweiterungen in
CoDeSys 3.x drin sind, somit auch in IndraWorks und TwinCAT 3, nicht aber in der S7 (und wohl auch in absehbarer Zeit nicht kommen werden). Damit ist der (noch) größte Anteil automatisierungstechnischer Anlagen faktisch lediglich nicht objektorientiert programmierbar. Gehen tut das aber sehr wohl, so man denn will.
Jetzt kommt meine These, untermauert durch die Aussagen vieler SPS-Programmierer, die ich kenne: Kenne mer nit, bruche mer nit, mache mer nit. Die meisten von denen kommen (ich übrigens auch) aus der Elektrotechnik und haben mit Softwareengineering nix am Hut, somit sind vielen (bei weitem nicht allen) die Methoden der Objektorientierten Softwareentwicklung nicht geläufig, also werden die auch nicht eingesetzt.
Dennoch sehe ich darin die Zukunft, weil sich schlicht riesige Vorteile ergeben. Aber auch das muss letztlich jemand bezahlen.
Das gleiche gilt übrigens (generell) für Dokumentation: Keiner macht sie gerne, keiner kalkuliert die Zeit dafür ein und spätestens bei der IBN wird die Aktualisierung etwaiger Doku wieder geschludert. Auch hier gibt es viel Optimierungspotential.
Ich weiß, ich schreibe das alles etwas provokativ...aber ich würde mir etwas mehr Wagemut und Pioniergeist bei vielen Kollegen wirklich wünschen.
