Programmierstil - Richtlinien - S7

eloboy

Well-known member
Beiträge
69
Punkte Reaktionen
1
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo,

gibt es irgendwo Richtlinien zum Programmieren von S7 ?
bzw. Vorschläge für einen "guten Programmierstil"

Oder kann jeder Programmierer machen was im gerade gefällt?

Über ein paar Meinungen würde ich mich sehr freuen.
 

sps-concept

Well-known member
Beiträge
2.235
Punkte Reaktionen
251
Programmierstil

Hallo,

prinzipiell kann jeder machen was er will. Dazu wirst du auch im Forum einige Beiträge finden. Prinzipiell finde ich folgendes wichtig:

Das Programm sollte strukturiert sein. Jeder verwendete Operand hat ein Symbol. Keine Schmiermerker in S7! Dafür gibts Lokalvariablen. Keine Weiterverknüpfung von Operanden - dafür kann man Hilfsmerker nehmen. Operanden sollten aus Gründen der Übersichtlichkeit nur an einer Stelle im Programm gesetzt/rückgesetzt/zugewiesen werden. Pointeradressierung nur benutzen wenn es Sinn macht. Jedes Netzwerk hat zumindest eine Netzwerküberschrift, erklärungsbedürftige haben zusätzlich Kommentare. Soweit es die Logik erlaubt wird in KOP/FUP programmiert. Hat schon mal jemand versucht eine Fehlersituaition die nur kurz ansteht in AWL über 3 Klammerebenen zu lokalisieren? Mir fällt sicher noch mehr ein...

MfG
André Räppel
 

plc_tippser

Well-known member
Beiträge
2.500
Punkte Reaktionen
301
Zuviel Werbung?
->Hier kostenlos registrieren
Keine Weiterverknüpfung von Operanden
Hi André,
wie meinst du das mit dem Weiterverknüpfen?

Sonst versuche ich den Aufbau des Programms noch zu strukturieren, indem ich mir mit Visio erst einmal die einzelnen Stationen und Funktionen aufmale, die Schnittstelle beschaue und die daraus entstandenen Schnittstellen nicht vom Anfang der Maschiene mit dem Ende zu verknüpfen. Also, wenn an einer Y-Achse eine Z montiert ist, kommuniziert diese nicht mit dem übergeordneten Baustein der Y-Achse sondern nur mit der Y-Achse. Halt ein serieller Aufbau.

Leuchtmelder, Hupe, LED´s sind beim mir immer FC2, Störmeldungsgenerierung immer FC3. Dadurch kann ich schnell meine Programme lesen, auch wenn sie 5 Jahre alt sind. Ich versuche meine Kollegen mit ins selbe Boot zu ziehen, was aber nur eingeschränkt funktioniert.

pt

pt
 

sps-concept

Well-known member
Beiträge
2.235
Punkte Reaktionen
251
S7

Hallo tippser,

mit Weiterverknüpfen meine ich folgendes. Bei normaler Ansicht sind in KOP 8 Verknüpfungen und eine Zuweisung möglich. Wenns mehr wird muss man scrollen. Viele Kunden wünschen dieses Limit. Manche programmieren dann so:

Netzwerk 1
========

U blabla
U blalblabla
U .....
U .....
U .....
U .....
U .....
U .....
= Ergebnis

Netzwerk 2
========

U Ergebnis
U blabla
U .....
U .....
U .....
U .....
U .....
U .....
= Ergebnis

Netzwerk 3
========

U Ergebnis
U blabla
U .....
U .....
U .....
U .....
U .....
U .....
= Ergebnis

MfG
André Räppel
 

andre

Well-known member
Beiträge
268
Punkte Reaktionen
37
plc_tippser schrieb:
Leuchtmelder, Hupe, LED´s sind beim mir immer FC2, Störmeldungsgenerierung immer FC3. Dadurch kann ich schnell meine Programme lesen, auch wenn sie 5 Jahre alt sind. Ich versuche meine Kollegen mit ins selbe Boot zu ziehen, was aber nur eingeschränkt funktioniert.

pt

pt
Hallo,
ich habe in der Instandhaltung viel mit fremden Programmen zu tun, schreibe aber auch selbst welche. Ich habe über die Zeit gelernt, das viele Wege nach Rom führen. Der Programmierer kann sein Programm gut lesen und Fehler schnell finden. ABER als Instandhalter muß man sich oft langwierig in die Gedankengänge eines Programmierers hinein versetzen. Und wie Du schreibst, das Du Deine Kollegen mit ins Boot ziehen willst, finde ich gut, hilft aber in der Regel wieder nur Euch. Es ist nun mal so, das es keine Richtlinien gibt und wohl auch nie geben wird, dazu sind die meisten Anwendungen viel zu individuell.
Ich für meinen Teil kann aus dem Programmierstil eines fremden Programmierers lernen und manche Dinge für mich anwenden. Der Chef sieht das in der Regel anders. Für ihn zählt nur effiziente Fehlersuche, schnell, schnell, schnell ...
Programmierer, die Ihre Programme nicht oder ungenügend kommentieren und auf Symboldateien verzichten, könnte ich auf den Mond schiessen! Für die müsste es eine Art Lizenzentzug geben.
Wenn ich selbst etwas programmiere, ist das wichtigste eine ordentliche Vorbereitung und immer daran denken, die Anlage könnte noch wachsen.
Gruß Andre
 
A

Anonymous

Guest
Zuviel Werbung?
->Hier kostenlos registrieren
Es ist auch hilfreich wenn man die Programme nach der IEC61131 programmieren würden. Dann wären die Programme von der Struktur und Dokumentation einigermaßen einheitlich.
 

smoe

Well-known member
Beiträge
334
Punkte Reaktionen
10
Leichter wäre gesagt was man nicht machen soll:

  • - Jeden Dreck mit einer Schrittkette lösen. Am besten eine Kette für das ganze Programm.
    - In dem Programm auf möglichst aufwendigen Weg eine "künstliche Intelligenz" einzubauen obwohls niemand braucht bzw. bezahlt.
    - Verknüpfungen möglichst bis zur Unkenntlichkeit zu kürzen um doch noch 1 ns Zykluszeit zu sparen.
    - Mit möglichst exotischen Fachbegriffen zu kommentieren um die ratlosen Instandhalter von den eigenen Fähigkeiten zu überzeugen.
    - Am Anfang jeden Bausteins einen 3 seitigen Kommentar der alles Wichtige des Programmierers enthält: Name, Anschrift, Tel-Nummer, Firmenlogo, Copyright, Produktwerbung, Lebenslauf usw..

smoe
 

gorden

Member
Beiträge
14
Punkte Reaktionen
0
Zuviel Werbung?
->Hier kostenlos registrieren
tag,

ich lerne an der berufschule (s7) über die schrittkette das programm zu schreiben und, von der schule her, hab ich ka wie man in s7 eine symbolik oder kommentar oder so schreibt, weil wir das in der schule nicht machen....

im betrieb (s5) lerne ich, das die dokumentation (zuordnungsliste oder symbolik) das a und o eines guten programms sind... und in meinem betrieb krieg ich ne aufgabe und dann heists entwickle mal was... und am ende wird alles besprochen und evt. verbessert...
 

smoe

Well-known member
Beiträge
334
Punkte Reaktionen
10
Ich pers. verzichte auf Schrittketten wo ich nur kann. Und es lässt sich fast alles auch ohne machen.

Zur Symbolik. Bei mir wird ausnahmslos jeder Operand kommentiert. Das erleichert spätere Erweiterungen erheblich. Bei Step5 hat mir das eh besser gefallen. Da waren noch Kommentare ohne Operand und eine sinngerechtere Ordnung der Liste möglich.

smoe
 

plc_tippser

Well-known member
Beiträge
2.500
Punkte Reaktionen
301
@sps-cocept
Das ist echt pervers. Wenn ich bei uns einen erwischen würde, der das macht :twisted:


Ich pers. verzichte auf Schrittketten wo ich nur kann. Und es lässt sich fast alles auch ohne machen.
Ich habe früher auch immer auf Schrittketten verzichtet. Seitdem ich die aber verstärkt einsetze, sind meine IBN-Zeiten gesunken, Änderungen lassen sich viel leichter umsetzen und Kollegen finden den Fehler viel schneller, da sie nur gucken müssen, wo die SK steht.

Kontra: Die Bausteine werden größer, aber das stört in 2004 eigentlich keinen mehr.

Gruß pt
 

Ralle

Supermoderator
Teammitglied
Beiträge
14.410
Punkte Reaktionen
3.378
Zuviel Werbung?
->Hier kostenlos registrieren
@smoe

Was hast du gegen Schrittketten ? Es kommt schon darauf an, wie man eine Schrittkette programmiert. Früher haben wir komplett ohne Schrittketten (S5) geschrieben. Die Programme konnten eigenlich viel (Maschine in Hand verfahren, Auto einfach wieder draufschalten ohne extra Verfolgung), weil sie zustandsgesteuert waren, also von der Stellung aller Maschinenteile und den Infos zum Materialfluß den weiteren Ablauf festlegten. Dann kam eine Firma mit Schrittketten. Die Programmerstellungszeit sank auf ca. 1/3. Dafür war es damals noch etwas unflexibel (S5 mit Merker-Schrittketten, stöhn). Seit Step 7 gibt es Sprungverteiler. Mit ein paar selbstgestrickten Standardbausteinen ist das ziemlich komfortabel zu händeln. Besonders für Montageautomaten ist das auf jeden Fall eine gute Lösung. Graph 7 ist auch eine Alternative, das kann noch mehr (parallele Schrittketten, Verzeigungen in Schrittketten etc.). Dafür handelt man sich leider eine schlechte Performance auf dem PG, besonders im Status ein (einschlaf-kaffeetrink).

Gruß Ralle
 

smoe

Well-known member
Beiträge
334
Punkte Reaktionen
10
Ich habe zu Zeiten der S5 gelernt und hab ich mir die Sk abgewöhnt. Aber ihr habt schon recht, es kann mit einer Sk so manches durchaus sinnvoll und gut gelöst werden. Abläufe eines Anlagenteiles der eben nur in einer Reihenfolge zu laufen hat. Schöne Diagnose ist dann auch möglich. Mit eingeschränkten Online Status muss man eben leben.

Zum ärgern finde ich nur die Machwerke so mancher Kollegen die offenbar die Sk zur "einzig wahren Methode" erklären und jede einfache Verknüpfung (zb. "Wasser leer" -> "Ventil ein") in eine umfangreiche SK packen. Der Erfolg ist dann der, wenn die Anlage mal nicht genau 100% läuft, das manchmal Anlagenteile nicht arbeiten weil die SK eben nicht im richtigen Schritt ist.

Ich sollte mir mal eine "richtige" S7 SK von euch Profis anschaun. Bin durchaus bereit zu lernen.

smoe
 

Harry

Well-known member
Beiträge
76
Punkte Reaktionen
6
Hallo!

Es gibt wohl soviele Arten zu programmieren, wie es Programmierer gibt !


Ich hatte lange mit fremden SPS-PRogrammen zu tun und darum diverse Möglichkeiten gesehen, welche mir gut gefallen haben. Andere waren schlichtweg eine Katastrophe, wo sogar der Programmierer selbst am Schluss nur noch am üben war, um das "Ding" irgendwie zum laufen zu kriegen.

Die Idee für meinen Programmierstil hab ich an einem für mich guten Beispiel abgeschaut und dann noch etwas an meine Bedürfnisse angepasst:

- alle Programme in AWL
- für alle Projekte die gleiche Programmstruktur
- sobald sequentielle Abläufe vorhanden sind -> SK (habe dazu einen speziellen Schrittkettentreiber entwickelt)
- alle Operanden symbolisch adressiert. Und zwar nach einer festen, logischen Gesetzmässigkeit und nicht nach Zufallsprinzip
- jeder Sensor wird dauernd auf Soll-Zustand überwacht. (Erkennung von Kabelbrüchen, Wackelkontakte, überbrückten oder abgehängten Sensoren)
- alle (!) fehlenden Weiterschaltbedingungen in einer Schrittkette führen zu einem Timeout und werden als Störung im Klartext ausgegeben und sind so durch den Instandhalter leicht zu lokalisieren
- Kommentare für jedes Netzwerk
- Umschreibung von "speziellen" Programmteilen, welche einfacher zu verstehen sind, wenn man die Idee des Programmierers kennt


Schlussendlich soll ja einfach folgendes erreicht werden:

- übersichtliches Programm
- erkennbare Struktur
- einfache Diagnosemöglichkeit
- möglichst viele Programmteile sind so universell, dass sie einfach in verschiedensten Projekten eingesetzt werden können.


Gruss

Harry
 

Heinz

Well-known member
Beiträge
657
Punkte Reaktionen
11
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo,
vieles hängt vom Kundenwunsch und der Aufgabe ab.

Ich arbeite nach folgender Regel:
Ablaufsteuerungen => Schrittkette
Verknüpfungssteuerungen => "Herkömlich" in Kop / Fup

Die Schrittkette hat in der Regel das Problem, nach Abbruch oder Kettenreset, Neustart der SPS! den richtigen Schritt wieder anzuspringen. Da ist die Verknüpfungssteuerung im Vorteil. Läßt sich sehr leicht eine Startbedingung erreichen dann ist die Kette im Vorteil.

Die Inbetriebnahmezeiten sind in der Regel mit Ketten geringer. Die Erfahrung habe ich auch gemacht.

Eine gut Verständliche Dokumentation ist Pflicht. Alle Bausteine Merker etc. haben in der Zuli eingetragen zu sein und IMMER den 1 Zustand zu beschreiben.

Das Programm sinnvoll strukturieren.
 
Oben