Problem mit Lokaldaten

[tobi221081]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Helmut,

naja das die Lokaldaten zwischen 2 OB1-Zyklen ihre Gültigkeit verlieren ist ja wie gesagt klar. Das ist auch nicht der Fehler. Es scheint halt nur so, dass sie auch durch den Weckalarm ihre Gültigkeit verlieren.
Meine Stat. Var. also meine Instanzdaten sind nicht das Problem. Es ändert sich an denen auch gar nichts weil die Eingänge und Ausgänge im OB35 identisch beschalten sind.


Weißt du wie intern in der CPU "gleiche Instanzen" eines FBs gehandelt werden?

Ich drifte nun mal stark ab in das Reich der Mutmassungen.
Ich werde im OB1 Zyklus unterbrochen. Meine Lokaldaten werden gesichert. Ich befinde mich nun im OB35. Dort wird die selbe Instanz aufgerufen (gleiche Beschaltung, gleicher Instanzdb). Die CPU rekonstruiert (eventuell) jetzt schon die Lokaldaten und macht ihre Berechnungen. Ich kehre zurück in den OB1. Dort weiß die CPU dann eventuell nicht mehr was an Lokaldaten zu rekonstruieren ist und der Fehler geschieht.


Was mich zu der Annahme bringt: Wenn ich den InstanzDB ändere, dann passiert kein Fehler. (Das ändern des InstanzDBs ist natürlich keine Lösung, es zeigt jedoch, dass das Problem irgendwie verwirrend ist.)

 

[Ralle]

Woher nimmst du die Gewissheit, daß die Lokaldaten gesichert werden und wohin sollen die eigentlich gesichert werden? Die liegen auf dem Lokaldatenstack. Den benutzt jeder FC/FB, die Aufrufe sind ja immer linear, also wird er immer ab der letzten belgeten Stelle weiter aufgebaut, ist der FC/FB am Ende wird der Lokaldatenstack wieder kleiner. Hoffe ich liege da richtig. Irgendwo hab ich mal gelesen (ich find einfach nicht mehr, wo), daß man sich um einige Sachen selbst kümmern muß, wenn ein Weckalarm oder ein anderer Interrupt das laufende Programm unterbricht.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

...wie Ralle schon sagt woher weißt du das die Lokaldaten passen. Du weißt ja nicht wann dein OB35 aus deinem OB1 aufgerufen wird. Die Lokaldaten sind doch vielleicht viele schon durch andere FB/FC aufrufen mißbraucht bzw. verändert, also können Sie nicht mehr passen...Vielleicht kannst du ja auf einen Teil deiner Lokaldaten verzichten und speicherst die Werte im Instanzbaustein...?

 

[tobi221081]

Diese Frage hab ich mir auch gestellt.

Ich hab in meine alten Uni-Mitschriften geschaut und da stehts drin, dass der Lokaldatenstack gesichert wird. In den Siemens-Handbüchern hab ich dafür nichts gefunden.

Nun sind UNI-Profs natürlich nicht unfehlbar, obwohl sie gern den Anschein vermitteln. Was nun wenn diese Grundannahme falsch ist.

Ich habe das mal durchgetestet. Ich rufe im OB35 keinerlei Bausteine auf, sondern geh direkt an den Lokaldatenstack und schreib dort Mist rein.

Mit dem Ergebnis: Meine Adressberechnung geht auch schief.
Ein eindeutiges Indiez dafür, das der Stack überhaupt nicht gesichert wird.


Wenn mir nun einer eine Stelle in irgendeinem Handbuch nennen kann, wo steht "Achtung Lokaldatenstack wird nicht gesichert" dem spendier ich ein Eis. Wahlweise nen Grog weils draußen kalt ist.


!!!!Moment ich muss mich revidieren.!!!!
Ich schreibe Mist direkt Mist in die Lokaldaten. Und habe zur Fehlersuche auf OB121 getriggert. Der Grund warum der angesprungen ist, war das ich gar nicht soviele Lokaldaten für OB35 definiert hatte. Und hab immernoch das Problem.

(Noch ein Argument dafür das die Lokaldaten gesichert werden. Ich kann doch über den V-Bereich auf die vorherigen Lokaldaten zugreifen. Also scheint er doch für jeden FB/FC einen neuen Stack anzulegen. )

 

[rostiger Nagel]

frei aus dem Berger Burch:

Die temponären Lokaldaten verwenden Sie zur Zwischenspeicherung
von Ergebnissen, die während der Programmbearbeitung eines Bausteins
anfallen. Temponäre Lokaldaten stehen nur während der Bausteinbearbeitung
zur Verfügung, nach dem Beenden des Bausteins gehen
ihre Inhalte verloren.

Temponäre Lokaldaten sind Operanden, die im Lokaldaten-Stack (L-Stack)
im Systemspeicher der CPU liegen. Das Betriebssystem der Zentralbaugruppe
stellt die die temponären Lokaldaten für jeden Codebaustein bei dessen Aufruf zur Verfügung.
Die Werte im L-Stack sind beim Aufruf eines Baustein quasi zufällig.
Um die Lokaldaten sinnvoll zu nutzen zu können, müssen Sie sie vor dem Lesen erst beschreiben. Nach
dem Beenden des Bausteins wird der L-Stack dem nächsten Baustein
zugewiesen.

...eigendlich hat der OB35 auch Lokaldaten und somit ist der L-Stack bei dem aufruf des OB35 schon wieder verändert...oder...?

gruß Helmut

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also zu Lokaldaten hab ich bei Siemens erstmal nur das gefunden:

Lokaldaten
Die Lokaldaten speichern:
● die temporären Variablen von Code-Bausteinen
● die Startinformation der Organisationsbausteine
● Übergabeparameter
● Zwischenergebnisse
Temporäre Variablen
Beim Erstellen von Bausteinen können Sie temporäre Variablen (TEMP) deklarieren, die nur
während der Bearbeitung des Bausteins zur Verfügung stehen und dann wieder
überschrieben werden. Diese Lokaldaten haben pro OB eine feste Länge. Vor dem ersten
lesenden Zugriff müssen die Lokaldaten initialisiert werden. Außerdem benötigt jeder
Organisationsbaustein für seine Startinformation 20 Byte Lokaldaten. Der Zugriff auf
Lokaldaten erfolgt schneller als auf Daten in DBs.
Die CPU besitzt Speicher für die temporären Variablen (Lokaldaten) gerade bearbeiteter
Bausteine. Die Größe dieses Speicherbereichs ist CPU-abhängig. Er wird zu gleichen Teilen
unter den Prioritätsklassen aufgeteilt. Jede Prioritätsklasse verfügt über einen eigenen
Lokaldatenbereich.

VORSICHT
Alle temporären Variablen (TEMP) eines OB und seiner unterlagerten Bausteine werden in
den Lokaldaten gespeichert. Wenn Sie viele Schachtelungsebenen in Ihrer
Bausteinbearbeitung verwenden, kann der Lokaldatenbereich überlaufen.
CPUs wechseln in den Betriebszustand STOP, wenn Sie die zulässige Größe der
Lokaldaten einer Prioritätsklasse überschreiten.
Berücksichtigen Sie dabei den Lokaldatenbedarf von Synchronfehler-OBs, er wird jeweils
der verursachenden Prioritätsklasse zugeordnet.

Da steht erstmal nichts von gesichert.

Jeder neu aufgerufene Baustein stockt sich auf den L-Stack auf, ist er fertig, wird wieder L-Stack frei, der aufrufende Baustein ist somit wieder an der richtigen Stelle.

 

[Larry Laffer]

Hallo Tobi,
ich weiß aus schmerzlicher Eigenerfahrung, dass der Lokaldatenstack definitiv nicht gesichert wird. Das Einzige, was hier geht ist, wenn du nur einen FB- oder FC-Aufruf im Programm hast - dann funktioniert es. Sonst ist es genau so wie schon von Ralle beschrieben (ichh habe dazu aber auch keine Quelle).

Bezüglich der doppelten Aufrufe könntest du eine Re-Entry-Sperre programmieren. Am Anfang des Bausteins fragst du ab, ob das Bit "Baustein_Aktiv" gesetzt ist - wenn ja, dann Baustein-Ende. Sonst Bit setzen, Baustein bearbeiten und am Ende wieder Rücksetzen. Das funktioniert allerdings auch nur, wenn dieses Bit entweder ein Merker ist oder es im STAT-Bereich des FB definiert ist.

Trotz alledem frage ich mich, warum du den Versuch TEMP-Daten in STAT-Bereich verschieben nicht mal testest ... Du kannst doch dabei gar nicht verlieren - im schlimmsten Fall hast du Recht und das hilft auch nicht ...

Gruß
LL

Nachsatz:
Nun ist Dank Reparatur und Ralle das Thema Temp-Lokaldaten dann wohl geklärt ...

 

[Sarek]

Für jeden OB gibt es eine Prioritätsklasse auf dem L-Stack !
die Größe ist CPU-abhängig

d.h. z.B. es gibt OB1 und OB35

OB1 hat Prioklasse 1 und liegt als erstes auf dem L-Stack
aus dem OB1 wird ein FB100 aufgerufen, daraus ein FB200 ....

L-Stack sieht so aus: (aus Sicht der SPS im FB200)


L-Daten FB200
===========
L-Daten FB100
===========
L-Daten OB1


Wird jetzt der OB1-Zyklus von einem anderen Höherprioren OB z.B. OB35
unterbrochen wird auf dem L-Stack eine "neue Prioklasse" aufgemacht

z.B. OB1-Zykl. wird im FB200 unterbrochen vom OB35 der wieder FB100 => FB200 aufruft

L-Stack sieht so aus: (aus Sicht der SPS im FB200 (OB35-Zykl.))

L-Daten FB200 (OB35-Zykl.)
=====================
L-Daten FB100 (OB35-Zykl.)
=====================
L-Daten OB35
=====================
L-Daten FB200 (OB1-Zykl.)
=====================
L-Daten FB100 (OB1-Zykl.)
=====================
L-Daten OB1

Ich hoffe man kann genau sehen das man den L-Stack nicht sichern muß!!
Die "alten" Daten aus dem OB1-Zyklus sind ja weiter unten auf dem L-Stack noch vorhanden und werden auch wieder gültig sobald der OB35-Zyklus fertig ist.

auch Adressregister ... müssen AFAIK nicht gesichert werden, da sie an der Unterbrechungsstelle systemintern wiederhergestellt werden.

Wie Du weiter oben schreibts passiert der Fehler mit einem anderen IDB nicht.
Dies weist zu 100% darauf hin das etwas im IDB-Bereich passiert ist !!

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also zu Lokaldaten hab ich bei Siemens erstmal nur das gefunden:



Da steht erstmal nichts von gesichert.

Jeder Baustein stockt sich auf den L-Stack auf, ist er fertig, wird wieder L-Stack frei, der aufrufende Baustein ist somit wieder an der richtigen Stelle.

...das hatte ich auch noch irgendwie im sinn...

 

[Larry Laffer]

@Sarek:
Diese Sicherung gilt aber m.E. nur innerhalb des laufenden Zyklusses. Ich bezweifle, dass es von Zyklus zu Zyklus gilt ...

 

[tobi221081]

Kannst du mir mal den Titel des Siemens Handbuches geben?

Man kann den Text im Handbuch auch anders Interpretieren.
Der OB1 kriegt einen Stack A (Prioklasse X). Der Interuppt OB35 kriegt einen eigenen (Stack B Prioklasse Y). Nun führe ich meine Arbeit im OB1 fort. Kriege also wieder Stack A. Da dürfte sich ja irgendwie nichts daran geändert haben.

 

[Sarek]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Sarek:
Diese Sicherung gilt aber m.E. nur innerhalb des laufenden Zyklusses. Ich bezweifle, dass es von Zyklus zu Zyklus gilt ...

Natürlich gilt dies nur innerhalb eines Zykluses.

d.h. wenn ein Baustein abgearbeitet ist werden die L-Daten auf dem Stack wieder freigegeben.

Aber der Fehler hier geht ja davon aus das der OB35 in den L-Daten des
OB1 "herumpfuscht".
Das ist definitiv nicht möglich.

 

[vierlagig]

IMHO wird und darf der stack durch einen interrupt, was ja der aufruf des OB35 nun mal darstellt nicht verloren gehen. gar nicht auszudenken, was da alles passieren kann ...

ich zitiere aus der hilfe:

Der Lokaldaten-Stack wird zu gleichen Teilen unter den Prioritätsklassen aufgeteilt (Voreinstellung). Das bedeutet, jede Prioritätsklasse verfügt über einen eigenen Lokaldatenbereich. Damit ist gewährleistet, dass auch hochpriore Prioritätsklassen und ihre zugeordneten OBs Platz für ihre Lokaldaten zur Verfügung haben.

sehr schön zu dem thema: http://www.automation.siemens.com/WW/forum/guests/PostShow.aspx?language=de&PostID=116922 *kopfschüttel*

 

[Larry Laffer]

... das ändert dann aber gar nichts an dem Re-Entry-Problem ...

und eigentlich auch nicht an der anderen Sache ...

 

[tobi221081]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Larry: Da bin ich gerade dabei. Jedoch dauert das ne Weile bei dem Baustein (14k), weil sich durch die Verschiebung auch Code ändert.

Ich nehme zunehmenden an, dass die Verschiebung das einzigste Mittel sein wird um weitere noch unentdeckte Ungereimtheiten auszuschliessen.

Trotzdem: Wenn ich mir Sareks Beitrag ansehe... Mein OB35 bekommt den L-STACK aufgestockt und rechnet. Ist der OB35 fertig und es wird im OB1 fortgefahren liegt der Stack-Pointer ja wieder richtig...was ja quasi einem sichern von Lokaldaten gleichkommt.


*wieso gibts hier keine heul-smileys

@vierlagig: Was ist den verkehrt daran sich Hilfe in mehreren Foren zu holen.

 

[Larry Laffer]

... wenn du symbolisch adressierst, dann ist es eigentlich kein Problem, den TEMP-Bereich in den STAT-Bereich zu verschieben ...

Einen "Heul-Smilie" gibt es unter Weitere :

 

[vierlagig]

@vierlagig: Was ist den verkehrt daran sich Hilfe in mehreren Foren zu holen.

daran ist nichts verkehrt, aber hättest du darauf hingewiesen wären einige antworten nicht doppelt gekommen und einige hätten mehr zeit zum arbeiten gehabt.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ereignisgesteuerte Programmbearbeitung
Die zyklische Programmbearbeitung kann durch bestimmte Startereignisse
(Alarme) unterbrochen werden. Tritt ein solches Startereignis ein, wird der gerade
bearbeitete Baustein an einer Befehlsgrenze unterbrochen und ein anderer
Organisationsbaustein abgearbeitet, der dem Startereignis zugeordnet ist. Danach
wird die Bearbeitung des zyklischen Programms an der Unterbrechungsstelle
wieder fortgesetzt.

Na ja das sagt nicht viel neues, aber man kann schon davon ausgehen, daß alles wider paßt, sonst hätte man sicher darauf hingewiesen, daß z.Bsp. AR1 und Ar2 gesichert werden muß etc.

Wenn ich das mit dem L-Stack richtig verstanden habe, dürfte der Aufruf des FB im OB35 den L-Stack des OB1 und dessen FB gar nicht berühren, da ja ein anderer teil des aufgeteilten L-Stack. So die Prioroitätsklasse nicht geleich ist. Und selbst dann wird ja nur aufgestockt.

@tobi
bist du dir sicher, nicht doch irgendwelche Stat-Daten zu verändern, bevor das BE im Fb des OB35 kommt?

@4L
Ich find da auch nichts dabei, solche Probleme an mehreren Fronten zu klären, zumal es noch kein befriedigendes Ergebnis gibt.
Ok, hab deine Erklärung grad noch gelesen, na ja, ich hätts wohl auch nicht sofort erwähnt.

 

[Sarek]

@ tobi

benutzt du am FB zufällig IN_OUT Variablen ?

hier könnte es zu Problemen kommen
wenn Du an IN_OUT elementare Datentypen verwendest (Bool, Word ....)

werden diese am Anfang des FB automatisch in den IDB kopiert ...

das könnte zur Folge haben:

OB1 ruft FB100:
IN_OUT_1 (DINT) : MD10
=> MD10 wird in IDB kopiert
...
Im Programm wird ein neuer Wert für IN_OUT_1 berechnet
=> Instanzdatum für IN_OUT_1 hat sich geändert
=> nicht jedoch MD10 ( wird erst am Ende des FB umkopiert)
...
OB35 unterbricht FB100 und ruft FB100 mit selben IDB:
IN_OUT_1 (DINT) : MD10
=> MD10 wird in IDB kopiert und berechneter Wert aus FB100(OB1-Zykl.) wird überschrieben
FB100(OB35) wird beendet

=> es wird im FB100 (OB1) wieder weiter gemacht
der Wert von IN_OUT_1 hat sich aber durch den OB35-Aufruf geändert
falls jetzt mit diesem Parameter weitergerechnet wird kann es zu falsche Ergebnissen führen !!

 

[Ralle]

@Sarek

Wird denn auch umkopiert, wenn gar nichts am FB im OB35 anparametriert ist?