Stop bei Zykluszeitüberschreitung

Deep Blue · 15 Mai 2008

Hallo,

mit folgendem Problem schlage ich mich herum: Eine SPS in unserer Firma geht ab und zu auf Stop, nachdem eine Zykluszeitüberschreitung stattgefunden hat (> 350 ms). Oft ist es an einem Zeitpunkt, wo ich nicht mehr im Hause bin und ein Angestellter den Schlüsselschalter auf Stop und zurück auf Run stellen muß, damit es wieder läuft. Nun würde ich ja gerne den permanenten Zyklus über einen Trend mitschreiben um zu sehen wann die Zeit hoch geht und wann nicht. Leider sind in dem Baugruppenzustand nicht mehr die Details der letzten Überschreitung sichtbar. Wie bekomme ich raus warum die Zykluszeit angestiegen ist und/ oder wie kann man den Zyklus mitloggen? Wie kann ich mich auf den nächsten "Absturz" vorbereiten?

MW · 15 Mai 2008

hast du dir schon mal den OB 80 angeschaut, der kann den Stop verhindern und du kannst rausfinden woran es liegen könnte

Einfach mal die Hilfe zu dem OB durchlesen

könnte mir aber vorstellen, dass deine CPU in irgendeiner Schleife hängenbleibt

vierlagig · 15 Mai 2008

jetz hab ich die infos schon zusammengetragen, da werd ich es auch posten, so:

Überschreitet Ihr Programm die maximale Zykluszeit für den OB 1, dann ruft das
Betriebssystem den OB 80 (Zeitfehler-OB) auf. Ist der OB 80 nicht programmiert,
dann geht die CPU in den Betriebszustand STOP.

im OB80 kannst du dann

Fehlercode B#16#01 Zykluszeit überschritten
OB80_ERROR_INFO: Laufzeit des letzten Zyklus (ms)
OB80_ERR_EV_CLASS: Klasse des Ereignisses, das den Alarm ausgelöst hat
OB80_ERR_EV_NUM: Nummer des Ereignisses, das den Alarm ausgelöst hat
OB80_OB_PRIORITY: die zum Alarmzeitpunkt aktive Prioritätsklasse

auswerten

Deep Blue · 15 Mai 2008

vierlagig schrieb:
im OB80 kannst du dann...

Erst mal vielen Dank für Eure schnelle Antwort. Also der OB 80 ist sowohl On- wie auch Offline leer. Klasse Arbeit eines Dienstleisters :sb6: .Da ich den OB 80 noch nicht bearbeitet habe oder mit Ihm zu tun hatte (Schande:TOOL: ) nun mal die Frage, wie ich es verhindere, das mit den OB 80 die CPU in Stop geht. Reicht es,

Code:

      L     #OB80_FLT_ID
      T     DB1.DBW    0
      L     #OB80_ERROR_INFO
      T     DB1.DBW    2
      L     #OB80_ERR_EV_CLASS
      T     DB1.DBW    4
      L     #OB80_ERR_EV_NUM
      T     DB1.DBW    6
      L     #OB80_OB_PRIORITY
      T     DB1.DBW    8

es in dieser Form zu tun und damit den Stop zu verhindern? Oder sollte da noch ein wenig mehr passieren?

vierlagig · 15 Mai 2008

Deep Blue schrieb:
Erst mal vielen Dank für Eure schnelle Antwort. Also der OB 80 ist sowohl On- wie auch Offline leer. Klasse Arbeit eines Dienstleisters :sb6: .Da ich den OB 80 noch nicht bearbeitet habe oder mit Ihm zu tun hatte (Schande:TOOL: ) nun mal die Frage, wie ich es verhindere, das mit den OB 80 die CPU in Stop geht. Reicht es,

Code:

L #OB80_FLT_ID T DB1.DBW 0 L #OB80_ERROR_INFO T DB1.DBW 2 L #OB80_ERR_EV_CLASS T DB1.DBW 4 L #OB80_ERR_EV_NUM T DB1.DBW 6 L #OB80_OB_PRIORITY T DB1.DBW 8

es in dieser Form zu tun und damit den Stop zu verhindern? Oder sollte da noch ein wenig mehr passieren?

der OB80 verhindert, dass die CPU in STOP geht, dazu muß er nur auf der Steuerung verfügbar sein und muß nicht ausprogrammiert sein.

mit deinem code speicherst du die Fehlerauswertung und kannst sie dir später anschauen.

Larry Laffer · 15 Mai 2008

So nebenher ...
Kann es ggf. auch sein, dass die Zykluszeit-Überschreitung gar kein Programmfehler ist, sondern das Ergebnis einer hin- und wieder stattfindenden Rechnenoperation (innerhalb einer Schleife), die deine Zykluszeit ganz gezielt hochtreibt ? In dem Fall könntest du auch den Überwachungswert hochsetzten ...

Ansonsten ... der von dir gepostete Code überschreibt immer den davor gewesenen Wert. Wenn dir das so reicht sollte das OK sein. Ich hoffe du hast die Variablengrößen beachtet (ich kann gerade nicht nachschauen).

Gruß
LL

Deep Blue · 15 Mai 2008

Larry Laffer schrieb:
So nebenher ...
Kann es ggf. auch sein, dass die Zykluszeit-Überschreitung gar kein Programmfehler ist, sondern das Ergebnis einer hin- und wieder stattfindenden Rechnenoperation (innerhalb einer Schleife), die deine Zykluszeit ganz gezielt hochtreibt ? In dem Fall könntest du auch den Überwachungswert hochsetzten ...

Nachdem ich nun etwas nachgeforscht habe ist mir aufgefallen, das immer eine Fehlermeldung die letzte vor dem CPU-Stop ist. Das konnte ich aus dem LogFile der Visu auslesen. Es ist immer ein und der selbe Türkontakt. Warum der nun meine CPU killt ist mir aber noch ein Rätsel. Der jetzige max. Wert liegt bei 350 ms.

Larry Laffer schrieb:
Ich hoffe du hast die Variablengrößen beachtet (ich kann gerade nicht nachschauen).
Gruß
LL

Ich wollte damit nur veranschaulichen, wie ich mir die Auswertung vorstelle.

@ vierlagig

Der OB 80 ist zwar leer, aber Online vorhanden. Dann sollte die CPU doch eigentlich weiter laufen,oder?

Kwyjibo · 15 Mai 2008

der OB80 muss nichts beinhalten, wenn du den im simatic manager erzeugst (rechtsklick usw. -> neuer OB) und dann OB80 eingibst, wirst du schon am automatisch vergebenen symbol sehen, dass es der richtige ist.

mit was schreibst du deine bausteine? wenn du bspw. CFC hast würd ich auch mal in die ablaufgruppen schauen, und guggen was so alles aufgerufen wurde, denn wenn die zeitüberschreitung nur ab und zu passiert, kann es gut sein, dass einfach ein OB1 (mit max. 6000ms überwachungszeit) so oft durch höherpriore OB's unterbrochen wird, bis er die 6000ms überschreitet.

nun hast du zwei fälle..

-> OB80 nicht projektiert (man kann ihn sogar im onlinemodus direkt auf die CPU kopieren, musst nicht mal laden) -> CPU geht in stop!

-> OB80 projektiertd und geladen -> überwachungszeit geht nochmal los, ABER!!!!! nur noch einmal!!!

Das heißt, wenn dein OB1 12001ms brauchen würde, also beliebiger wert höher als 2x überwachungszeit, geht die CPU trotz OB80 100% sicher in STOP!! -> nun weiß ich nicht welcher OB das war der hier die zeit überschritten hat, aber wenns einer mit zB 150ms ist, wäre bei 350ms trotz OB80 ein STOP aufgetreten.

ein leerer OB macht nur probleme wenn du CFC bzw. PCS 7 nutzt, denn der compiler löscht leere OBs (wie zb den OB80). lösung: bau einfach nen FC-aufruf eines beliebigen leeren FC ein und das passiert auch nicht mehr!

also so doof ist der OB80 nicht, nicht gleich los-:sb5:

wenn ein OB so extrem lange braucht, wird oft unterbrochen durch höherpriore OBs (die wiederum selbst unterbrochen werden können, und deren zeit addiert sich zum niederpriorsten OB dazu...), ist so ein klassiker bei "sporadisch" auftretenden zyklusüberschreitungen.

vierlagig · 15 Mai 2008

mit dem Aufruf des SFC 43 "RE_TRIGR" im OB80 kannst du die Zykluszeitüberwachung immer wieder neustarten, würde aber die Aufrufe zählen und begrenzen...

was ist denn um den Türkontakt drum rum geproggt?

Larry Laffer · 15 Mai 2008

vierlagig schrieb:
... was ist denn um den Türkontakt drum rum geproggt?

Das würde mich in dem Zusammenhang auch interessieren ...
Ich vermute hinter der Zykluszeit-Überschreitung ja nach wie vor eine Schleifen-Bearbeitung, die (zu Recht oder zu Unrecht) den voreingestellten Wert überschreitet (möglich wäre auch Endlos-Schleife).
Den Vorschlag mit den höher-prioren OB's kann ich mir hier nicht unbedingt vorstellen.

Gruß
LL

Kwyjibo · 15 Mai 2008

ich denke halt oft in CFC

also wenn es eine schleife ist, müsste man überlegen, welche schleife den als bedingung irgendetwas hat, was mit dem an/aus zu tün hat (wenn der wächter das durchführt)?

persönlich glaube ich nicht, dass es mit höherprioren OB's hier zu tun hat, nachdem ich mir sein problem nochmal genauer angeschaut habe, weil.. also ich glaub "not"-dinge finden hier wohl nicht statt.

du kannst ja mit TIME_BEGIN und TIME_END bei jedem OB messen wie lang der läuft und das abspeichern.

PS: das mit der zykluszeitüberschreitung neu anlaufen lassen sehe ich persönlich nicht so gerne, weil man im normalfall die anlage so planen sollte, dass alles eben richtig läuft - also nicht langsame prozesse in extrem schnellen OB's laufen lassen etc. ... sondern alles eben so oft/schnell wie der prozess es benötigt... ist für mich ein bisschen wie sprünge in höheren sprachen, man kanns machen aber das kann auch gut in die hose gehen.

Borsti · 16 Mai 2008

Wie groß ist den überhaupt die normale Zykluszeit?
Ich mein, wenn die normale Zykluszeit schon in der nähe der 350ms rum eiert, muß dieser Türkontakt ja nur eine popelige Routine aufrufen und schon bist du über die 350ms hinaus...
Kannst ja mal beim Baugruppenzustand (ich mein da stände das), die kürzeste, aktuelle und längste Zykluszeit posten. Kann ja auch sein, daß dein Programm generell stark schwankt, was die Zykluszeiten angeht...

Flinn · 16 Mai 2008

Nabend,
was steht denn im Diagnosepuffer der CPU nach so einem Stop?

Da mal nachgucken ist eigentlich das erste, was man nach einem CPU-Stop - wodurch auch immer ausgelöst - macht.

Gruß
Flinn

Borsti · 16 Mai 2008

siehe #7 in diesem Thread...

Flinn · 16 Mai 2008

Borsti schrieb:
siehe #7 in diesem Thread...

Beitrag #7:

Deep Blue schrieb:
Nachdem ich nun etwas nachgeforscht habe ist mir aufgefallen, das immer eine Fehlermeldung die letzte vor dem CPU-Stop ist. Das konnte ich aus dem LogFile der Visu auslesen. Es ist immer ein und der selbe Türkontakt. Warum der nun meine CPU killt ist mir aber noch ein Rätsel. Der jetzige max. Wert liegt bei 350 ms.

Ich wollte damit nur veranschaulichen, wie ich mir die Auswertung vorstelle.

@ vierlagig

Der OB 80 ist zwar leer, aber Online vorhanden. Dann sollte die CPU doch eigentlich weiter laufen,oder?

Wo steht denn im Beitrag #7 etwas vom Diagnosepuffer der CPU?

Gruß
Flinn

MW · 17 Mai 2008

Flinn schrieb:
Wo steht denn im Beitrag #7 etwas vom Diagnosepuffer der CPU?

Augen auf !!!

IM ANHANG ist ein Screenshot

Tom08 · 23 Mai 2008

Hallo

wenn die Zykluszeit so hoch ist würde ich mal Kompremieren vielleicht sind da noch Leichen in der CPU.

Stop bei Zykluszeitüberschreitung

Deep Blue

Level-2

MW

Level-1

vierlagig

Level-1

Deep Blue

Level-2

vierlagig

Level-1

Larry Laffer

Super-Moderator , User des Jahres 2008-2009

Deep Blue

Level-2

Anhänge

Kwyjibo

Level-1

vierlagig

Level-1

Larry Laffer

Super-Moderator , User des Jahres 2008-2009

Kwyjibo

Level-1

Borsti

Level-1

Flinn

Level-2

Borsti

Level-1

Flinn

Level-2

MW

Level-1

Tom08

Level-1

Similar threads

Wir schützen deine Privatsphäre