Verwendung der Fehlerbehandlungsbausteine

Pico1184

Level-2
Beiträge
332
Reaktionspunkte
9
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

da ich in der Vergangenheit öfters auf Software getroffen bin die zwar Fehler OBs geladen hatte,
diese aber alle immer komplett leer waren (in einem Fall sogar der OB121 Programmierfehler, was ich ohne Fehlerbehandlung tunlichst vermeiden würde),
wollte ich mal bei euch fragen ob ihr die Fehlerroutinen immer ausprogrammiert oder ob ihr dies auch dem Zufall überlässt.

Die PN/DP Teilnehmer Diagnose mache ich über einen eigenen Baustein und verwende die 80er OBs für diesen Fall daher auch nicht.

Wie läuft das bei euch alles so?

Grüße Pico
 
Hallo zusammen,

da ich in der Vergangenheit öfters auf Software getroffen bin die zwar Fehler OBs geladen hatte,
diese aber alle immer komplett leer waren (in einem Fall sogar der OB121 Programmierfehler, was ich ohne Fehlerbehandlung tunlichst vermeiden würde),
wollte ich mal bei euch fragen ob ihr die Fehlerroutinen immer ausprogrammiert oder ob ihr dies auch dem Zufall überlässt.

Die PN/DP Teilnehmer Diagnose mache ich über einen eigenen Baustein und verwende die 80er OBs für diesen Fall daher auch nicht.

Wie läuft das bei euch alles so?

Grüße Pico

Hi,

danke gut!
Ich mache mir das Leben einfach und verwende "Systemfehler melden" beim generieren der HW-Konfig.
Dabei werden ALARM-S meldungen erzeugt die auf entsprechenden Panels oder WinCC mit CPU-Zeitstempel angezeigt werden.
Funktioniert inzwischen ganz gut wenn man dabei keine exotische Hardware einsetzt für die es keine Meldetexte gibt.

Gruß
Johannes
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

da ich in der Vergangenheit öfters auf Software getroffen bin die zwar Fehler OBs geladen hatte,
diese aber alle immer komplett leer waren (in einem Fall sogar der OB121 Programmierfehler, was ich ohne Fehlerbehandlung tunlichst vermeiden würde),
wollte ich mal bei euch fragen ob ihr die Fehlerroutinen immer ausprogrammiert oder ob ihr dies auch dem Zufall überlässt.

Die PN/DP Teilnehmer Diagnose mache ich über einen eigenen Baustein und verwende die 80er OBs für diesen Fall daher auch nicht.

Wie läuft das bei euch alles so?

Grüße Pico

Also in meinen Steuerungen ist der OB121 auch leer. Mir geht es darum das bei der IB die CPU nicht in Stop geht falls ich mal eine Fehler mache.
 
Daß ich eine ausprogrammierte Fehlerauswertung im OB121 für überflüssig halte, habe ich in dem anderen Thread schon geschrieben.
Wenn ich in meinen Anlagen einen OB121 finde, dann bleibt der auch drin - dann hat es irgendwann mal einen Grund gegeben, den da einzuspielen. Meistens den, daß der Programmierer aus "gutem" Grund seinem eigenen Programm nicht traut. ;) Oder weil ein CPU-Stop zur Unzeit sehr teure Folgen hätte. Besser es werden nur immaterielle Daten zerstört als materiell wertvolle Produkte.

Da bei uns eine SPS meistens eine ausgedehnte Anlage steuert, halte ich einen leeren OB121 zur Verhinderung des CPU-Stops für besser als eine möglicherweise zunächst unerkannte fehlerhafte Datenverarbeitung mit nur lokaler Auswirkung. Alle bisher von mir in der Wildbahn beobachteten Gründe für tatsächliche OB121-Aufrufe waren Kleinigkeiten in Datenverarbeitung, deren negative Folgen auch so am Anlagenverhalten entdeckt worden sind. Doch die meisten Fehlfunktionen der Anlagen kamen aus logischen Programmierfehlern, welche sowieso den OB121 nicht aufgerufen haben.

Harald
 
... es gibt ja nicht nur den OB121 - den habe ich noch nie irgendwo gebraucht ...
Ich habe in meinen Programmen z.B. immer die Perepherie-OB's (natürlich leer) drin, die man ja meißt deshalb da reinbaut weil eine Perepherie sich manchmal etwas gewöhnungsbedürftig verhält ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... es gibt ja nicht nur den OB121 - den habe ich noch nie irgendwo gebraucht ...
Ich habe in meinen Programmen z.B. immer die Perepherie-OB's (natürlich leer) drin, die man ja meißt deshalb da reinbaut weil eine Perepherie sich manchmal etwas gewöhnungsbedürftig verhält ...

@ Larry

wenn Du die OB´s onehin drin hast warum verwendest Du nicht "Systemfehler Melden"?
Man bekommt den Diagnosepuffer der CPU ganz normal, ohne PG, gemeldet.

Gruß

Johannes
 
Hallo Johannes,

Du machst es dir ja wirklich einfach ;) . Ich bin (leider erst kürzlich) auch auf diese Funktion gestoßen. Es ist wirklich sehr einfach, kann es nur empfehlen.


Gruß, Onkel

Habe die Funktion erstmals 2007 verwendet und die CPU ging brutal auf STOP. Die Entwickler hatten die 414H/F schlicht übersehen!
3 Monate und ein SP später ging die CPU nicht mehr auf Stop dafür gab es aber (noch) keine Meldetexte für die ET200M F-Module.
Trotzdem sehr empfehlenswert!
Ich verwende auch ganz allgemein das ALARM-S bzw. ALARM-8P Verfahren, habe seit 2005 kein klassisches Meldesystem mit Bitverfahren projektiert und es geht mir weiterhin sehr gut.

Gruß

Johannes
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@ Larry

wenn Du die OB´s onehin drin hast warum verwendest Du nicht "Systemfehler Melden"?
Man bekommt den Diagnosepuffer der CPU ganz normal, ohne PG, gemeldet.

Hallo Johannes,
in dem Fall, auf den ich mich gerade bezogen habe, ist es so, dass es sich um überhaupt keinen Fehler handelt.
- Ich habe z.B. eine Servo-Achse, die beim Starten mal ganz kurz einen Diagnose-Fehler meldet (aber ganz normal arbeitet). Dies ist nach Angaben des Herstellers "normal" - OK ...
- Ich habe z.B. Ventil-Inseln oder ET-Stationen, denen ich zeitweilig die Lastspannung wegnehme. Dann bringt das Ding einen Diagnose-Fehler (der mich nicht wirklich interessiert), der auch keinen CPU-Stop bringen soll.

Wenn ich noch länger nachdenke dann finde ich sicherlich noch weitere Beispiele für das Thema.
Wie schon geschrieben - Perepherie-Fehler-OB's und nicht System-Fehler OB ...

Gruß
Larry
 
Hallo Johannes,

Wenn ich noch länger nachdenke dann finde ich sicherlich noch weitere Beispiele für das Thema.
Wie schon geschrieben - Perepherie-Fehler-OB's und nicht System-Fehler OB ...

Gruß
Larry

Hi Larry,

Du hast für Dich bestimmt die Lösung die Du auch benötigst.
Was ist aber mit einem echten Fehler? Drahtbruch, Analogsignal übersteuert, Karte defekt etc. pp..?
Ist es nicht schön in diesem Fall eine Kanalfehler Meldung zu bekommen, mit Angabe der Baugruppe und Kanal, für die Du keinen einzigen Strich Software schreiben musstest?

Gruß
Johannes
 
Ist es nicht schön in diesem Fall eine Kanalfehler Meldung zu bekommen, mit Angabe der Baugruppe und Kanal, für die Du keinen einzigen Strich Software schreiben musstest?
Ist ja alles ganz praktisch und schön, aber ich finde es persönlich sinnvoller eine Meldung wie "Füllstandsmessung Behälter xy Drahtbruch" anstatt "Baugruppe 3 Kanal 4 Drahtbruch" (oder was auch immer dort generiert wird) zu bekommen.
Bei PCS7 werden auch allerhand automatische Meldungen generiert. Der normale Anlagenfahrer kann damit aber überhaupt nichts anfangen. Mit einer Meldung dass Messung xy einen Drahtbruch hat schon eher.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ist ja alles ganz praktisch und schön, aber ich finde es persönlich sinnvoller eine Meldung wie "Füllstandsmessung Behälter xy Drahtbruch" anstatt "Baugruppe 3 Kanal 4 Drahtbruch" (oder was auch immer dort generiert wird) zu bekommen.
Bei PCS7 werden auch allerhand automatische Meldungen generiert. Der normale Anlagenfahrer kann damit aber überhaupt nichts anfangen. Mit einer Meldung dass Messung xy einen Drahtbruch hat schon eher.

Hi Thomas,

eigentlich wollte ich nicht ganz so tief einsteigen aber ich nehme den Ball gern auf.
Selbsverständlich hast Du recht, aaaaaber jetzt vermischt sich die verfahrenstechnische Sicht mit der leittechnischen.
Die Meldungen die Du meinst kommen direkt aus MSR Bausteinen. Ich verwende ALARM_S für die 300er CPUs und ALARM 8P für die 400.
Die Meldungen vom System sind hardwareorientiert und kommen zusätzlich dazu entprechend den projektierten Diagnosefunktionen.
Das ergibt dann eine art PCS 6,5 für arme Leute (nicht ganz PCS7 aber mit CFC stand alone, eigenen Bausteinen ohne Treiber und AS-OS Engineering).

Gruß
Johannes
 
Vom Systemfehler Melden kommen vom Text her ähnliche Meldungen wie beim PCS7 durch die Treiberbausteine. Mit den Texten kann der normale Anlagenfahrer in der Regel wirklich nix anfangen. Dafür werden sie automatisch generiert, ohne dass man da irgendwas projektieren muss. Teilweise werden dort aber Texte aus der HW-Konfig mit integriert, also wer da Lust hat, kann an der Stelle schon etwas Klartext hineinbringen.
Weiterhin werden auch Meldungen von ganzen EA-Karten oder von der IM generiert, welche einer einzelnen Messstelle eh nicht zugeordnet werden können.

Alles in allem eine einfache Diagnosemöglichkeit für Anlagen bei denen der Kunde nicht eine händische projektierte Diagnose mit Klartexten bezahlen will. Und bei großen Anlagen mit vielen Karten will ich das auch garnicht alles händisch projektieren...

PCS6,5 für arme Leute nutze ich auch :)

Gruß.
 
Ich habe die Diagnose normalerweise in meine Typicals integriert. Denn im Programm hat man doch meistens auf eine Messwertstörung oder auf den Ausfall eines Profibusteilnehmers zu reagieren. Also muss eine Auswertung vorhanden sein.

An der OS interessiert es wirklich niemanden bei Ausfall eines Profibus Umrichters dass im Programm gerade der OB86 oder der OB121/122 aufgerufen wurde. Ich finde so eine Meldung sogar falsch, weil es nicht die Ursache einer Störung anzeigt sondern nur eine Auswirkung. Eine Meldung mit "Ausfall Profibusteilnehmer Frequenzumrichter Motor xy" sagt hingegen eindeutig wo der Fehler zu suchen ist.
 
Zurück
Oben