Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 6 von 6

Thema: Fragen zur Vermeidung von CPU-Stop

  1. #1
    Registriert seit
    22.10.2010
    Beiträge
    188
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard


    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)
    Zitieren Zitieren Fragen zur Vermeidung von CPU-Stop  

  2. #2
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.314
    Danke
    932
    Erhielt 3.329 Danke für 2.688 Beiträge

    Standard

    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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  3. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    bike (11.02.2014)

  4. #3
    Registriert seit
    09.10.2012
    Beiträge
    183
    Danke
    7
    Erhielt 17 Danke für 12 Beiträge

    Standard

    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.
    Geändert von INSEVIS-Service (12.02.2014 um 08:52 Uhr)
    Viele Grüße / best regards
    Stefan vom Support

    INSEVIS GmbH

  5. #4
    Xplosion ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.10.2010
    Beiträge
    188
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Es reicht also, wenn die oben genannten OB´s alle vorhanden sind oder?

  6. #5
    Registriert seit
    30.08.2010
    Ort
    Östereich
    Beiträge
    1.470
    Danke
    506
    Erhielt 218 Danke für 193 Beiträge

    Standard

    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
    Elektrotechnik und Elektronik funktioniert mit Rauch (Beweis: Tritt Rauch aus, funktioniert auch das Bauteil nicht mehr)

  7. #6
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.314
    Danke
    932
    Erhielt 3.329 Danke für 2.688 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Xplosion Beitrag anzeigen
    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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  8. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    Ing_Lupo (13.02.2014)

Ähnliche Themen

  1. Antworten: 8
    Letzter Beitrag: 09.01.2012, 11:35
  2. Antworten: 17
    Letzter Beitrag: 21.08.2008, 07:47
  3. Kein Stop der CPU bei entfernen von DP-Slave
    Von tuppes38 im Forum Feldbusse
    Antworten: 15
    Letzter Beitrag: 20.11.2006, 16:52
  4. CPU-Kopplung von Simulations-SPSen zur einfachen Anlagensimulation
    Von Gerhard Bäurle im Forum Werbung und Produktneuheiten
    Antworten: 0
    Letzter Beitrag: 13.10.2006, 14:13
  5. Fragen zur CPU 224XP
    Von Hightowerxxx im Forum Simatic
    Antworten: 20
    Letzter Beitrag: 11.10.2005, 04:39

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •