Step 7 B-Stack auslesen bei Zykluszeitfehler OB80

  • Ersteller Ersteller Gelöschtes Mitglied 103809
  • Erstellt am Erstellt am
Zuviel Werbung?
-> Hier kostenlos registrieren
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?

Wenn du die SPS-Uhrzeit stellst und Interrupt-OBs vorhanden sind muss damit gerechnet werden, dass der OB80 aufgerufen wird. Allerdings steht das entsprechende Ereignis dann im Diagnosepuffer (sinngemäß: aufgerufen wegen Uhrzeitsprung). Vielleicht kommt es dann zu einem weiteren Ereignis wenn weitere Interrupts aufgerufen werden, je nach Priorität. Ich würde auf jeden Fall einmal den 10ms OB herausnehmen wenn er nicht benötigt wird.
 

Warum ist das in der S7-400 unnötig (ich hatte bisher nur S7-300 aus der Classic-Welt in den Fingern)?
S7-400 habe ich geschrieben, weil der TE eine S7-400 verwendet. Das Retten ist aber auch in der S7-300 unnötig.

Wenn ein OB ein Programm unterbricht, dann werden AR1 und AR2 und die DB-Register und die Akkus und die Status-Flags automatisch gerettet und danach wieder hergestellt. Der OB kann mit den Registern anstellen was er will und muß keine Werte wiederherstellen - deshalb muß auch nichts selber gerettet werden.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kann eine fehlerhafte Uhrzeitsynchronisation zu einem Mehrfachaufruf von OB80 führen?
Glaube ich eher nicht. Ein zweiter Aufruf des OB80 passiert ja erst, wenn die doppelte zulässige Zykluszeit überschritten wird - hier > 300ms (zehnfache normale Zykluszeit!). Da glaube ich auch nicht an ein unglückliches Zusammentreffen von Ereignissen, sondern vermute sehr eine zu lange laufende Programmschleife.

Harald
 
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.
Das heisst, Du ordnest jedem Netzwerk eine Variable zu und es wird etwas unübersichtlich, die ganzen Differenzen zu bilden und auszuwerten.
Über wie viele OB1-Netzwerke reden wir denn hier?
Einfacher finde ich, am Anfang jedes Netzwerks die jeweilige NetzwerkNr in immer dieselbe Variable abzuspeichern (und am Ende des letzten Netzwerks eine 0). Daraus kannst Du zwar nicht ermitteln, in welchem Netzwerk wie viele ms verbraten wurden, aber Du siehst auf einen Blick (ohne "decodieren" zu müssen) in welchem Netzwerk die ZyklusZeitÜberwachung "zugeschlagen" hat und kannst die noch nicht bearbeiteten Netzwerke bei der Suche nach der Ursache ausschliessen.

Wenn die Ursache allerdings in der AlarmBearbeitung liegt, hilft das auch nicht.
Ich denke, ich würde für jeden WeckAlarm-OB zwei Variablen spendieren:
- einen "Zähler", der bei jedem Aufruf des OB inkrementiert wird und
- einen SpeicherPlatz, wo der OB die aktuelle NetzwerkNr des OB1 hin kopiert.
Das setzt die o.g. Mimik im OB1 voraus und der OB1 müsste zusätzlich im 1. Netzwerk diese Variablen der WeckAlarm-OBs löschen.

PS:
vielleicht besser: im letzten Netzwerk des OB1 die WeckAlarm-TestVariablen löschen, dort wo der OB1 seine NetzwerkNr löscht.
 
Zuletzt bearbeitet:
Hi,

ich hab mich für folgende Lösung entschieden:
- Der OB1 hat 39 Netzwerke, daher habe ich in einem DB ein Array[2..39] of time angelegt
- Mittels Time_TCK ermittle im Netzwerk 1 des OB1 die Uhrzeit basierend auf dem internen Zähler der CPU 0 - 2147483647 und speichere diese in eine Startzeitvariable
- weiterhin im Netzwerk 1 setze ich das das Array[2..39] auf T#0ms
- Dann habe ich mir einen kleinen FC programmiert, der wenn er aufgerufen wird wieder Time_TCK benutzt und dann die relative Differenz zu Startzeitvariable bildet und diese in das Array[2..39] für das jeweilige Netzwerk schreibt
- Ich fange in dem FC den Überlauf des TIME_TCK ab, der ca. alle 28 Tage passiert
- dann habe ich die Zeiten aus dem Array[2..39] aufs Messwerterfassungssystem gepackt

Dahingehend habe ich für die Zukunft folgende Diagnosemöglichkeiten beim CPU Stop durch Zykluszeitüberschreitung:
- Ich sehe im Array, wie weit der OB1 überhaupt bearbeitet wurde
- Anhand des Messwerterfassungssystems kann ich die Zeiten vergleichen und schlussfolgern ob eventuell nicht das letzte Netzwerk sonderns eins davor bereits die Zykluszeit unnötig hochgetrieben hat

Damit sollte es mir zukünftig möglich sein rauszukriegen, wo der Fehler herkommt. Ich habe weiterhin mal nachgeschaut, ob diese zusätzlichen Aufrufe meine Gesamtzykluszeit hochtreiben, aber die SPS rennt bei 22ms daher, wie vor der Änderung.

P.S. OB80 und den nicht benutzten 10ms Weckalarm habe ich Off- und Online entfernt.
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben