Problem mit Lokaldaten

... 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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@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.
 
tobi221081 schrieb:
@Larry: den FB hier ins Forum stellen... würd ich gern nur dann haut mich mein Chef...
Zum Vergrößern anklicken....

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

Ich denk immer mehr das es irgendein Hirnriß-Programmierfehler ist. Bin dem weiter auf der Spur.
Zum Vergrößern anklicken....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
Zuletzt bearbeitet:
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.

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
Zum Vergrößern anklicken....
 
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...
Zum Vergrößern anklicken....
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
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.

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.
Zum Vergrößern anklicken....
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.

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.
Zum Vergrößern anklicken....

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

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.
Zum Vergrößern anklicken....

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.
 
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.
 
Zuletzt bearbeitet:

Similar threads

waldy
TIA OB35 Erfassen
Antworten
7
Aufrufe
1K
waldy
waldy
D
TIA Problem mit Multiinstanzen?
Antworten
9
Aufrufe
1K
DCDCDC
D
G
Grundsatzfragen zur Restrukturierung einer bestehenden Programmstruktur
Antworten
11
Aufrufe
2K
Mrtain
Mrtain
U
Step 7 Lokaldaten ohne Deklaration?
Antworten
10
Aufrufe
913
ducati
D
M
Problem mit dem Ruhestrom einer Drehzahlachse
Antworten
5
Aufrufe
1K
MaxDan
M
Zurück
Oben