Es reicht also, wenn die oben genannten OB´s alle vorhanden sind oder?
Das kann man so pauschal nicht unterschreiben... ich weiß ja nicht wie kreative Programmierfehler Du machen kannst
Man muß unterscheiden, welche OB wegen möglichen Programmierfehlern bei der Programmänderung im Run vorhanden sein sollten und welche OB sowieso wegen Hardware-Ereignissen vorhanden sein müssen (unabhängig von der Programmänderung in Run). Ein OB86 (Baugruppenträgerausfall) wird normal nicht wegen einem Softwarefehler ausgelöst...
Um die CPU vor einem Stop wegen möglichen "einfachen" Programmierfehlern im neuen Code und vor "Blödheit" bzw. falschen Handlungen zu schützen reichen nach meiner Erfahrung die
OB121 (Programmierfehler),
OB122 (Peripheriezugriffsfehler) und
OB85 (Programmablauffehler). Wenn Sprünge oder Schleifen zum geänderten Code gehören, dann sollte dieser Code vor dem Einspielen penibel in PLCSIM getestet werden, ob sich nicht womöglich ein Rückwärtssprung oder eine Endlosschleife eingeschlichen hat. Zur Sicherheit kann man vor der Programmänderung einen
OB80 (Zeitfehler) mit Aufruf des SFC43 RE_TRIGR in die Steuerung laden, doch in einer produktiven Steuerung hat ein OB80 imho nichts zu suchen.
Genaugenommen müßte vorsichtshalber auch ein
OB88 (Bearbeitungsabbruch) vorhanden sein, doch praktisch habe ich in den letzten 16 Jahren an einigen hundert S7-CPU noch nie einen OB88 gebraucht. So saudumme Fehler sollten Programmierern nicht passieren, welche Programmänderungen in Run an produzierenden Anlagen durchführen dürfen ...
Man kann für fast jeden OB eine Situation konstruieren, wo das Vorhandensein dieses OB notwendig ist, doch es macht keinen Sinn, in jede Steuerung vorsichtshalber jeden möglichen OB zu laden. Es kommt letztlich auf den konkreten Einzelfall drauf an.
Was kann weitere OB erfordern bzw. Stop auslösen:
- eine Aktion des Programmierers erfordert Stop der CPU und der Programmierer klickt (gedankenlos) auf OK im Dialog, wo er das Stoppen bestätigen soll
- die vorsorglich geladenen Fehler-OB enthalten selber Programmierfehler
- das Programm oder ein Fehler-OB enthält Aufruf der SFC46 STP und ruft die durch fehlerhafte Logic auf
- wenn das Programm mit SFC39..SFC42 hantiert (maskieren/freigeben von Asynchronfehler-Ereignissen)
- parametrieren von Baugruppen im Programm (SFC55..SFC57, SFB53) kann Prozessalarme (OB4x) und Diagnosealarme (OB82) auslösen
Prozessalarm-OB4x --> kann unmäßige Verlängerung des OB1-Zyklus verursachen --> Zykluszeit OB80
- SFC12 Aktivieren von DP-Slaves/PROFINET IO-Devices mit MODE 3 oder 4 --> OB86 (Baugruppenträgerausfall)
- Anlagenänderung im laufenden Betrieb (CiR) --> OB83 (Ziehen/Stecken-Alarm)
- Uhrzeitalarme aktivieren mit SFC28 und SFC30 --> OB10..OB17 nicht vorhanden --> OB85 (Programmablauffehler)
- die CPU-Uhr verstellen bei aktiven Uhrzeit-Alarmen --> OB80 (Zeitfehler)
- Aktivieren von Verzögerungsalarmen mit SFC32 --> OB20..OB23 nicht vorhanden --> OB85 (Programmablauffehler)
- zu lange Bearbeitung in Weckalarm-OB30..OB38 --> OB80 (Zeitfehler)
- SFC82..SFC84 auf Ladespeicher zugreifen und gleichzeitig betroffene DB von PG in die CPU laden kann den OB1-Zyklus verlängern --> OB80 (Zeitfehler)
- Bausteine laden wenn sehr hohe Aufruffrequenz von Weckalarm-OB3x und/oder Prozessalarm-OB4x --> OB80 (Zeitfehler)
- Bausteine ändern, die SFC65..SFC69 der S7-Basiskommunikation enthalten kann zur Verringerung von freien Verbindungsressourcen führen, was nur durch Stop/Neustart der CPU beseitigt werden kann
- viele unerwartete Fehler kann man auslösen, wenn man Bausteine auf der CPU löscht
z.B. löschen eines an der Globaldatenkommunikation beteiligten DB --> OB87 (Kommunikationsfehler)
löschen von Fehler-OB8x, OB121, OB122 --> direkt Stop bei Auftreten eines entsprechenden Fehlers
löschen von Uhrzeitalarm-OB1x oder Verzögerungsalarm-OB2x --> OB85 (Programmablauffehler)
löschen von im Programm aufgerufenen FB, FC --> OB121 (Programmierfehler)
- Spezialprobleme bei Multicomputing, F-CPU, ...
- und und und ...
Wie ich schon in #2 schrieb: Das beste ist, keine Fehler machen! Nicht schnell sondern konzentriert arbeiten. Sich vor der Änderung der möglichen Folgen klar sein und nochmal prüfen. Ein gewisses Maß an Professionalität und Sorgfalt muß man schon voraussetzen, wenn man Programmierer an laufenden Anlagen rumprogrammieren läßt. Sollte der Programmierer noch nicht reif genug dafür sein, dann ist es vielleicht sogar besser, wenn die CPU als "Strafe" in Stop geht - ein solches Ereignis vergißt derjenige wohl nie mehr!
Und wichtig: immer wieder mal einen Blick in den CPU-Baugruppenzustand und Diagnosepuffer werfen.
Btw: Und bei der Inbetriebnahme einer Anlage nicht zu faul sein die CPU-Uhr zu stellen.
Harald