@Sarek
Wird denn auch umkopiert, wenn gar nichts am FB im OB35 anparametriert ist?
Ich fände es ganz nett, mal zu sehen zu bekommen, worüber wir hier so nett philosophieren ...
@Larry: den FB hier ins Forum stellen... würd ich gern nur dann haut mich mein Chef...
@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.
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
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...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...
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.
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.
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.
Das liegt wohl daran dass die 315er 1024 Bytes je Aufrufebene adressieren kann...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...
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.
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.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?