"Saubere" Programme

Ralf1969

Level-1
Beiträge
6
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Nachdem ich längere Zeit selbst programmiert habe wechselte ich vor einiger Zeit zu einem Unternehmen, dass die gesamte Elektrotechnik und Steuerungsprogrammierung fremdvergibt (mir wurde seinerzeit beim Wechsel mal was versprochen, das leider nicht eingehalten wurde). Nunja, was mir da an Programmen insbesonder hinsichtlich Strukturiertheit / mieser Symbolik etc. entgegenschlägt zieht einem die Schuhe aus. Es böte sich hier ja zunächst an aus 'Softwarerichtlinien' eine art Werksvorschrift für uns zusammenzustellen, ich denke aber daß dies nicht so sehr doll ist, da ich aus eigener Erfahrung heraus weiß daß Softwarerichtlinien Programmierer zu recht großen Verrenkungen bringen, eine eigene Softwarerichtlinie in etwas moderaterer Form zu erstellen ist recht hoher Aufwand.

Gibt es irgendwo allgemeinverbindliche Richtlinien für 'saubere Programmierung'?
 
Ich glaube nicht, dass es zu dem Thema eine Spielregel gibt.
Es bleibt also bei dir zu entscheiden, ob und wo es hin gehen soll.

Das von dir hier angestossene Thema wird auf jeden Fall wieder viele kontroverse Meinungen ans Tageslicht bringen.

Ich würde an deiner Stelle gewisse Programmier-Spielregeln vorgeben. Wie weit das geht bleibt dir dabei überlassen. In meinem Betrieb wäre ich da sehr rigoros. Das liegt aber vielleicht auch daran, das ich schon eine Menge Mist gesehen habe und nicht jeder, der sich Profi nennt ist auch letzlich einer. Ich habe bisher feststellen müssen, dass die Werke der meissten externen Programmierer nicht im entferntesten so schön lesbar sind wie das, was du hier im Forum als Vorschläge auf Probleme erhälst.

Fazit: siehe oben ...

Gruß
LL
 
Nun, um 'Am genialsten' geht es mir eher weniger. Es geht mir im wesentlichen natürlich um einige "No-Go" Dinge (wie zum Beispiel das Adressieren von Ein und Ausgängen mitten innerhalb von FCs (die dann möglichst, wenn es mehrfach genutzte Funktionen innerhalb einer Anlage sind mit kopiert und auf andere EA Adressen umgeschrieben wurden) Um ein Schludern bei der Symbolik und ähnlichem. Viele programme sehen mir übel nach altem s5 Code aus obwohl sie neu erstellt wurden, das muß m.E. nun wirklich nicht sein (man kann natürlich da auch unterschiedlicher Meinung sein, jedoch ist das weitgehende Ignorieren von modernen Strukturen UDTs / Instanzierbarkeit von Bausteinen und auch das Ausufernde Benutzen von Merkern schlechte Stil, m.E. auch das nicht-Nutzen IEC Timern).
 
Meiner Meinung nach ist die Hauptursache von "unsauberen Programmen" die Tatsache das der Programmierer sobald die Anlage läuft keine Zeit (Geld) mehr bekommt das Programm "aufzuräumen".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Meiner Meinung nach ist die Hauptursache von "unsauberen Programmen" die Tatsache das der Programmierer sobald die Anlage läuft keine Zeit (Geld) mehr bekommt das Programm "aufzuräumen".

Hmmm ... das mag durchaus sein, allerdings wenn die Struktur von vornherein nicht da ist bestehen nur geringe chancen, durch 'aufräumen' Struktur hereinzubringen.
 
Nun, um 'Am genialsten' geht es mir eher weniger. Es geht mir im wesentlichen natürlich um einige "No-Go" Dinge (wie zum Beispiel das Adressieren von Ein und Ausgängen mitten innerhalb von FCs (die dann möglichst, wenn es mehrfach genutzte Funktionen innerhalb einer Anlage sind mit kopiert und auf andere EA Adressen umgeschrieben wurden) Um ein Schludern bei der Symbolik und ähnlichem. Viele programme sehen mir übel nach altem s5 Code aus obwohl sie neu erstellt wurden, das muß m.E. nun wirklich nicht sein (man kann natürlich da auch unterschiedlicher Meinung sein, jedoch ist das weitgehende Ignorieren von modernen Strukturen UDTs / Instanzierbarkeit von Bausteinen und auch das Ausufernde Benutzen von Merkern schlechte Stil, m.E. auch das nicht-Nutzen IEC Timern).

Ich kann dich schon verstehen, aber natürlich ist gerade das Thema NOGO auch extrem kontrovers, was der eine als modern und super empfindet ist für den anderen absolut abartiger Programmierstil. Insofern bleibt dir nur übrig, deine Wünsche zu formulieren, das von den Verantwortlichen zu einer Richtlinie absegnen zu lassen und diese dann mit in die Verträge einzubringen. Bei der Abnahme wird dann auch der Programmiercode mit abgenommen. Dabei muß man dann sicher immer mal Kompromisse eingehen, aber eine Grundlage ist vorhanden. Ich geb zu, ich mag das nicht besonders als Programmierer, weil meine Angebote und Zeitabschätzungen natürlich auf meinen Programmierstil beruhen und es mitunter viel Zeit kostet, den manchmal wirklich kruden Wünschen von Verantwortlichen nachzukommen, die meinen, den Stein der Weisen zu besitzen. Ich fang auch gar nicht erst an, meine Meinung zu Gut und Schlecht beim Programmieren komplett kund zu tun, UDT, nutze ich auch, aber ich verfluche sie auch oft genug und nicht nur ich :ROFLMAO: !

PS: Und denk auch mal daran, modern ist nicht immer gleich bedeutend mit gut. Ich hab schon Graph7 -Programme eleminieren dürfen, die zwar wirklich bewundernswert modern waren, inkl. UDT, umkopieren von und in Instanz-DB usw. aber so buggy und unwartbar, daß der Betreiber der Anlagen aus Sicherheitsgründen viel Geld in die Hand genommen hat, um neue Programme schreiben zu lassen. Die sind aus deiner Sicht vielleicht konservativ, laufen aber bestens uns wurden vom Wartungspersonal gerne angenommen, weil wenig zu warten :ROFLMAO: und auch recht gut zu überblicken. (denke ich dich mal ;) ) Das beste Programm ist immer noch das, wo kein Instandhalter jemals reinschauen muß. Ich weiß das ist fast unmöglich zu leisten, aber so ein Programm ist auch selten in wirklich schlechtem Programmierstil erstellt!!!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Programme

Hi,
bezüglich GRAPH: wo ich mich frage, wenn es um Prozesse/Sequenzen geht, die mittels Schrittketten gut auflösbar sind, was kann da besser und übersichtlicher sein als GRAPH SKs? Gibt es nicht.
Wenn ich das Programm aufmache, und mein Prozess in Form einer SK sehe, wie so alles abläuft, und welche Aggregate/Aktoren in dem entspr. Schritt aktiv sind, und das noch online verfolgen kann... Das ist das Beste für mich.
Voraussetzung: man kann GRAPH programmieren und/oder lesen.

Vladi
 
Hi,
bezüglich GRAPH: wo ich mich frage, wenn es um Prozesse/Sequenzen geht, die mittels Schrittketten gut auflösbar sind, was kann da besser und übersichtlicher sein als GRAPH SKs? Gibt es nicht.
Wenn ich das Programm aufmache, und mein Prozess in Form einer SK sehe, wie so alles abläuft, und welche Aggregate/Aktoren in dem entspr. Schritt aktiv sind, und das noch online verfolgen kann... Das ist das Beste für mich.
Voraussetzung: man kann GRAPH programmieren und/oder lesen.

Vladi

Du hast natürlich Recht, aber nicht alles ist so gut auflösbar (Servo der erst verfährt und dann in Momentenregelung geht und eine bestimmte Zeit lang mit 30t zu drücken. Das lief nicht wirklich gut, besonders, bei irregulären Abbrüchen (Stop, Reset, Not-Aus, Stop an ganz bestimmten Stellen etc.). Zudem war auf Grund der fortschrittlichen Programmierung vieles einfach nicht nachzuvollziehen (Mal wurde hier was in den Instanz-DB eines anderen FB kopiert, mal dort) Es war Einfacher, alles neu zu machen, der Kunde hatte natürlich die Nase voll von Graph. Ausßerdem hatten die das Garph-Paket zuerst nicht mal auf ihrem PG und die Instandhalter konnten damit nicht umgehen, kein Wunder, die hatten das vorher noch nie gesehen. Selbst wenn, aus o.g.G. war das Programm nicht wartbar.

PS. Entschuldige Ralf, wollte deinen Thread nicht okkupieren!
 
Gibt es irgendwo allgemeinverbindliche Richtlinien für 'saubere Programmierung'?

Verbindliche Richtlinien kenne ich auch nicht. Ich bin zwar selber ein Proggi, aber wenn wir mal eine Anlage Fremdvergeben, dann halte ich schon in der Pflichtenheftphase für den Auftragnehmer einige Programmier-Regeln fest, an die sich die Firma zu halten hat.
Um nur einige zu nennen:
  • Programm in deutscher Sprache
  • Netzwerke nur mit Überschrift
  • Gut kommentierte Symboltabelle
  • Keine Merkerschnittstellen (Eingänge auf Merker rangieren, dann verarbeiten, anschliessend Merker auf Ausgänge rangieren)
  • Möglichst in FUP (jaja, daran scheiden sich die Geister...)
  • keine Netzwerke mit "auskommentiertem" Code, der dann in FUP verschwindet
  • Referenzliste "Operanden ohne Symbol" muss leer sein.
  • FUP-Netzwerke nicht größer als ein Bildschirminhalt (normale Auflösung)
Damit sind wir bisher ganz gut gefahren. Ich hab zwar noch etwas meine Instandhalterbrille auf (10 Jahre Instandhaltung liegen hinter mir), aber man findet Fehler einfach schneller, wenn nach den obigen Kriterien programmiert wurde.

Gruß Approx
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und hier noch ein paar Ergänzungen:

1. Kein Zugriff auf Instanzdaten ausserhalb des Funktionsbausteins
2. Keine Sammelsurium-Datenbausteine, Trennung nach Anlagenteil, oder Trennung nach Parameter und Istwerte.
3. Die Nummernbereich würde ich nicht zwangsläufig vorschreiben, mir sie aber vom Programmierer vorlegen lassen und somit prüfen, ob eine Struktur vorhanden ist.
4. Nachweis bei Programm-Abnahme, wie Programm ohne "rote LED's" auf PLCSim laufen kann
5. Nachweis über Test's der verwendeten selbstgeschriebenen (gekapselten) Bausteine (FC/FB).
6. Nachweis, dass S7 keine Inkosistenzen mehr anmeckert.
7. Recovery-Strategie Beschreibung (Bei Defekter CPU).
 
  • Keine Merkerschnittstellen (Eingänge auf Merker rangieren, dann verarbeiten, anschliessend Merker auf Ausgänge rangieren)

warum? ... ein kurzer erfahrungsbericht und ein quasi-pro für merkerschnittstellen:

einer unserer anlagenlieferant hat seine programme nach folgender struktur aufgebaut

1. INPUT-Scan (Eingänge auf Merkerbereiche rangieren für die einzelnen Anlagengruppen)
2. MAIN-Funktionen für die einzelnen Anlagengruppen
3. STEUER und REGEL-Funktionen für die einzelnen Anlagengruppen
4. DRIVE-Funktionen für die einzelnen Anlagengruppen
5. OUTPUT-Scan (Merkerbereiche auf Ausgänge rangieren für die einzelnen Anlagengruppen)

...wobei die anlagengruppe der in der hardwareumsetzung definierten entspricht...

daraus ergibt sich für den inbetriebnehmer folgender vorteil:

- seine funktionen MAIN, STEUER, DRIVE sind in baugleichen anlagen immer gleich, IBN-service zeit verkürzt sich und man brauch auch keine schmiermerker :rolleyes:

für den instandhalter bedeutet diese gliederung:

- bei einem defekten eingang, muß keine lange querverweisliste abgearbeitet werden. einfach umverdrahten, im INPUT-Scan ändern ... fertig .. ähnlich für ausgänge (aber die sollten sowieso nur einmal beschrieben werden :rolleyes: ... aber bei S/R sinds schon mal zwei ...)
 
Zuletzt bearbeitet:
An diesem Punkt habe ich auch gestutzt, aber vielleicht soll und approx erklären was er damit genau meint.
Bezieht das vielleicht auf IN-Parameter von FC/FBs? Hier wäre es natürlich Quatsch sie auf Schmiermerker zu legen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke , das Rangieren von Merkerbereichen kommt noch aus der Zeit vor einer komplett symbolischen Programmierung, wie sie in einer IEC-Umgebung standardisiert ist.
 
Zu den Merkerschnittstellen kann ich nur sagen, dass es aus Programmierersicht einfacher ist, weil man sein Programm bequem im Büro schreiben kann und vor Ort nur noch die Schnittstelle beschalten muss. ABER: Wenn man fix einen Fehler suchen muss, dann sind mit Merkerschnittstelle immer noch ein paar Steps mehr nötig, um z.B. einen fehlenen Eingang zu lokalisieren. In meinem Fall hatte der "Gute Mann" in der betreffenden Anlage seine Merker nicht mal gut kommentiert. Ich hab dann kurzerhand das komplette Programm umverdrahtet (kurz ist gut - es hat ca. ne Woche gedauert). Aus solchen Dingen hab ich halt gelernt und mein Cheffe pflichtet mir bei. :cool:

P.S. Ist ja wie beschrieben auch nur meine Meinung zu "sauberer" Programmierung. :rolleyes:

Gruß Approx
 
In meinem Fall hatte der "Gute Mann" in der betreffenden Anlage seine Merker nicht mal gut kommentiert.

solltest aus den erfahrungen aber keine allgemein gültigen regeln aufstellen, denn wie du schon erwähntest:

  • Gut kommentierte Symboltabelle

der zwischenschritt über den fehlenden eingang ist ein berechtigter einwand, allerdings kann man das durch gute störauswertung und damit verbundener visualisierung kompensieren, so dass man den eingang und in meinem fall, ich den INPUT-scan, wirklich nur anzufassen brauche, wenn ich darin eine änderung/erweiterung vornehmen muß/möchte...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Früher hab ich das auch nicht so gesehen aber das Argument von vierlagig, dass wir in irgend einem anderen Thread schon mal durchhatten hat mich überzeugt, so dass ich meine neuen Programme auch nach diesem Stil schreibe.
für den instandhalter bedeutet diese gliederung:

- bei einem defekten eingang, muß keine lange querverweisliste abgearbeitet werden. einfach umverdrahten, im INPUT-Scan ändern ... fertig .. ähnlich für ausgänge (aber die sollten sowieso nur einmal beschrieben werden :rolleyes: ... aber bei S/R sinds schon mal zwei ...)
*ACK*
 
Wie wärs denn mit dem Vorschlag, anstatt der Merker zwei Datenbausteine zu verwenden z.B. "DB-IN", "DB-OUT"?
Hab mit PEW und PAW schon ähnliches gemacht und die Erfahrungen, was gute Vorbereitung anbetrifft, sind recht gut.
 
Für die "Merkerhasser" unter uns wäre das natürlich eine Alternative.;)
Ich persönlich halte Merker für diesen Anwendungsfall aber für "in Ordnung".
 
Zurück
Oben