Step 7 B-Stack auslesen bei Zykluszeitfehler OB80

[Gelöschtes Mitglied 103809]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

ich habe an einer S7-400 das Problem, dass ca. alle 3 Monate einmal OB 80 kommt und die CPU in Stop geht, wegen Zykluszeitüberschreitung. Die CPU läuft sonst bei ca 30ms, fällt an dem Punkt aber mit der Überschreitung der Grenze von 150ms aus. Leider war ich nicht vorort beim letzten Fall und konnte mir nicht den B-Stack angucken in der Diagnose. Daher die Frage, wenn der OB80 getriggert wird, kann ich da irgendwie im OB80 den B-Stack auslesen und Typ (z.B. FC) und Nummer (z.B. 100) in einen DB schreiben?

 

[DeltaMikeAir]

Da die CPU in Stopp wechselt, gehe ich einmal davon aus, das der OB80 nicht geladen wurde. Oder?

Richtig wäre es wohl, die TEMP Variablen des OB80 auszuwerten, zu sichern und dann um schlimmeres zu verhindern die CPU gezielt in den Stop zu bringen.

Die vom Fehlercode abhängigen Variablen haben folgende Bedeutung:


Fehlercode Bit Bedeutung
B#16#01 OB80_ERROR_INFO: OB80_ERR_EV_CLASS:
OB80_ERR_EV_NUM:
OB80_OB_PRIORITY:
OB80_OB_NUM Zykluszeit überschritten.Laufzeit des letzten Zyklus (ms).Klasse des Ereignisses,
das den Alarm ausgelöst hat.Nummer des Ereignisses,
das den Alarm ausgelöst hat.Prioritätsklasse des OB, der bearbeitet wurde,
als der Fehler auftrat.Nummer des OB, der bearbeitet wurde, als der Fehler auftrat.
B#16#02 OB80_ERROR_INFO:
OB80_ERR_EV_CLASS:
OB80_ERR_EV_NUM:
OB80_OB_PRIORITY


OB80_OB_NUM: Der angeforderte OB ist noch in Bearbeitung.Die zugehörige temporäre Variable des
angefordeten OB. Dieser ist bestimmt durch:OB80_ERR_EV_CLASS undOB80_ERR_EV_NUM.Klasse des Ereignisses, das den Alarm
ausgelöst hatNummer des Ereignisses, das den Alarm ausgelöst hat.Prioritätsklasse des Fehler verursachenden OBs
(z. B.: "7" für OB30/Prioritätsklasse 7, der
gestartet werden sollte, aber nicht gestartet werden konnte).Nummer des Fehler verursachenden OB (z. B.: "30" für OB 30, der gestartet werden sollte, aber nicht gestartet werden konnte).
B#16#05 undB#16#06
OB80_ERROR_INFO:

OB80_ERR_EV_CLASS: OB80_ERR_EV_NUM: OB80_OB_PRIORITY: OB80_OB_NUM:
Bit 0 gesetzt::
:Bit 7 gesetzt:
Bit 8 bis 15: abgelaufener Uhrzeitalarm durchUhrzeitsprungabgelaufener Uhrzeitalarm bei Wiedereintritt in RUN nach HALTFür den Uhrzeitalarm 0 liegt der Startzeitpunkt in der VergangenheitFür den Uhrzeitalarm 7 liegt der Startzeitpunkt in der Vergangenheitnicht verwendetnicht verwendetnicht verwendetnicht verwendetnicht verwendet
B#16#07
Bedeutung der Parameter siehe Fehlercode B#16#02. Überlauf des OB-Anforderungspuffers für die aktuelle Prioritätsklasse
(Jede OB-Startanforderung für eine Prioritätsklasse wird in den zugehörigen OB-Anforderungspuffer eingetragen; nach Beendigung des OB wird der Eintrag wieder gelöscht. Falls für eine Prioritätsklasse mehr OB-Startanforderungen vorliegen als die maximal mögliche Anzahl der Einträge im zugehörigen OB-Anforderungspuffer, wird der OB 80 mit dem Fehlercode B#16#07 aufgerufen.)
B#16#08
Bedeutung der Parameter siehe Fehlercode B#16#02. Taktsynchronalarm-Zeitfehler
B#16#09
Bedeutung der Parameter siehe Fehlercode B#16#02. Alarmverlust durch zu hohe Alarmlast
B#16#0AOB80_ERROR_INFO: Wiedereintritt in RUN nach CiRCiR-Synchronisationszeit in ms
B#16#0B OB80_ERR_EV_NUM:
OB80_OB_PRIORITY:
OB80_OB_NUM Technologiesynchronalarm-ZeitfehlerNummer des Ereignisses, das den Alarm ausgelöst hat: W#16#116APrioritätsklasse des OB, der bearbeitet wurde,
als der Fehler auftrat.Nummer des OB, der bearbeitet wurde, als der Fehler auftrat: 65

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bzw. evtl. könntest du in der regulären CPU Diagnose mal reinschauen, ob dort noch Informationen zum Stop auszulesen sind.

 

[Gelöschtes Mitglied 103809]

Hi DeltaMikeAir,

das etwas seltsame ist / war, der OB 80 war im AG und die CPU ist trotzdem in Stop gegangen. Ich habe heute zwar schon das Speichern der Lokalvariablen des OBs in einen DB eingefügt, allerdings sagen dir mal halt nicht an welcher Stelle im Programm, sprich in welchem Baustein, der Fehler passiert ist. Daher die Frage, wie ich den B-Stack in den DB-Kriege. Natürlich habe ich in die Diagnose geguckt, es gibt keinen weiteren Eintrag sondern nur OB80 mit 151ms aufgerufen, Ereignis-ID w#16#3501: Verursacher neues Ereignis: Laufendes OB1-Startereignis (Abschluss des freien Zyklus) für OB: Zyklisches Programm (OB 1) in Prioritäsklasse: 1. Ich mein eine CPU geht z.B. auch in Stop wenn ma neine Endlosschleife programmiert, auch wenn der OB80 im AG ist.

 

[DeltaMikeAir]

das etwas seltsame ist / war, der OB 80 war im AG und die CPU ist trotzdem in Stop gegangen.

Aus der OB80 Hilfe:

Hinweis
Wenn der OB 80 in demselben Zyklus zweimal aufgrund der Zykluszeitüberschreitung aufgerufen wird,
geht die CPU in STOP. Sie können dies durch Aufruf der SFC 43 "RE_TRIGR" an geeigneter Stelle verhindern.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

B-Stack und U-Stack kann man meines Wissens generell nicht im RUN auslesen. Und im STOP gehts nur mit PG.

Wenn Du den OB80 online löschst, dann wird bei S7-400 ein Diagnosepuffer-Eintrag erzeugt (STOP wg. OB nicht geladen) mit der Unterbrechungsstelle (Baustein + Adresse + "Gehe zu"-Button).
Wenn der OB80 vorhanden ist, dann bekommt man keine Info zur Unterbrechungsstelle. Der OB80 liefert leider keine Infos zur Unterbrechungsstelle.

Harald

 

[Heinileini]

Besonders spannend wird es, wenn die Steuerung nicht an der verursachenden Problemstelle in Stopp geht, sondern erst ms später.
Gibt's nicht? Doch, wenn die Ursache z.B. keine EndlosSchleife, sondern eine Schleife ist, die sporadisch wesentlich mehr Durchläufe als üblich ausführt und erst danach, im weiteren Verlauf des OB1, die ZyklusZeit überschritten wird.
Muss aber keine Schleife sein. Vielleicht gibt es verschiedene "ProgrammZweige" (z.B. bedingte Aufrufe von Bausteinen), die vermeintlich nie im selben Zyklus durchlaufen werden, sporadisch aber eben doch.
Auch z.B. mehrere (Zeit-)AlarmBearbeitungen können dazu führen, wenn sie sich gelegentlich in einem OB1-Zyklus häufen.

Fazit: Selbst wenn es gelingt den B-Stack im "richtigen" Augenblick auszulesen und abzuspeichern, muss darin noch lange nicht die Ursache der ZyklusZeitÜberschreitung zu finden sein.

 

[Gelöschtes Mitglied 103809]

Hi,

also Haralds Vorschlag habe ich erstmal mit der Produktion abgesprochen und werde ich so umsetzen. Aktuell habe ich keine Anhaltsstelle, wo im Programm ich überhaupt gucken muss. Gibt es denn eine Best-Practice Lösung zum Vorgehen, um bei einem sporadisch (alle 3 Monate) auftretender Zyklusüberschreitung rauszubekommen, wer der / die Verursacher sein können?

Was haltet ihr davon, in jedem Netzwerk in OB1 die Uhrzeit wegzuspeichern? Das würde mich zwar Laufzeit kosten, aber dann hätte ich einen Ansatz.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gibt es denn eine Best-Practice Lösung zum Vorgehen

Welche Programmiersprache?


Wenn z.B. SCL dann würde ich mir mal alle FOR Schleifen anschauen, vor allem die wo die Anfangs- und/oder Endwerte der Schleifen variabel
sind.

Bei AWL mal die Sprünge anschauen, vor allem natürlich die nach oben zurück springen...

 

[Heinileini]

Gibt es denn eine Best-Practice Lösung zum Vorgehen, um bei einem sporadisch (alle 3 Monate) auftretender Zyklusüberschreitung rauszubekommen, wer der / die Verursacher sein können?

Was haltet ihr davon, in jedem Netzwerk in OB1 die Uhrzeit wegzuspeichern? Das würde mich zwar Laufzeit kosten, aber dann hätte ich einen Ansatz.

Bedeutet "sporadisch (alle 3 Monate)" ...
- ganz selten, aber doch sehr regelmässig alle 3 Monate?
- ganz selten, ca. 4 mal pro Jahr?
In welcher Sprache ist das Programm geschrieben?
Wird in dem Programm mit ...
- (Zeit)-AlarmBearbeitung
- bedingten BausteinAufrufen
- mit "Überspringen" von zeitraubenden Passagen
- Schleifen, deren Anzahl Durchläufe Daten-abhängig stark schwanken
... gearbeitet?
Gibt es einen Zusammenhang zum 3-Monate-Rhythmus (macht der BetriebsArzt seine QuartalsAbrechnung auf der SPS)?

Kenne Deinen OB1 nicht - um wie viele Netzwerke geht es?
Falls AlarmBearbeitungen vorhanden sind, würde ich hier ansetzen. Aber die Erweiterungen zum Testen könnten natürlich leicht zu einer weiteren Ursache von ZyklusZeitÜberschreitungen werden.
Vllt am Anfang von OB1 die TestDaten löschen und am Ende des OB1 die TestDaten in RingPuffer schreiben.
TestDaten: Für jeden Alarm ein eigenes Bit setzen bzw. einen eigenen Zähler (DW) inkrementieren.

 

[Heinileini]

Wenn z.B. SCL dann würde ich mir mal alle FOR Schleifen anschauen, vor allem die wo die Anfangs- und/oder Endwerte der Schleifen variabel
sind.

WHILE-Schleifen sind eigentlich noch verdächtiger, insbesondere, wenn sich das EndeKriterium nicht auf einen SchleifenZähler bezieht.
Dazu gehören allerdings auch die FOR-Schleifen, die sich darauf verlassen, dass sie im NormalFall vorzeitig durch EXIT abgebrochen, aber sporadisch doch bis zum bitteren Ende durchlaufen werden.

 

[Gelöschtes Mitglied 103809]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hey,

also wie soll ich das sagen, einmal alle 3 Monate fällt die SPS damit aus. Die ist bis auf einige Ausnahmen komplett in FUP programmiert. Wir benutzen Weckalarme zum regeln und steuern der Antriebe. Ich hab mir mal die Zykluszeit des OB1 aufs Messwerterfassungsystem gelegt. Das einzige was etwas auffällig ist der SQL4Automation teil, aber selbst da geht er von 25 auf 35ms hoch. Der Teil wurde aber beim letzten Ausfall nicht bearbeitet zu diesen Zeitpunkt.

 

[Heinileini]

also wie soll ich das sagen, einmal alle 3 Monate fällt die SPS damit aus.
Wir benutzen Weckalarme zum regeln und steuern der Antriebe.
Das einzige was etwas auffällig ist der SQL4Automation teil, ...

- Also ziemlich definitiv alle 3 Monate? Gibt's irgendwas Datums-abhängiges? Umstellung der Produktion? WartungsArbeiten? Rücksetzen von Zählern, um Überläufen zuvorzukommen? ...?
- Wieviele verschiedene WeckAlarme? Welche ZeitAbstände jeweils?
- SQL4Automation klingt so nach Zugriff auf DatenBank. Das hat doch hoffentlich nicht jemand programmiert, der vor lauter HochSprachenProgrammierung alle Rücksicht auf ZyklusZeit vergessen hat?

 

[Gelöschtes Mitglied 103809]

Hey,

es war diesmal nach Stillstand bzw. Wartung. Aber obs die anderne Male war, kann ich dir nicht sagen. 3 Weckalamre 50, 25 und 10 ms, aber nur der 50ms wird benutzt. SQL4a Schnittstelle hab ich programmiert und läuft auch an anderne Anlagen und hat in 4 Jahren noch keine Probleme an diesen verursacht.

Es isst "gefühlt" alle 3 Monate laut Aussage Betreiber, ob das wirklcih auf den Tag so hinkommt kann ich dir nicht sagen. Aber Wartung an der Anlage ist alle 2 Wochen.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hey,

es war diesmal nach Stillstand bzw. Wartung. Aber obs die anderne Male war, kann ich dir nicht sagen. 3 Weckalamre 50, 25 und 10 ms, aber nur der 50ms wird benutzt. SQL4a Schnittstelle hab ich programmiert und läuft auch an anderne Anlagen und hat in 4 Jahren noch keine Probleme an diesen verursacht.

D.h. es sind Weckalarme projektiert und die OBs sind auch in der SPS vorhanden, aber leer? Wie sind die Prioritäten der Weckalarme eingestellt?

 

[Heinileini]

Hmmm, also nichts "Naheliegendes", was in Frage käme.
In grauer Vorzeit (S5) habe ich mir mal einen Wolf gesucht, aber die Ursache mit "FernWirkung" dann doch gefunden. Durch einen ParametrierFehler wurde sporadisch MB0 (oder MW0 oder MD0?) "zerschossen" und somit M0.0 gesetzt oder M0.1 gelöscht, also einer oder beide der SystemMerker DefNull und DefEins unzulässigerweise verändert. Das führte auf Umwegen zu reichlich mehr SchleifenDurchläufen an einer völlig unverdächtigen, bewährten ProgrammStelle.
Warum ich das erwähne? Mir fällt nichts besseres ein.
Also doch die LaufZeiten der OB1-NetzWerke messen und ... abwarten. Wenn sich der Fehler nicht so selten bemerkbar machen würde, würde ich "binäres Suchen" vorschlagen, um die Anzahl der Eingriffe in OB1 geringzuhalten: Zeit für die erste und die zweite "Hälfte" von OB1 messen. Wenn ermittelt ist, welche der Hälften zu lahm ist, diese dann wieder in zwei Hälften teilen und wieder für nur diese beiden die Zeiten messen, u.s.w. ...
Oder bzw. zusätzlich in jedem OB1-Netzwerk die NetzWerkNr in ein und dieselbe Variable schreiben, dann kannst Du ablesen, bis zu welchem NetzWerk sich das Programm vor Auftreten der ZeitÜberschreitung durcharbeiten konnte.
Good luck!

 

[Gelöschtes Mitglied 103809]

Hi,

also es sind 4 Weckalarme projektiert 200ms, 100ms, 50ms, 10 ms mit den Prioritäten 11 - 14. In den 200ms und 100ms sind nur ein jeweils 1 PID Regler, 50 ms sind die n-soll / m-soll Vorgaben für 7 Antriebe und 10 ms ist leer bis auf

TAR1
T #Retten_AR1

l #Retten_AR1
LAR1

Warum die überhaupt das Adressregister retten wollen ist mir nicht ganz klar, weiß das einer von euch?

Weiterhin habe ich OB80 jetzt gelöscht - ich habe das Programm mal überfolgen, habe jetzt aber keine Sachen gefunden die Aussehen wie Schleifen. Vllt. sollte ich jetzt einfach warten bis zum nächsten Ausfall ohne OB80 im AG?

P.S. Da fällt mir noch ein, ich habe vor ca. 4-5 Monaten eine Uhrzeitsynchronisation über NTP auf der CP hinzugefügt, die als Master für die CPU fungiert. Kann eine fehlerhafte Uhrzeitsynchronisation zu einem Mehrfachaufruf von OB80 führen?

P.P.S. Ich hab mal geguckt, ob wirklich die Merker für Logisch 1 oder 0 mehrfach geschrieben werden, ist laut Referenztabelle aber nicht der Fall.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Clyde82,

tritt denn der Fehler erst seit dem Hinzufügen der Uhrzeitsynchronisation über NTP auf? Da Du angibst, dass Du das vor 4-5 Monaten eingespielt hast, wie kommt man auf die 3 Monate, nach denen (regelmäßig?) der Fehler auftritt?

Das AR1 (bei Bedarf auch das AR2) rettet man, wenn man es innerhalb eines Bausteins manipuliert um mit indirekter Adressierung zu arbeiten. Wenn kein Code dazwischen steht, ist es hinfällig. Dann kann auch der ganze Baustein (inkl. Aufruf) gelöscht werden.

VG

MFreiberger

 

[PN/DP]

Warum die überhaupt das Adressregister retten wollen ist mir nicht ganz klar, weiß das einer von euch?

Vermutlich, weil die das "schon immer" so machen, oder aus Angst/Unkenntnis, oder für Portierbarkeit des Codes? In der S7-400 ist das unnötig, egal ob Code dazwischen steht oder nicht.

Harald

 

[MFreiberger]

Moin PN/DP,

Achtung: offtopic!

Vermutlich, weil die das "schon immer" so machen, oder aus Angst/Unkenntnis, oder für Portierbarkeit des Codes? In der S7-400 ist das unnötig, egal ob Code dazwischen steht oder nicht.

Harald

Warum ist das in der S7-400 unnötig (ich hatte bisher nur S7-300 aus der Classic-Welt in den Fingern)?

VG

Mario