Step 7 OB35 - Zeitüberschreitung

SPS_NEU

Level-2
Beiträge
567
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Gemeinde,

ich habe hier eine Lageregelung, welche über eine ET200s (6ES7 151-8AB00-0AB0) geregelt wird. Das ganz wird im OB35 (2ms) abgearbeitet. Die SF-LED bzw. die Online-Diagnose sagt, dass es einen OB-Anforderungsfehler (Taktgenerator 6) gibt.
Wie bekomme ich raus, wie die tatsächliche Abarbeitungszeit des OB35 ist, wenn diese überschritten wird?
 
Behafte mich darauf, aber das müsste aus den Statusinfos des OB 80 herauslesbar sein. (Wenn der OB80 nicht geladen ist, geht die CPU in Stop wenn die Bearbeitungszeit des OB35 länger wie die Taktzeit ist)
 
Probiere doch einfach mal die Holzhammer Methode.
OB35 Aufruf schrittweise um 1ms erhöhen und schauen wann die SF LED nicht mehr kommt ;)
 
In der Schnittstelle. In der Hilfe wird das ausführlich beschrieben.
OB80_FLT_ID informiert dich über die Art des Fehlers.
OB80_ERROR_INFO liefert dir dann weitere informationen. z.B. eben Zykluszeit. Muss aber je nach ID entsprechend ausgewertet werden.

Ich sags dir jetzt schon, so ganz Trivial ist die Sache nicht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie bekomme ich raus, wie die tatsächliche Abarbeitungszeit des OB35 ist, wenn diese überschritten wird?
Geht die CPU in STOP? Dann kommt als Ergebnis die Zeit der Aufruffrequenz raus - die Info nützt also nichts.

Wird der OB35 trotz Intervall-Überschreitung bis zum Ende abgearbeitet? Dann kannst Du am Anfang und am Ende des OB35 den SFC64 TIME_TCK aufrufen und die Differenz des Systemzeitzählers auswerten.

Testweise kannst Du auch die Aufruffrequenz verringern (größere Aufruf-Zeit einstellen, z.B. 10ms ) und mit SFC64 TIME_TCK die Differenz des Systemzeitzählers auswerten.
Oder testweise den Programmcode in den OB1 kopieren und da die Zeitmessung mit SFC64 machen.

(die IM151-8 hat keinen SFC78 OB_RT)

Harald
 
Oha - leider kann ich dir nicht folgen. Wo finde ich die Schnittstelle. Der OB80 wird ja nicht aufgerufen wie eine normale Funktion....
Bzw. wo finde ich die Hilfe zu OB80?
 
ja die Beschreibung hab ich. Aber wo kann ich die Informationen dann her nehmen. Gibt es ein einfaches Beispiel?

Da dies nicht so eine triviale alltägliche Sache ist, dürfte es da kein einfaches Beispiel geben.
So wird z.B. die Schnittstelle eines OBs abgefragt:
Code:
ORGANIZATION_BLOCK "CYCL_FLT"
TITLE = "Cycle Time Fault"
{ S7_Optimized_Access := 'FALSE' }
VERSION : 0.1
   VAR_TEMP 
      OB80_EV_CLASS : Byte;   // 16#35, Event class 3, Entering event state, Internal fault event
      OB80_FLT_ID : Byte;   // 16#XX, Fault identifcation code
      OB80_PRIORITY : Byte;   // Priority of OB Execution
      OB80_OB_NUMBR : Byte;   // 80 (Organization block 80, OB80)
      OB80_RESERVED_1 : Byte;   // Reserved for system
      OB80_RESERVED_2 : Byte;   // Reserved for system
      OB80_ERROR_INFO : Word;   // Error information on event
      OB80_ERR_EV_CLASS : Byte;   // Class of event causing error
      OB80_ERR_EV_NUM : Byte;   // Number of event causing error
      OB80_OB_PRIORITY : Byte;   // Priority of OB causing error
      OB80_OB_NUM : Byte;   // Number of OB causing error
      OB80_DATE_TIME : Date_And_Time;   // Date and time OB80 started
      lastzycl : Int;
      lastOB : Int;
   END_VAR




BEGIN
	CASE BYTE_TO_INT(#OB80_FLT_ID) OF
	    1: // Zykluszeit überschritten
	        // info über letzte zykluszeit lesen
	        #lastzycl := WORD_TO_INT(#OB80_ERROR_INFO);
	        #lastOB := #OB80_OB_NUM;
	    2: // OB überlappung z.B. OB35 läuft noch, ob 35 wird aufgerufen
	        #lastzycl := 0; // da ob nicht abgeschlossen, keine Zyklusinfo möglich
	        #lastOB := #OB80_OB_NUM;
	        
	        
	        
	END_CASE;
END_ORGANIZATION_BLOCK

Bei dir würde es aber reichen wenn der OB80 leer vorhanden ist, damit die CPU nicht in Stop geht. Und du in deinem Weckalarm die Zykluszeit misst so wie in Beitrag 6 von PN/DP beschrieben.

Das nicht so triviale kommt jetzt. Da ein ob der nicht aufgerufen werden konnte (weil derselbe schon läuft) verzögert aufgerufen wird. Wird der verzögerte Aufruf deine Zyklusaufzeichnung dann zerschiessen.
Das heisst in OB80 könntest du ein Bit setzen das seine Ausführung anzeigt und im nächsten Aufruf des Weckalarms dieses Bit abfragen und neue Zyklusmessungen in einem anderen speicherbereich ablegen oder die CPU in Stop überführen.

mfG René
 
Ich hab das jetzt etwas leichter gelöst:
ich zähle einfach einen INT-Wert am Ende des OB35 mit jedem Durchlauf hoch. Nach 1s übergebe ich denn Wert in lass von neuem Zählen. 1000ms teile ich dann durch den gezählten Wert und hab die Zeit desn OB35. Funktioniert super
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Funktioniert super
Ist nur ziemlich nutzloser Aufwand... Laß mich raten, da kommt raus: 2ms :cool:

Das was Du da jetzt zählst ist wie oft je Sekunde bzw. in welchem Zeitabstand der OB35 aufgerufen wird (was in HW Konfig eingestellt ist) abzüglich der übersprungenen Aufrufversuche. Das ist keine Information wie lange der OB35 für die Abarbeitung braucht.

In welchem Zeitabstand der OB35 aufgerufen wird kann man auch ganz einfach aus #OB35_EXC_FREQ auslesen.
Ob ein Aufruf übersprungen wurde könnte man durch Auswertung von #OB35_DATE_TIME rauskriegen (oder mit dem OB80 wie vollmi gezeigt hat).

Harald
 
Ja, aber ich gehe mal davon aus, dass falls die Abarbeitung nicht in 2ms geschafft wird, ein anderer Wert entsteht.

Wie und Wo lese ich : #OB35_EXC_FREQ aus??
 
Wenn bei Deiner einfachen Zähllösung der OB35 499 mal in 0.5ms oder 1.0ms oder 1.9ms abgearbeitet wurde und einmal 3ms gebraucht hat, dann wird das in Deinem Rechenergebnis nicht annähernd zu erkennen sein. Und wenn er 500 mal fehlerfrei in 0.5ms abgearbeitet wurde, dann wird Deine Berechnung 2ms ergeben. Also alles weit weg von der Realität.

#OB35_EXC_FREQ ist eine temporäre Lokaldatenvariable des OB35, zu finden in der Deklaration der TEMP-Variablen an der Adresse 10.0 (das LW10)

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
.. ich habe hier eine Lageregelung, welche über eine ET200s (6ES7 151-8AB00-0AB0) geregelt wird. Das ganz wird im OB35 (2ms) abgearbeitet. ..
Ob eine Bearbeitung im 2ms-Task überhaupt sinnvoll ist, ist natürlich eine ganz andere Frage. Ich wollts nur mal angesprochen haben :cool: .
 
@Harald:
Bist du denn der Meinung (ich weiß es selber nicht), dass die von dir genannte Variable da weiterhilft ? Die wird am Ende ja auch nichts anderes aussagen.

@TE:
Es gibt Zeitangaben über Laufzeiten von Befehlen bei der jeweiligen CPU. Es würde dich m.E. der Wahrheit sehr viel näher bringen wenn du vom OB35-Code die Zeiten der verwendeten Einzelbefehle addierst.
Ansonsten in Anlehnung an den Beitrag von Onkel Dagobert : ich habe schon bei kleinen CPU's OB35-Intervall in dem Raster umgesetzt. Das klappt dann wunderbar wenn wirklich nur der Code im OB35 drin ist, der zeitkritisch bearbeitet werden muss. Nicht-zeitkritische Sachen, wie z.B. eine wie auch immer geartete Auswertung einfach im zyklischen Programm machen. Das setzt allerdings ein bißchen Disziplin voraus ...

Gruß
Larry
 
Die Variable #OB35_EXC_FREQ wird dem TE bei seinem Problem nicht weiterhelfen - ich hatte sie lediglich erwähnt, weil da einfach schon drinsteht was er unnötigerweise errechnet (solange der OB35 immer vor dem nächsten Aufruf fertig wird).
Sein einfacher Rechenweg als Problem"lösung" ist allerdings völlig untauglich zur Lösung seines Problems:
Wie bekomme ich raus, wie die tatsächliche Abarbeitungszeit des OB35 ist, wenn diese überschritten wird?
Dafür muß man nicht zählen wie oft der OB aufgerufen wurde sondern muß die Laufzeit der Anweisungen vom Beginn des OB bis zu seinem Ende messen (habe ich schon in #6 erklärt).

Harald
 
Zurück
Oben