# Programmierrichtlinie



## yather (19 August 2009)

Hallo liebe Forum Mitglieder,
ich weiß das das Thema hier schon behandelt wurde. es geht um Programmierrichtlinie für S7. will nur wissen was ich vergessen habe.

1) hat einer eine gute Vorlage für Bausteinköpfe für FB und FC,s?
2) welche Signale sind für die Steuerung einer Anlage/Maschine von Bedeutung? und in welche OB,s werden sie sinnvollerweise Programmiert?
3) wie wird die Quittierroutine sinnvollerweise Programmiert?

wenn einer noch was einfällt, dann bin ich dankbar wenn er das erwähnen würde.

Mfg


----------



## PN/DP (20 August 2009)

Hallo yather,

bitte entschuldige falls ich Dir zu nahe trete, aber so, wie Du Deine 3 Fragen gestellt hast, fällt mir spontan diese Antwort ein:
Das Erstellen einer Programmierrichtlinie, die anderen Programmierern vorschreibt, wie sie 
programmieren sollen, sollte man jemandem überlassen, der selber Ahnung vom Programmieren hat.

Gut, Spaß beiseite.



> 1) hat einer eine gute Vorlage für Bausteinköpfe für FB und FC,s?


wenn Du bei "Bausteinköpfen" die Übergabeparameter-Schnittstelle meinst, da kannst Du höchstens
Benennungs-Konventionen vorschreiben, aber nicht, welche Eingänge oder Ausgänge die FB/FC haben 
sollen. Jeder FB/FC hat eine spezielle Aufgabe, und nach dieser Aufgabe richtet es sich, welche 
Parameter übergeben werden. Eine allgemeingültige Vorlage wird es nicht geben.



> 2) welche Signale sind für die Steuerung einer Anlage/Maschine von Bedeutung? und in welche OB,s werden sie sinnvollerweise Programmiert?


* Signale?
Kommt auf die Anlage/Maschine drauf an, kann man nicht generell sagen oder gar vorschreiben
Im Grunde ist jedes an der speziellen Maschine/Anlage vorhandene Signal von Bedeutung, sonst
gäbe es das Signal nicht.
* Welcher OB?
Eine Maschine/Anlage wird im allgemeinen/sinnvollerweise gar nicht in OB's programmiert.
95% des Programmcodes befindet sich in FC's oder ggf. in FB's. Die werden fast alle im OB1 oder 
als Functions in FC's oder FB's aufgerufen. 
Programmierung in Weckalarm-OB's wie OB35 sind in Industrieanwendungen meistens verboten bzw. nur für
Regler-Bausteine und einige wenige Spezialanwendungen erlaubt (kommt auf den Einsatzfall an).
Dann könnten/sollten ggf. noch ein paar Fehler-OB 8x ausprogrammiert sein. Kommt auf die verwendete
Hardware an.



> 3) wie wird die Quittierroutine sinnvollerweise Programmiert?


Das kommt auf die Anwendung drauf an, eventuell spielen da auch Sicherheitsvorschriften eine Rolle.
Gibt es vielleicht gar mehrere Quittierstellen? Oder mehrere Operator-Panels? Alles möglich.
Fehler, die nur kurz anstehen oder von allein wieder gehen können, sind zu speichern bis zur Quittierung
Darf schon vor dem Gehen quittiert werden? Das muß von Fall zu Fall entschieden werden.



> wenn einer noch was einfällt, dann bin ich dankbar wenn er das erwähnen würde.


Hast Du schon folgende Richtlinien bedacht:
* welche Programmiersprache ist Vorschrift? FUP/KOP, AWL nur wenn nicht anders geht, SCL, Graph, ...
* Ausgabewerte zu PAW generell vorher auf MW oder DBW speichern, dann erst ausgeben
* Maschinen-Einstellwerte sind nach Inbetriebnahme als Initialwerte und Aktualwerte in die Projekt-DB's zu schreiben
* Operator Panels und Visualierungen dürfen nur Werte aus extra eingerichteten Schnittstellen-DB's nutzen
(keinesfalls Zugriffe auf Merker, Eingänge oder gar Ausgänge!)
Das DBD0 jedes DB, auf den Schreibzugriffe der OP oder Visu stattfinden, ist unbenutzt zu lassen
* Dokumentationssprache ist Deutsch
* In jedem Programmbaustein (OB,FB,FC,DB) ist der Name des Autors/Programmierers einzutragen
* jedes Netzwerk hat mindestens eine Überschrift, besser auch eine Kommentarzeile
* ist die Funktion eines Netzwerks nicht allgemeinverständlich, dann MUSS ein kurzer Kommentar sein
Kann die Funktion nicht in 2, 3 Sätzen erklärt werden, dann ist das Netzwerk zu groß und muß geteilt werden
* E/A-Symbole sind entsprechend Betriebsmittel-Bezeichnung im Stromlaufplan zu benennen
* FC/FB: für jeden Übergabe-Parameter sind die zulässigen Parameterwert-Bereiche anzugeben
* Schrittbausteine müssen über eine Zeitüberwachung verfügen und bei Fehlern den aktuellen Schritt anzeigen können.
* Alle verwendeten E/A-Punkte, Merker, Timer, Zähler und Bausteine müssen in der Symoltabelle aufgeführt sein
* alle verwendeten Variablen in DB müssen sinnvolle Namen zu haben
* Zuweisungen sollen mit = erfolgen, S/R sind nur zulässig, wenn tatsächlich eine speichernde Funktion nötig ist
* Mehrfachzuweisungen eines E/A-Punktes sind nicht zulässig, schon gar nicht an verschiedenen Programmstellen
* Mehrfachzuweisungen eines Merkers ist nur innerhalb eines/des selben Netzwerkes zulässig
* Die Zuweisung von 2 Zählern oder 2 Timern innerhalb eines Netzwerkes ist nicht zulässig
* Zuweisungen an Ausgänge sind nur in Programmteilen zulässig, die IMMER bearbeitet werden
(niemals in bedingt bearbeiteten Programmteilen)
* alle Timerwerte sind in DB zu hinterlegen, direkte Zeitwertangaben an einem Timer sind unzulässig
* Hardware-Konfig: ist ein Ethernet-CP vorhanden, dann muß der auf Steckplatz 4 sein (S7-300). Die E/A-Adressen 
E256..271 und A256..271 dürfen nur für Ethernet-CP genutzt werden, keinesfalls für DP-Slaves.
Diese Regel ist für S7-400 sinngemäß anzuwenden.
* Bei Einsatz von Profibus ist eine Liste der ausgefallenen/gestörten Slaves zu führen
(per OB86 oder Diagnosebausteine oder SZL auslesen) und auf Operatorpanels oder Visu anzuzeigen
* bei Operatorpanels oder Visualisierung muß der Störmeldetext die Betriebsmittelbezeichnung lt. Schaltplan enthalten
* Die Zykluszeit der CPU muß nach erfolgter Inbetriebnahme in der Dokumentation eingetragen werden. 
Wird diese wesentlich verändert, so ist das gesamte Programm zu überprüfen.
* Programmänderungen nach der Inbetriebnahme sind in einem ChangeLog zu dokumentieren
(Datum, Autor, Beschreibung, Grund, Änderungsstelle)
Das ChangeLog ist im Quellen-Ordner jeder CPU mit dem Namen "ChangeLog" zu führen.
* Während der Inbetriebnahme und nach jeder späteren Änderung ist vor Verlassen des Betriebes der aktuelle
 Programmstand als Quelltext auf einem Speichermedium des Kunden zu hinterlegen
* ...

Gruß
PN/DP


----------



## PN/DP (20 August 2009)

*Ausnahmen*

Von allen Richtlinien gibt es natürlich begründbare Ausnahmen.


----------



## Maxl (21 August 2009)

Ich gehe mal davon aus, es geht um eine Programmierrichtlinie für die eigenen Programmierer, nicht für Lieferanten.


Also, ohne jetzt eine große Philosophen-Runde anleiern zu wollen, aber einige Punkte halte ich für überzogen, an anderen Stellen gäbs weitere Vorgaben


PN/DP schrieb:


> * Ausgabewerte zu PAW generell vorher auf MW oder DBW speichern, dann erst ausgeben


Der Zugriff auf PEW/PAW ist generell (soweit machbar) zu vermeiden, Analogwerte sollten auch im Prozessabbild  liegen


> * Das DBD0 jedes DB, auf den Schreibzugriffe der OP oder Visu stattfinden, ist unbenutzt zu lassen


könnte ich ohne Begründung so hinnehmen, wozu das?


> * Schrittbausteine müssen über eine Zeitüberwachung verfügen und bei Fehlern den aktuellen Schritt anzeigen können.


außerdem ist eine Schrittdiagnose zu programmieren, mit der zumindest die letzten 10 Schritte (besser 30 oder 100) mit zeitstempel nachvollzogen werden können. Keine Schrittbausteine für kurze und einfach Abläufe, hier sind SR-Abläufe sinnvoller.


> * Mehrfachzuweisungen eines Merkers ist nur innerhalb eines/des selben Netzwerkes zulässig


mhm, lässt sich in Schrittbausteinen aber oftmals nicht vermeiden


> * Die Zuweisung von 2 Zählern oder 2 Timern innerhalb eines Netzwerkes ist nicht zulässig


zähler ok, aber timer? wichtig noch: ein Timer darf nur 1 mal im gleichen Netzwerk abgefragt werden, ggf. Merker am Ausgang anschließen


> * Zuweisungen an Ausgänge sind nur in Programmteilen zulässig, die IMMER bearbeitet werden (niemals in bedingt bearbeiteten Programmteilen)
> 
> 
> 
> ...


----------



## PN/DP (22 August 2009)

Ich möchte auch keine Philosophen-Runde veranstalten, aber versuchen, ein paar meiner nicht sofort verständlichen Richtlinien-Vorschläge zu erläutern.



Maxl schrieb:


> > * Ausgabewerte zu PAW generell vorher auf MW oder DBW speichern, dann erst ausgeben
> 
> 
> Der Zugriff auf PEW/PAW ist generell (soweit machbar) zu vermeiden, Analogwerte sollten auch im Prozessabbild liegen


Bei einigen CPU ist das Prozessabbild nicht groß genug für alle PAW oder nicht einstellbar. PAW können nicht beobachtet werden. 
Deswegen vor Ausgabe auf MW (oder DBW) legen. Außerdem sollen mit dieser Richtlinie mehrfach-Schreibzugriffe auf PAW verhindert werden.



> > * Das DBD0 jedes DB, auf den Schreibzugriffe der OP oder Visu stattfinden, ist unbenutzt zu lassen
> 
> 
> _könnte ich ohne Begründung so hinnehmen, wozu das?_


Reine Vorsichtsmaßnahme aus Erfahrung, wenn eine nicht-Step7-integrierte Visualisierung von einem Programmierer-Team erstellt wird.
Viele Visualisierer legen schon die Variablen für die Visualisierung an, ohne die exakte Adresse im Step7-Projekt zu kennen. Sie wissen aber
schon die Nummer des Schnittstellen-DB. Als Adresse wird dann erstmal DBD0, DBW0, DBB0 oder DBX0.0 eingegeben - und dann vergessen.
Wird das DBD0 freigehalten, so bewirken Schreibzugriffe der Visualisierung auf diese Variablen nichts falsches im Step7-Programm.


> * Schrittbausteine müssen über eine Zeitüberwachung verfügen und bei Fehlern den aktuellen Schritt anzeigen können.


Stammt aus der Programmierrichtlinie von Fa. Erasco/Lübeck, der man sich unterwerfen muß, wenn man für diese Fa. programmieren dürfen will.
Muß man natürlich auf ein vernüftiges Maß herunterhandeln. Hilft tatsächlich den Mechatronikern bei der Störungsanalyse von z.B. Packmaschinen.


> > * Mehrfachzuweisungen eines Merkers ist nur innerhalb eines/des selben Netzwerkes zulässig
> 
> 
> _mhm, lässt sich in Schrittbausteinen aber oftmals nicht vermeiden_


Das ist eine der begründbaren Ausnahmen, sollte aber wirklich auf Schrittmerker begrenzt bleiben.


> _wichtig noch: ein Timer darf nur 1 mal im gleichen Netzwerk abgefragt werden, ggf. Merker am Ausgang anschließen_


Diese Richtlinie ist mir unbekannt, leuchtet mir auch nicht so richtig ein. Bei allen mir bekannten SPSen wird ein Timer nur außerhalb des "OB1" aktualisiert,
niemals innerhalb eines Netzwerkes. Könnte ich aber mit leben, falls es verlangt würde.


> _UND: nur = Zuweisungen sind zulässig!_


Da gefällt mir "meine" Fassung dieser Richtlinie besser:
* Zuweisungen sollen mit = erfolgen, S/R sind nur zulässig, wenn tatsächlich eine *speichernde* Funktion nötig ist



> > * alle Timerwerte sind in DB zu hinterlegen, direkte Zeitwertangaben an einem Timer sind unzulässig
> 
> 
> _Schalterentprellzeiten oder Sicherheitszeiten sollen einstellbar sein?_


Stammt ebenfalls von Erasco, ABER: Begründbare Ausnahme. Teilweise gibt es sogar Vorschriften, daß bestimmte Zeiten hard-coded im Programm stehen müssen (z.B. Sicherheitszeiten).


> > * Hardware-Konfig: ist ein Ethernet-CP vorhanden, dann muß der auf Steckplatz 4 sein (S7-300). Die E/A-Adressen E256..271 und A256..271 dürfen nur für Ethernet-CP genutzt werden, keinesfalls für DP-Slaves.
> 
> 
> _also das halte ich für überzogen_


Diese Richtlinie stammt auch von Erasco, halte ich für sinnvoll.
Hintergrund:
Sollte aus irgendeinem Grund nicht mehr über die integrierte MPI(/DP)-Schnittstelle auf die CPU zugegriffen werden können, dann stellt diese Richtlinie sicher, daß immer ein CP343-1 in einem Werkstattaufbau an die CPU angesteckt werden kann, der CP dann über die Standard-System-Adressvorgabe der CPU die E/A-Adressen 256..271 erhält und über diesen CP die CPU urgelöscht und wiederbelebt werden kann.

@Maxl: Zu Deinen Vorschlägen, besonders auch zu den Hinweisen Remanenz betreffend:
*ACK*

* Taktmerker: einmal im Programm muß ein Byte-Zugriff auf das Taktmerker-Byte vorkommen (L "AG_Taktmerker"), damit diese in der Querverweisliste als benutzt auftauchen.

* Als guter "Mittelweg" zwischen verschiedenen Richtlinien bei Standard-Merkern für einfache Anlagen hat sich für mich dieses Schema bewährt:

```
M0.0  IMMER0
M0.1  IMMER1
M0.2  ZYKLUS1
M0.3  STOERUNG       //Sammelstörung
M0.4  NEUSTOERUNG    //neue Störung gekommen
M0.5  BLINK1         //1Hz Blinktakt
M0.6  LAMPENTEST
M0.7  NOTAUS         //0=Notaus
M1.0  TEST
M1.1  DUMMY
...
M1.5  PULS1          //1-Zyklus langer Puls jede Sekunde
...
M1.7 UNGEKLAERT      //0-Merker, markiert ungeklärte Verknüpfungen
...
```

Programmierrichtlinien sind ja sooooo ätzend - hat man sich aber erst einmal dran gewöhnt, dann erkennt man, daß diese meistens sinnvolle Hintergründe haben und einem die eigene Arbeit sogar erleichtern können.
Man kann ja so viel unbewußt verkehrt machen, wenn man einfach so ins Blaue hinein programiert.

Gruß
PN/DP


----------



## zotos (22 August 2009)

Ich brech mal die "ich will nicht Diskutieren Übereinkunft" 
Warum sollte man sich in einer nagelneuen "Programmierrichtline" gegen SCL und S7-Graph aussprechen? Wir sind doch nicht von vorgestern. Viele Firmen sind bei Ihren Schrittkettenkonzepten selbstverliebt jeder hat was entwickelt wo er sich selbst super drin auskennt aber das Rad wurde somit zichtausendfach neu erfunden. Gerade als Kunde würde ich für Schrittketten S7-Graph vorschreiben. SCL ist als Sprache super, wenn Siemens den Editor und das online Beobachten noch auf die Reihe bekommen würde, würde ich von AWL völlig abstand nehmen.

Nächster Punkt: Soll die Richtline nur für Siemens gelten? Wenn ja für welche Plattform? Es kündigt sich ja gerade die Nächste Step7 Generation an.

Wo man sich wirklich gedanken machen sollte, ist wie man Variablen und Bausteine bennent. Dem Vorschlag von PN/DP für E/As die BMK (Betriebsmittelkennzeichnung) zu verwenden kann ich nur zustimmen (dann sollte die BMK hat auch geregelt sein).

Anstelle einer schöden Richtlinie alleine würde ich dem Zuliefer auch eine quellenoffene Bausteinsammlung zur verfügung stellen. Wenn Standard Aufgabenstellenungen mit Standard Funktionen gelöst werden können haben beide Seiten was davon.


----------



## Paule (22 August 2009)

Hallo PN/DP und Maxl,

ich finde Eure Auflistung der Richtlinien sehr interessant.
Im Zuge der neuen Maschinenrichtlinie und der dabei geforderten Validierung ist es ja sehr sinnvoll die angewendeten Richtlinien zu benennen.

Mich würde jetzt interessieren unter welcher Norm Eure Richtlinien laufen, kommt das aus der ISO 13849-1 "Sicherheitsbezogene Teile von Steuerungen - allgemeine Grundsätze"?
Oder sind das Eure Firmen internen Richtlinien?
PN/DP Du hast ja schon zweimal die Fa. Erasco benannt, gibt es dafür einen bestimmten Grund?


----------



## bike (22 August 2009)

PN/DP schrieb:


> Das DBD0 jedes DB, auf den Schreibzugriffe der OP oder Visu stattfinden, ist unbenutzt zu lassen


So wie in S5? Bei S7 sehe ich zwingenden Grund, doch kann es allerdings hilfreich sein, wenn indirekt mit Pointern zugegriffen wird. Dann steht bei einem nicht initialisierten Zähler eben in dw0 Mist stehen, was nicht interssieren muss.


PN/DP schrieb:


> * Dokumentationssprache ist Deutsch


Deutschland ist Exportweltmeister, doch den Kunden deutsche Dokumentation anbieten klappt im Ausland eher weniger. 
Also wir müssen Englsch kommentieren.


PN/DP schrieb:


> * In jedem Programmbaustein (OB,FB,FC,DB) ist der Name des Autors/Programmierers einzutragen


Am besten mit Telefonnummer? Wenn der Baustein nicht macht er soll?

Das macht keinen Sinn, da das Programm von einer Firma entwickelt und verkauft wird. 
Da geht es niemand an wer was entwickelt hat. Denn es kommt uncool wenn nach einem Author gefragt wird, der nicht mehr in der Firma oder beim Mitbewerber ist.



PN/DP schrieb:


> * jedes Netzwerk hat mindestens eine Überschrift, besser auch eine Kommentarzeile
> * ist die Funktion eines Netzwerks nicht allgemeinverständlich, dann MUSS ein kurzer Kommentar sein
> Kann die Funktion nicht in 2, 3 Sätzen erklärt werden, dann ist das Netzwerk zu groß und muß geteilt werden



 Stichwort: strukturierte Programmierung



PN/DP schrieb:


> * Zuweisungen sollen mit = erfolgen, S/R sind nur zulässig, wenn tatsächlich eine speichernde Funktion nötig ist



Wann wird sonst eine speichernde Funktion verwendet, ausser wenn es notwendig ist?



PN/DP schrieb:


> * Mehrfachzuweisungen eines Merkers ist nur innerhalb eines/des selben Netzwerkes zulässig


Mehrfachzuweisung muss nie sein, es werden die einzelnen Verknüpfungen am Ende in einem separaten Netzwerk zusammengefasst.



PN/DP schrieb:


> * Hardware-Konfig: ist ein Ethernet-CP vorhanden, dann muß der auf Steckplatz 4 sein (S7-300). Die E/A-Adressen
> E256..271 und A256..271 dürfen nur für Ethernet-CP genutzt werden, keinesfalls für DP-Slaves.


Den selben Adressraum belegt auch eine NCK, daher macht dies wenig Sinn. 
Diese Adressen sind von Siemens default ausserhalb des PAE/PAA gelegt. 
Was machst du wenn mehr als ein CP verwendet werden?

Ich kenne das Problem Standardisierung bei uns aus dem Werk und weiss wie schwer dies ist. 
Es können und müssen nach meiner Meinung Richtlinien aufgestellt werden, die notwendig und hilfreich sind.
Doch für mich ist die Maxime: Der Kunde muss mit der Anlage und der Programmierung umgehen können.
Ja, die Instandhalter müssen das verstehen, was ich programmiert habe.

Daher sind unser Vorgaben an die Transline Vorgaben angelehnt, das passt für die Automobilisten und deren Zulieferer.

bike


P.S. Entwickler sind Künstler und welcher Künstler lässt sich schon vorschreiben wie er seine Kunst machen soll.


----------



## RobiHerb (24 August 2009)

*Künstler*



bike schrieb:


> ...
> P.S. Entwickler sind Künstler und welcher Künstler lässt sich schon vorschreiben wie er seine Kunst machen soll.



Das ist ein frommer Wunsch, deshalb hier ein anderes Zitat:

      „Genie ist 1% Inspiration und 99% Transpiration.“ Thomas A Edinson


Na und da die 1% Inspiration recht oft chaotisch ist, ergibt dann der grössere Teil die Forderung nach einer gewissen Disziplin in der Arbeit, die sich auch in Codier Richtlinien äussert.


----------



## bike (24 August 2009)

RobiHerb schrieb:


> Das ist ein frommer Wunsch



Das ist kein frommer Wunsch, sondern die Realiät.
Wie ich schon schrieb haben wir Richtlinien, das P.S war nur um zu erklären warum es so schwer ist Richtlinien zu erstellen und durch zu setzen.


bike


----------

