Step 7 Fragen zur Vermeidung von CPU-Stop

Xplosion

Level-1
Beiträge
202
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

hab eine allgemeine Frage:


Wenn ich ein bestehendes Programm im laufenden Betrieb erweitern möchte, passiert es immer wieder, dass die CPU in Stop geht. Hab dann mal wieder einen Funktionsbaustein draugeladen ohne vorher den DB zu laden bzw. eine Adresse vergeben, die nicht im DB existiert.

Wie kann ich den CPU-Stop umgehen, so dass ich auf die SPS im laufenden Betrieb schreiben kann ohne jedes mal Sorge zu haben, dass die komplette CPU stoppt.

Wenn ich jetzt alle Fehler-OB´s im Programm erstelle, kann ich dann einen STOP beim Erweitern der Programmierung definitiv ausschliessen?

Andererseits ist es ganz gut, wenn die CPU stoppt. Dann sehe ich gleich was ich falsch gemacht habe.


Wie macht ihr das im laufenden Betrieb?


Arbeite mit Insevis S7 (= S7-315-2PNDP)
 
Keine Fehler machen ;)

Oder OB121 und OB122 in die CPU laden und dann regelmäßig nach Programmänderungen in den Baugruppenzustand/Diagnosepuffer schauen, ob noch alles in Ordnung ist.

PLCSIM hilf auch ungemein beim offline-Programmtest vor dem Einspielen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

Die Fehler OB s funktionieren natürlich.

Wichtig: der OB 121 Programmierfehler

OB 122 Peripheriezugriffsfehler

OB 80 Zeitfehler
OB 82 Diagnosealarm
OB 85 Programmablauffehler
OB 86 Baugruppenträgerausfall und externe Peripherie


Bei Programmfehlern kann man ja noch die
Diagnose benutzen.

Dann sollte die CPU im RUN bleiben.
 
Zuletzt bearbeitet:
Ja, aber du musst nach jedem laden in die Diagnose gehen und schauen ob alles OK ist (wird hier einer der Fehler OB angefordert -> Fehler)

Besser wäre es natürlich wenn du in den Fehler OB zB. einen Merker setzt und den gleich irgendwie visualisierst, dadurch siehst du gleich wenn was schiefgeht :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 :cool:
    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
 
Zurück
Oben