Grundsätzlich stimmt das auch. Das Programm an sich sollte durch Struktur und Variablennamen und Netzwerktitel und Bausteinnamen etc. selbsterklärend sein. Trotzdem sollte man abundzu zumindest bei Sonderlocken im Kommentar vermerken, warum man hier dies oder jenes tut...
Ja, genau!
Solchen Quatsch hier kann man aber lassen:
Code:
U Pu1.Stoe // Pumpe 1 Störung
O Pu2.Stoe // Oder Pumpe 2 Störung
...
Wohl dem, der die Möglichkeit hat, darauf zu verzichten. Jetzt sind wir wieder beim Thema Nostalgie.
Code:
// Statt ...
U E 21.3
O E 32.3
// ... lieber ...
U E 21.3 // Pumpe 1 Störung
O E 32.3 // Pumpe 2 Störung
// ... im Programm-Ausdruck stehen zu haben ...
... das war für uns zur S5-Zeit
DER Durchbruch.
Das hat unsere AWL-Programme so lesbar gemacht, dass wir freiwillig und gerne
- (aus PlatzGrüden) auf ZeilenKommentare,
- KOP und FUP verzichtet und
- und ein BASIC-Programm geschaffen haben, das die DruckAusgaben des PGs automatisch ergänzt hat
- und umfangreiche ZuordnungsListen gepflegt haben.
Zu viele Kommentare haben die Eigenart, bei Änderungen der Logik während IBN oder später nicht mitgeändert zu werden.
Ja, leider. Der ZeitDruck, unter dem meistens gearbeitet werden muss, sorgt automatisch dafür, dass so manches Wünschenswertes bis Unverzichtbares (u.a. die Kommentare) vernachlässigt wird bzw. unterbleibt.
...
Fehler werden zurrest immer am Programm gesucht, weil
es für die anderen am wenigsten greifbar und augenscheinlich
wenig Arbeit bereitet.
Nicht unbedingt. Wenn der Programmierer einen leisen Verdacht hat, dass es am Programm liegen könnte, dann ja.
Ich kenne es so, dass man sich auf der Suche nach der FehlerUrsache auf das PG stürzt, um sie durch Beobachten der "Innereien" der PLC einzukreisen und auch durch Einbau von "Fallen" in die Software gezielt besser beobachten zu können.
Dann wirst du es als Programmierer auf der Baustelle immer versuchen irgendwie
hin zu Fummeln, schmierst in deinen noch so schönen Programm rum, weil es
ohne Flex und Schweißgerät geht.
Wenn man die Ursache des Problems eingekreist, isoliert und verstanden hat, dann wird man als Programmierer versuchen, das Problem wenigstens provisorisch durch eine ProgrammÄnderung in den Griff zu bekommen. Selbst dann, wenn man die "ideale" ProblemLösung ganz wo anders (z.B. in der Mechanik, Hydraulik oder sonstwo) sieht.
Man ist dann ja sofort einen Schritt weiter und kann die Inbetriebnahme fortsetzen, während sich andere um ihren Anteil der ProblemLösung kümmern.
Am Ende ist es wieder ein Kunstwerk.
Künstler sind immer Merkwürdig
Ja, ja, ist das Kunst oder kann das weg?