Problem mit Lokaldaten

tobi221081

Level-1
Beiträge
27
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute...

Ich kämpfe gerade mit einem Problem und taste mich nun langsam zur Ursache vor. Ich hoffe einer von euch kann mir helfen oder mich eventuell auf eine neue Spur bringen.

Ich habe einen FB geschrieben, welcher sehr viele Lokaldaten (>500Byte) besitzt. Nun rufe ich meinen FB im OB1 auf. Ebenfalls wird die selbe Instanz im OB35 aufgerufen obwohl er dort keinerlei Funktion ausführt.

OB1 OB35
CALL FB11,DB99 CALL FB11,DB99
meine parameter identischer parametersatz

(Der Hinweis den FB nicht im OB35 aufzurufen, wenn er dort keinerlei Funktion ausführt bringt nicht die Lösung => Der Grund warum mein Baustein im OB1 und OB35 liegt ist, dass wenn ich ihn in einem CFC einbaue er standardmaßig auf OB35 gelegt wird. Der zusätzlich Einbau in OB1 wird über das Attribut S7_tasklist erreicht. Der Aufruf in OB35 ist quasi "ohne nutzen". Ich möchte dem Kunden nur ersparen den Baustein dort löschen zu müssen. Das Problem ist aber nicht PCS7-spezifisch. Ich erreiche das gleiche Verhalten bei reiner AWL-Programmierung.)

Wird der Baustein aus dem OB35 aufgerufen, erkennt er dieses und macht ein BE. (Diese Implementierung ist überprüft. Der Baustein steigt im OB35 wirklich aus.)


Arbeitet mein Baustein nun in einem OB1-Zyklus und wird durch den OB35 unterbrochen treten beim fortführen des OB1 Zykluses Fehler auf und das immer an Stellen wo mit Lokaldaten gearbeitet wird.

L XY
L AB
*I
SLD 3
LAR1
TAR1 TEMP0_DWORD

/*mach irgendwas anderes*/

LAR1 TEMP0_DWORD
L 5
T W[AR1,P#0.0]

Ich vermute das der Baustein im OB1-Zyklus an der Stelle "mach irgendwas anderes" unterbrochen wird. Danach will er die berechnete Adresse (TEMP0_DWORD) rekonstruieren und diese stimmt nicht mehr und ich hab den Salat. Kann das sein, dass ab einer gewissen Größe es Probleme bei der Rekonstruktion der Lokaldaten nach einem Weckalarm gibt?

Oder kann es sein das mein Programm nach LAR1 TEMP0_DWORD unterbrochen wird und das Adressregister (welches im OB35 auch geändert wird) nicht mit gesichert und zurückgeschrieben wird? Gravierende Fehler bei der algorithmischen Implementierung schließe ich (vorerst) aus, da keinerlei Probleme auftreten, wenn der Baustein nur im OB1 aufgerufen wird..

Gibt es eine Möglichkeit zu sehen an welcher Bausteinadresse für den OB35 unterbrochen wurde?

Das beschriebene Verhalten tritt bei vielen Steuerungssystemen sowohl aus der 300er- als auch der 400er-Serie auf.


Vielen Dank!
 
ich empfehle dir: sowohl AR1 und AR2 als auch den letzten offenen global-DB zu retten und nach bearbeitung wieder herzustellen ... das löst erstmal das adressregister verschiebe...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hey hallo, vielen Dank für so eine schnelle Antwort. :TOOL:

Das Problem ist nur, dass der OB1 halt durch einen Weckalarm unterbrochen wird. Innerhalb meines Bausteines im OB1-Zyklus kann ich also nichts retten, da ich ja nicht absehen kann wann genau der Weckalarm zuschlägt.

Im Baustein innerhalb des OB35 kann ich auch nichts retten, denn ich weiß nicht was der Kunde innerhalb des OB35 "oberhalb" meines Bausteinaufrufes projektiert.
 
Um auszuschliessen, dass ich einem fatalen Denkfehler aufsitze, möchte ich noch folgendes abklären.

Wird mein Baustein im OB1 an der Codezeil X durch den Weckalarm unterbrochen so wird nach der Bearbeitung des Weckalarms an der Codezeile X+1 und nicht am Anfang fortgefahren.

Stimmt doch oder?
 
Es gibt noch den SFC39/40. Mit dem kann man die Weckalarme abschalten und auch wieder einschalten.

Bei einer S7-300 ist sicherzustellen, daß ein bestimmter Programmteil nicht durch einen Weckalarm (OB-35-Aufruf) unterbrochen wird. Eventuell auftretende Weckalarme sollen nicht nachgeholt werden.

Wenn du in deinem FB als erstes die Weckalarme sperrst und am Ende wieder zuschaltest oder dies im OB1 vor und nach dem FB tust,würde dieser nicht mehr unterbrochen werden. Ein Versuch ist es sicher Wert.
 
Hallo,
was heißt bei dir "Lokaldaten" ? Daten im STAT-Bereich des FB oder eventuell welche im TEMP-Bereich ?

Ganz grundsätzlich kann man das machen, was du da tust (ich mache das z.B. bei meinen Kurven-FB's so). Du mußt nur beachten, dass wenn der Aufruf im OB35 etwas ganz anderes macht wie der im OB1, dass du trotzdem ggf. Beeinflussungen verriegeln mußt.

Gruß
LL
 
Hallo Ralle, hallo vierlagig.

Also erstmal ein fettes "bin begeistert" an dieses Forum. Die Kommunikation läuft ja fast wie in Echtzeit. :-D

@Ralle:
Mit dem Sperren von Alarmen hantier ich gerade rum. Bin gespannt ob der Fehler dann immernoch auftritt. Trotzdem ist dies keine Endlösung.
Mein Baustein ist halt ein Treiber mit dem der Kunde machen kann, was er gern möchte. Und da wäre es fatal wenn der Treiber grundsätzlich Alarme abschaltet oder zumindest um seine Bearbeitungszeit verzögert.

@vierlagig:
Da es sich bei dem Baustein um einen Treiber handelt und nicht "fest zu einem Projekt" gehört, hab ich grundsätzlich nur Einfluss auf den Code innerhalb des Bausteines. Der Kunde kann dann später seine OBs wie wild drum rum projektieren. Deswegen hab ich keinen Einfluss auf die Netzwerke innerhalb des OB35.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Larry :) (Das Spiel hab ich auch schon zu 486er Zeiten gezockt.)

Ich meine mit Lokaldaten die im TEMP-Bereich. Eine Verriegelung findet auch schon statt. Sobald mein FB merkt, dass er im OB35 liegt macht er ein BE.

Die Implementierung der Verrieglung ist überprüft und funktioniert. Trotz Verriegelung bleibt das Problem bestehen.
 
Zuletzt bearbeitet:
... dann haben wir da den Fehler ...
Der TEMP-Bereich wird von einem Zyklus zum nächsten NICHT gesichert. Wenn du also nicht alles im TEMP-Bereich zunächst zuweisst, dann könnte das schon der Grund sein ...

Gruß
LL
 
Hallo Larry,

das ist mir schon klar. Daran liegt es auch nicht.
Bei einem Aufruf meines Bausteins wird immer genau 1 Zustand des Zustandsmodells abgearbeitet. Innerhalb eines Zustandes wird dann nur mit Lokaldaten gerechnet die vorher geschrieben also einen gültigen Wert haben.


Wird nun durch den Weckalarm im OB1-Zyklus an der Codestelle X unterbrochen müßten doch alle Lokaldaten gesichert werden. Der Weckalarm wird verarbeitet. (Innerhalb meines Aufrufes in OB35 wird dann gesperrt nicht das der selbe Zustand nochmal durchlaufen wird.)

Nach dem Weckalarm sollten doch die Lokaldaten wieder rekonstruiert werden und im OB1-Zyklus an der Codestelle X+1 fortgefahren werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
das ist mir schon klar. Daran liegt es auch nicht.
... das hört sich nach deiner Beschreibung aber genau danach an ...
Wie schon gesagt : Lokaldaten im TEMP-Bereich werden nirgendwo gesichert. Wenn nicht gezielt (in den Zeilen davor) zugewiesen, ist deren Inhalt zufällig. Ich würde das noch einmal genau checken. Wenn du etwas sicher "gemerkt" haben willst, so solltest du die Variablen einfach in den STAT-Bereich rüberschieben - zumindestens würde ich das vielleicht einmal ausprobieren ...

Gruß
LL
 
Sicher?

Ich will das bezweifeln. Über einen OB1-Zylus wird nichts gerettet. Ganz klar! Aber der OB1 Zyklus wird ja nur unterbrochen und danach fortgeführt.

Dagegen spricht auch, dass wenn ich OB35 nur so aufrufe und dort ein wenig rumrechne kein Fehler auftritt obwohl der OB1-Zyklus dann genauso unterbrochen wird und mit "unsicheren Lokaldaten" weitergerechnet wird. Der Fehler tritt nur auf wenn ich exakt die selbe Instanz meines Bausteines nochmal aufrufe. Ruf ich zum Beispiel eine andere Instanz auf gibts keine Fehler...
 
...also ich würde meinen vorredner ersteinmal recht geben mit den Lokaldaten...rufst du eigendlich deinen FB im OB1 auf, unterbrichst mitten im FB durch den OB35 und rufst dann im OB35 den FB mit gleicher instanz erneut auf...oder wie muß mann deine ausagen verstehen....?

gruß Helmut
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hey hallo, ja genau so.

Warum ich das mache, habe ich versucht in den vorherigen Beiträgen zu erklären. Ich mach das nicht "absichtlich so". Aber ich muss Sorge dafür tragen, dass dieser Aufruf keine Probleme verursacht.

Damit es keine weiteren Probleme gibt weil ein Zustand innerhalb meines Bausteines durch den Weckalarm mehrfach abgearbeitet wird, sperrt sich mein Baustein im OB35 und macht ein BE. Beim Fortsetzen im OB1 Zykluses gehts dann schieff.
 
...aber wenn du im OB35 ein BE im entsprechenden FB machst, kann er doch nicht an der gleichen stelle im OB1 weiterarbeiten wie vorher.....:confused:
 
...und genau das lässt mich verzweiflen!

(Nochmal zum Verständnis ich mach natürlich nicht sofort BE im OB35.
Die selbe Instanz meines FBs wird aufgerufen. Diese merkt dann das sie im OB35 aufgerufen wurde und macht das BE.)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...ich weiß ja nicht, normal merkt sich doch die CPU wo sie den OB1 verlassen hat und springt an der selben stelle zurück wenn du aus einen anderen OB kommst...aber wenn du den FB mit der gleichen Instanz nocheinmal aufrufst...das würde ich mir nicht trauen, genauso wenig würde ich mich auf die Lokaldaten verlassen...die würde ich schon irgenwie retten wollen...

gruß helmut
 
...das mit den Lokaldaten wurde ja schon erläutert...wie es mit der Instanz ist kann ich ja nicht sagen vielleicht werden durch den erneuten aufruf Instanzdaten verändert die du an der Schnittstelle hast, dieses kann dann zu unerwünschten ergebnissen führen...
 
Zurück
Oben