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
