# Problem mit Lokaldaten



## tobi221081 (13 Januar 2009)

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!


----------



## vierlagig (13 Januar 2009)

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...


----------



## tobi221081 (13 Januar 2009)

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.


----------



## tobi221081 (13 Januar 2009)

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?


----------



## Ralle (13 Januar 2009)

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.


----------



## vierlagig (13 Januar 2009)

ja, so ist es.

wenn noch mehr in den OB35 kommt, so rette im NW1 und schreibe im letzten zurück


----------



## Larry Laffer (13 Januar 2009)

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


----------



## tobi221081 (13 Januar 2009)

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.


----------



## tobi221081 (13 Januar 2009)

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.


----------



## Larry Laffer (13 Januar 2009)

... 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


----------



## tobi221081 (13 Januar 2009)

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.


----------



## Larry Laffer (13 Januar 2009)

tobi221081 schrieb:


> 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


----------



## tobi221081 (13 Januar 2009)

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...


----------



## rostiger Nagel (13 Januar 2009)

...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


----------



## tobi221081 (13 Januar 2009)

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.


----------



## rostiger Nagel (13 Januar 2009)

...aber wenn du im OB35 ein BE im entsprechenden FB machst, kann er doch nicht an der gleichen stelle im OB1 weiterarbeiten wie vorher.....​


----------



## tobi221081 (13 Januar 2009)

...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.)


----------



## rostiger Nagel (13 Januar 2009)

...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


----------



## tobi221081 (13 Januar 2009)

Gibt es bekannte Einschränkungen oder Erfahrungen warum du dir das nicht trauen würdest?


----------



## rostiger Nagel (13 Januar 2009)

...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...


----------



## tobi221081 (13 Januar 2009)

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 (13 Januar 2009)

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 (13 Januar 2009)

...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 (13 Januar 2009)

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 (13 Januar 2009)

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
> ...


 
...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 (13 Januar 2009)

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
> ...



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 (13 Januar 2009)

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 (13 Januar 2009)

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 (13 Januar 2009)

Ralle schrieb:


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


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


----------



## Larry Laffer (13 Januar 2009)

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


----------



## tobi221081 (13 Januar 2009)

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 (13 Januar 2009)

Larry Laffer schrieb:


> @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 (13 Januar 2009)

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 (13 Januar 2009)

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

und eigentlich auch nicht an der anderen Sache ...


----------



## tobi221081 (13 Januar 2009)

@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 (13 Januar 2009)

... 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 (13 Januar 2009)

tobi221081 schrieb:


> @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 (13 Januar 2009)

> 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
> ...



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 (13 Januar 2009)

@ 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 (13 Januar 2009)

@Sarek

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


----------



## Sarek (13 Januar 2009)

IMHO kann nix kopiert werden wenn nix parametriert ist



Ralle schrieb:


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


----------



## Larry Laffer (13 Januar 2009)

... wenn nichts dran-parametriert ist, dann hat die Schnittstelle (durch die gleiche Instanz) die Werte der letzten Zuordnung ...

---

Ich fände es ganz nett, mal zu sehen zu bekommen, worüber wir hier so nett philosophieren ...

Gruß
LL


----------



## tobi221081 (13 Januar 2009)

Ich habe zwar INs und OUTs aber keine IN_OUTs


----------



## Larry Laffer (13 Januar 2009)

Larry Laffer schrieb:


> Ich fände es ganz nett, mal zu sehen zu bekommen, worüber wir hier so nett philosophieren ...


 
Wenn es nun nicht funktioniert (funktionieren sollte), dann greif doch noch meinen Vorschlag (s.o.) auf und stell deinen FB mal hier ein ...

Gruß
LL


----------



## Sarek (13 Januar 2009)

PEW an IN-Parameter parametriert ?

Was für eine CPU hast Du überhaupt?
Bei >500Byte L-Daten muß das ja ne S7-400 oder ne 318 sein, oder?

Sind die Speicherbereiche in der HW-Konfig dafür extra neu konfiguriert worden?

Schau mal in die Ref-Daten unter Programmstruktur wieviele Lokaldaten
reserviert sind für die OBs und was in der HW-Konfig eingestellt ist.
Vielleicht gibts doch ein Problem mit den L-Stack und die CPU geht nicht auf STOP weil irgendein FW-Fehler dies verhindert.


----------



## tobi221081 (13 Januar 2009)

@Larry: den FB hier ins Forum stellen... würd ich gern nur dann haut mich mein Chef... 

@sarek: 150Bytes => das Verhalten tritt bei unterschiedlichen CPUs auf....
=> Deswegen glaub ich nicht an einen FW-Fehler. PEWs nicht nur BLOCK_DBs und M

Ich denk immer mehr das es irgendein Hirnriß-Programmierfehler ist. Bin dem weiter auf der Spur.


----------



## Larry Laffer (13 Januar 2009)

tobi221081 schrieb:


> @Larry: den FB hier ins Forum stellen... würd ich gern nur dann haut mich mein Chef...


 
... war nur ein Vorschlag - du mußt es ja nicht so machen.
Die Chance wäre halt nur sehr groß, dass man dir dann helfen könnte ... Ich kann mir jedenfalls nicht vorstellen, dass der FB etwas furchtbar Geheimnisvolles enthält ...


----------



## Sarek (13 Januar 2009)

In deinem 1.Post schreibst Du > 500Byte lokaldaten
jetzt nur 150 Bytes.

Sind wirklich nur 150Bytes deklariert?



tobi221081 schrieb:


> @Larry: den FB hier ins Forum stellen... würd ich gern nur dann haut mich mein Chef...
> 
> @sarek: 150Bytes => das Verhalten tritt bei unterschiedlichen CPUs auf....
> => Deswegen glaub ich nicht an einen FW-Fehler. PEWs nicht nur BLOCK_DBs und M
> ...


----------



## Onkel Dagobert (13 Januar 2009)

Es liegt sicherlich nicht an den temporären Lokaldaten! Wie bereits mehrfach erwähnt wurde, besitzen OB1 und OB35 getrennte Datenbereiche für die temporären Lokaldaten. Wird der OB durch den OB35 unterbrochen und anschließend fortgesetzt, so besitzen die temporären Lokaldaten noch ihre Gültigkeit (derselbe Zyklus), und müssen daher auch nicht gesichert werden.

Die Ursache liegt höchst wahrscheinlich in den statischen Lokaldaten. Beim Aufruf eines FBs werden vor der Bearbeitung des Codes die Eingangsparameter in den Instanz-DB kopiert. Daran ändert auch ein BE nichts. Ebenso werden die Ausgänge vor dem Verlassen des FBs aus dem Instanz-DB aktualisiert. Auch das wird durch ein BE nicht verhindert.

Aus dieser Tatsache verbietet sich eigentlich schon ein mehrfacher Aufruf mit einer Instanz, insbesondere in verschiedenen Prioritätsklassen. Die Eingänge müssten in beiden OBs konsistent sein und dürften natürlich nicht beschrieben werden. Die Bausteinausgänge dürften nicht als Zwischenergebnisse missbraucht werden (macht man ja so wie so nicht, wäre jedoch möglich). Dann könnte es eventuell funktionieren. Für IN_OUTs gilt es natürlich genau so.

@tobi
Ruf' doch mal im OB35 den FB ohne Aktualparameter auf (bis auf die OB35-Kennung). Wenn ich richtig liege, dürfte das Problem dann nicht auftreten.


Gruß, Onkel


----------



## Sarek (13 Januar 2009)

Die Eingänge sind eigentlich automatisch konsistent wenn:
a) nicht direkt auf Peripherie zugegriffen wird
b) es nicht einen den stilistischen "Programmierfehler" gibt das z.B. ein MW von aussen angeflanscht ist und im FB direkt nochmal draufgeschrieben wird (so ne ART Zirkelbezug)
c) ein IN-Parameter im FB nicht zugewiesen wird (auch stilistischer "Programmierfehler")

Die Konsistenz ergibt sich einfach daraus wenn ein FB unterbrochen wird und in einer anderen Prio neu aufgerufen wird mit dem selben IDB dann
sind die IN-Daten konsistent wenn der FB selbst nicht die o.g. Daten frisiert oder natürlich ein anderer Baustein vorher bzw. OB in der neuen Prio-Klasse.

Bei OUT muß unbedingt zugewiesen werden bevor abgefragt wird.
Zwischenergebnisse dürften nix ausmachen, da die Daten im IDB vom
zweiten Aufruf nicht verändert werden sondern nur rausgeschrieben 
werden auf den angeflanschten Parameter.

Bei INOUT ist ein bisschen komplizierter, wie oben schon angemerkt.






Onkel Dagobert schrieb:


> Es liegt sicherlich nicht an den temporären Lokaldaten! Wie bereits mehrfach erwähnt wurde, besitzen OB1 und OB35 getrennte Datenbereiche für die temporären Lokaldaten. Wird der OB durch den OB35 unterbrochen und anschließend fortgesetzt, so besitzen die temporären Lokaldaten noch ihre Gültigkeit (derselbe Zyklus), und müssen daher auch nicht gesichert werden.
> 
> Die Ursache liegt höchst wahrscheinlich in den statischen Lokaldaten. Beim Aufruf eines FBs werden vor der Bearbeitung des Codes die Eingangsparameter in den Instanz-DB kopiert. Daran ändert auch ein BE nichts. Ebenso werden die Ausgänge vor dem Verlassen des FBs aus dem Instanz-DB aktualisiert. Auch das wird durch ein BE nicht verhindert.
> 
> ...


----------



## Onkel Dagobert (14 Januar 2009)

Hallo Sarek,



Sarek schrieb:


> ..Zwischenergebnisse dürften nix ausmachen, da die Daten im IDB vom zweiten Aufruf nicht verändert werden sondern nur rausgeschrieben werden auf den angeflanschten Parameter...


Damit hast du recht. Vielleicht ist ja doch noch ein Durchgangsparameter dabei. Dann würde das Zwischenergebnis durch den zweiten Aufruf verändert werden. Irgend so eine Fehlerursache vermute ich jedenfalls.


Gruß, Onkel


----------



## tobi221081 (14 Januar 2009)

Guten Morgen  

Nach einer schlaflosen Nacht mit viel grübeln über den Fehler gehts nun weiter. 

Erstmal an alle einen herzlichen Dank, dass ihr euch so bemüht.

Also nochmal wegen der Größe der Lokaldaten. Im Post beim Siemens-Forum schrieb ich >500. Das war so ein "beim Postschreiben grob geschätzer Wert". Ich hab nun nochmal genau nachgeschaut wieviele das nun sind und dabei ist mir ein Fakt aufgefallen der sehr von Interesse sein könnte.


Mein FB verfügt über 150 Byte Lokaldaten. Nun ruft mein FB wiederrum einen FC auf. Dieser FC ist eine Art "Funktionsbibliothek" um Algorithmik auszulagern. Dieser FC hat ebenfalls 146 Bytes Lokaldaten. Sind wir also schon bei >300 wenn wir die Lokaldaten des Aufrufenden-OBs dazuzählen.

Die Darstellung im "Referenzdaten"-Programm durchschau ich irgendwie nicht. Ich kriege dort andere Werte angezeit wie ich mir die "Lokaldaten im Pfad" anschaue. Der höchste Wert den ich dort sehe ist 674. 


Step7 bring beim Übertragen der Bausteine keine Fehler weil ja kein Baustein die erlaubten 256 übersteigt. Dies erklärt aber nicht warum auch große 400er Steuerungen aussteigen.


Zur Lösungsstrategie "Aufruf ohne Aktualparameter" selbst wenn ich keine Parameter anlege tritt der Fehler leider auf.
Und es gibt definitiv keine IN_OUTs.


----------



## Sarek (14 Januar 2009)

Wenn Du in den Referenzdaten unter Programmstrukur nachschaust kannst
du in der Spalte Lokaldaten(im pfad) die max. Belegung für jede Prioklasse
anschauen.

AFAIK ist die max. Größebei einer S7-300 256Byte pro Prio-Klasse
(ausser 318 )
d.h. dieses Programm dürfte nicht auf einer 300er laufen.
Bei der 318 und 400er kann in der HW-Konfig im Karteikartenreiter "Speicher" die max. Größe eingestellt werden.



tobi221081 schrieb:


> Guten Morgen
> 
> Nach einer schlaflosen Nacht mit viel grübeln über den Fehler gehts nun weiter.
> 
> ...


----------



## tobi221081 (14 Januar 2009)

Ich werd das gleich mal auscheckern.


----------



## Sarek (14 Januar 2009)

mach mal nen Screenshot und stell den hier rein



tobi221081 schrieb:


> Die Darstellung im "Referenzdaten"-Programm durchschau ich irgendwie nicht. Ich kriege dort andere Werte angezeit wie ich mir die "Lokaldaten im Pfad" anschaue. Der höchste Wert den ich dort sehe ist 674.


----------



## tobi221081 (14 Januar 2009)

Ich glaube ich hab die Lösung gefunden.

Mein FB ruft ja einen FC diese Funktionsbibliothek auf. Der wird über eine Schnittstelle im IDB parametriert und nicht über Aktualparameter. (Hat Performancetechnische Gründe warum das so...)

Jedenfalls benutze ich auch diesen FC um den BE im OB35 zu veranlassen.


Was ist nun eigentlich passiert. Mein FB hat die Schnittstelle im IDB des FC anparametriert und wurde nun unterbrochen bevor er den eigentlichen CALL macht.

Nun kam der OB35 und hat ebenfalls auf die Schnittstelle zugegriffen um den SFC6 für das BE auszuführen. Nun blieb die vom FB aus OB35 umparametrierte Schnittstelle stehen und der FB aus OB1 wurde fortgeführt. Mit falschen Schnittstellenparametern hat der FC dann "den falschen Job" erledigt und eine falsche Adresse berechnet.

Also Programmierfehler..... *erleichtert sei* weil dagegen kann man ja was machen.




Trotzdem wundert mich immernoch etwas. Warum ist die 315er nicht wegen der 6XX-Bytes Lokaldaten in den STOP gegangen. Das wird wohl ein Rätsel bleiben.


Ich bedanke mich an der Stelle nochmal für eure Unterstützung.


----------



## Onkel Dagobert (14 Januar 2009)

tobi221081 schrieb:


> ..Trotzdem wundert mich immernoch etwas. Warum ist die 315er nicht wegen der 6XX-Bytes Lokaldaten in den STOP gegangen. Das wird wohl ein Rätsel bleiben...


Das liegt wohl daran dass die 315er 1024 Bytes je Aufrufebene adressieren kann.


Gruß, Onkel


----------



## Larry Laffer (15 Januar 2009)

tobi221081 schrieb:


> Mein FB ruft ja einen FC diese Funktionsbibliothek auf. Der wird über eine Schnittstelle im IDB parametriert und nicht über Aktualparameter. (Hat Performancetechnische Gründe warum das so...)
> 
> Jedenfalls benutze ich auch diesen FC um den BE im OB35 zu veranlassen.
> 
> ...


 
Hallo Tobi,
Programmierfehler ...? Das sieht für mich eher nach extrem unsauberer Programmierung aus ... ich muß allerdings gestehen, dass ich diese Erklärung nicht wirklich verstanden habe ...

Gruß
LL


----------



## tobi221081 (15 Januar 2009)

Sarek schrieb:


> Wenn Du in den Referenzdaten unter Programmstrukur nachschaust kannst
> du in der Spalte Lokaldaten(im pfad) die max. Belegung für jede Prioklasse
> anschauen.
> 
> ...


 
Nun gibts es 2 konkurierende Aussagen. 256 versus 1024. Ich wälze gerade in meinen Unterlagen aber irgendwie find ich (noch) kein offizielles Siemens-Handbuch welches sagt wieviele das nun sind.

Das wär ja nun schade, wenn wir diesen mittlerweile groß gewordenen Thread mit einer falschen Aussage beenden.


----------



## tobi221081 (15 Januar 2009)

aus der Siemens-Mall

CPU312 als kleinster Vertreter
Lokaldaten


je Prioritätsklasse, max.
256 byte



CPU315

Lokaldaten


je Prioritätsklasse, max.
1 024 byte; pro Baustein max. 510





@Larry: ....und das sagt einer der pauschal dazu geraten hat alle Lokaldaten in den STAT-Bereich zu kopieren ohne ne Ursache abzuklären. Naja, neee komm auf das wer programmiert sauberer Niveau lassen wir uns nicht runter... Geht ja hier darum jemanden zu Helfen und nicht um Selbstdarstellung.


----------



## rostiger Nagel (15 Januar 2009)

Hallo tobi,
ich glaube nicht das hier um selbstdarstellung geht und vom Larry schon garnicht. Aber die Art deines beschriebenen Programmes finde ich auch sehr ungewöhnlich. Für mich sind Bausteine die an den Grenzen einer CPU dieser Leistungsklasse gehen nicht gerade schön. Nichts für ungut...

gruß Helmut


----------



## Larry Laffer (15 Januar 2009)

@Reparatur:
Danke dir für dein Statement ...



tobi221081 schrieb:


> @Larry: ....und das sagt einer der pauschal dazu geraten hat alle Lokaldaten in den STAT-Bereich zu kopieren ohne ne Ursache abzuklären. Naja, neee komm auf das wer programmiert sauberer Niveau lassen wir uns nicht runter... Geht ja hier darum jemanden zu Helfen und nicht um Selbstdarstellung.


 
@Tobi:
Den "pauschalen" Rat habe ich dir deshalb gegeben, weil das mit den temporären und statischen Lokaldaten ein immer wieder gern gemachter Fehler bei der SPS-Programmierung ist. Das tolle daran ist, dass sogar ansich erfahrene Programmierer das sehr oft nicht wissen, dass die temporären Daten von einem Zyklus (bzw. Baustein-Aufruf) zum nächsten nicht (oder nur zufällig) erhalten bleiben. Ich hatte auch bei dir den Eindruck, dass das so ist.
Zu der Art der Programm-Realisierung:
Wenn ich bei einem Aufruf des Bausteins (wie ich schon geschrieben habe mache ich so etwas auch gerne) eine Funktion benutzen möchte und bei einem anderen Aufruf nicht dann kann man sich natürlich einen Abbrechen mit "Abbruch erzwingen usw." - man kann aber auch die ungewünschte Teilfunktion einfach überspringen (so à la If Modus_1 then ... else ... end_if). In AWL wäre das dann irgendetwas mit SPA und SPB etc.
Den Kommentar hatte ich übrigens des Helfens (und der Selbst-Darstellung wegen) verfasst - das mit der Selbst-Darstellung habe ich hier (glaube ich) nämlich tatsächlich nicht nötig.
Ich hatte dabei den Eindruck (und der besteht auch immer noch), dass du (ihr) die stattfindende Funktion immer noch nicht wirklich im Griff habt. Vielleicht solltest du deine diesbezügliche Funktion ja noch mal überdenken ...
Wenn du es wünscht kann ich mich natürlich in Zukunft auch aus deinen Beiträgen heraus halten ...

Gruß
LL


----------



## tobi221081 (15 Januar 2009)

Nein das wünsch ich natürlich nicht. Nichts für ungut...


----------

