Problem mit Lokaldaten

[Sarek]

IMHO kann nix kopiert werden wenn nix parametriert ist

@Sarek

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

[Larry Laffer]

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

Ich habe zwar INs und OUTs aber keine IN_OUTs

[Larry Laffer]

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]

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]

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

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

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

Sind wirklich nur 150Bytes deklariert?

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

[Onkel Dagobert]

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]

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.

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