Problem mit Lokaldaten

[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]

@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...&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]

@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]

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?