Step 7 Verständnisfrage zu TEMP-Variablen

Ok, lieben Dank für eure geduldigen Erklärungen!

Denke jetzt komme ich der Sache allmählich näher (ja stimmt, dauert mal wieder ganz schön!). Was ich bei meiner eingangs gestellten Frage nicht bedacht habe ist, dass der Zustand ja über einen Zyklus hinaus gespeichert werden muss. Weiß nicht ob man es so ausdrücken kann, aber es könnte ja sein, dass sich der Zustand dann ändert, wenn die FC mit ihrer Temp-Variablen gerade nicht aufgerufen ist und dann würde ihr diese Wertänderung wohl durch die Lappen gehen... :p

@Michael:

Danke für den Link; ist dort echt super erklärt. Verstehe nur das nicht ganz:

"Aus den oben genannten Gründen lassen sich TEMP nicht sinnvoll an Stellen verwenden, an denen nicht in jedem Zyklus zugewiesen wird (z.B. SR-Glieder) oder an denen die Variable vor einer Zuweisung abgefragt wird."

Die Ausführung von Setzen/Rücksetzen passiert doch immer sofort an der Stelle, an der ich es programmiert habe. Und wenn das in einer FC passiert, dann wäre das doch eigentlich kein Problem. Oder verstehe ich das jetzt falsch?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Das verstehst du eher falsch! ;)

U M0.0
S #Temp_Var
U M0.1
R #Temp_Var

Wenn weder M0.0 noch M0.1 True ist, ist #Temp_Var unbestimmt, denn die Variable wird ja weder gesetzt noch rückgesetzt.

U M 0.0
SPB M001

U M 0.1
= #Temp_Var

M001: NOP 0

Wenn M0.0 False ist. dann hat #Temp_Var einen definierten Wert, True bei M0.1 = True und False, bei M0.1 = False.
Wenn aber M0.0 True ist, dann wird die Wertzuweisung an #Temp_Var umsprungen und die Variable hat einen Wert, der vollkommen zufällig True oder False ist!
 
Ralle schrieb:
Das verstehst du eher falsch! ;)
Zum Vergrößern anklicken....

Lieben Dank Ralle,

naja - hätte mich ja auch gewundert, wenn's anders gewesen wäre... ;)

Aber jetzt ist das doch klar geworden! (Irgendwie brauche ich immer Beispiele, komisch...)


UND: Meine "Erläuterung" für die Zustandsabfrage (mit TEMP) könnte man(n) :p so durchgehen lassen, oder?
 
spirit schrieb:
... es könnte ja sein, dass sich der Zustand dann ändert, wenn die FC mit ihrer Temp-Variablen gerade nicht aufgerufen ist und dann würde ihr diese Wertänderung wohl durch die Lappen gehen...
Zum Vergrößern anklicken....
Nein. Es ist so, dass der Speicher für TEMP-Variablen nicht fest von einem Baustein reserviert werden, sondern nur während des Aufrufs. Davor und danach steht dieser Speicher wieder anderen Bausteinen zur Verfügung um ihre TEMP dort abzulegen, diese Bausteine ändern also die Werte im TEMP-Speicher. Wenn man also eine Variable abfragt, die man vorher nicht zugewiesen hat, steht dort zwangsläufig noch der Wert, den ein anderer Baustein dort abgelegt hat, also ein mehr oder minder zufälliger Wert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
M-Ott schrieb:
Nein. Es ist so, dass der Speicher für TEMP-Variablen nicht fest von einem Baustein reserviert werden, sondern nur während des Aufrufs. Davor und danach steht dieser Speicher wieder anderen Bausteinen zur Verfügung um ihre TEMP dort abzulegen, diese Bausteine ändern also die Werte im TEMP-Speicher. Wenn man also eine Variable abfragt, die man vorher nicht zugewiesen hat, steht dort zwangsläufig noch der Wert, den ein anderer Baustein dort abgelegt hat, also ein mehr oder minder zufälliger Wert.
Zum Vergrößern anklicken....

Ok Michael, also zweiter Versuch mit meinen Worten:

In meinem Beispiel wird, während die FC aufgerufen wird, in die TEMP-Variable der aktuelle Zustand eingeschrieben. Nachdem die FC abgearbeitet wurde, wird dieser TEMP-Bereich wieder von einer anderen FC benutzt und überschrieben. Wird die ehemalige FC erneut aufgerufen, so steht in der TEMP-Var nicht mehr der ursprüngliche Zustand, sondern evtl. ein zufälliger Wert aus einem anderen FC-Aufruf. Besser? ;)
 
Richtig und damit besser.

Außerdem ist es neben der zwischenzeitlichen Benutzung des Speicherplatzes durch andere Variablen auch möglich, das die Temp-Variable beim nächsten Aufruf an einem anderen Speicherort angelegt wird und deswegen der Inhalt vor dem ersten Schreiben wieder zufällig ist.
 
hucki schrieb:
Richtig und damit besser.

Außerdem ist es neben der zwischenzeitlichen Benutzung des Speicherplatzes durch andere Variablen auch möglich, das die Temp-Variable beim nächsten Aufruf an einem anderen Speicherort angelegt wird und deswegen der Inhalt vor dem ersten Schreiben wieder zufällig ist.
Zum Vergrößern anklicken....

Supi, ich danke Euch SEHR!

Glaube, dann kann ich diese TEMP-Variablen nun doch als erledigt abhaken... :s12:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo spirit!

Beispiele sind ja ansich was gutes, aber, sofern du die Möglichkeit hast, probier doch mal folgendes (jetzt bin ich nämlich selber neugierig geworden und ich habe leider keine Möglichkeit das zu Testen):

Lege ein neues Projekt an mit OB1 und zwei FCs oder FBs oder gemischt.

Im ersten Versuch rufst du im OB1 zuerst den ersten Baustein auf und danach den zweiten.
In beiden Bausteinen deklarierst du jeweils im temp. Bereich eine Bool Variable.
Im ersten Baustein setzt du die temp. Variable mit SET auf "1".
Im zweiten Baustein fragst du die temp. Variable ab und weißt sie z.B. einen Ausgang zu (ist ja nur ein Test).

Also:
Code: 
OB1:
Call FC1
Call FC2

Im FC1:
Set
= xTemp

Im FC2:

U xTemp
= A0.0

Meine Behauptung (und bis dato bisherige Auffassung): A0.0 wird "1"

Versuch #2

Selbes Szenario, selber Code nur: Jetzt rufst du FC2 in FC1 auf!

Code: 
OB1:

Call FC1

Im FC1:

Set
=xTemp

Call FC2

Im FC2:

U xTemp
= A0.0

Hier denke ich wird A0.0 "0" bleiben.

Wie komme ich auf diese Behauptungen?

Der Lokaldatenstack (L-Stack) wird ja von allen Bausteinen genutzt. OB1 legt hier seine 20 Bytes im L-Stack ab. Dadurch dass du im ersten Versuch in FC1 eine Bool Variable im temp. Bereich angelegt hast werden hier wohl 2 Byte reserviert werden. Sobald du im FC1 bist umfasst der Stack also 22 Bytes. Jetzt wird FC1 beendet und diese 2 Bytes werden wieder freigegeben. Jetzt wird FC2 aufgerufen und wiederum werden 2 Bytes reserviert. Der Stack umfasst aber weiterhin nur diese 22 Bytes.

Im zweiten Versuch hast du im FC1 wieder diese 22 Bytes ... da aber diesmal FC2 in FC1 aufgerufen wird werden nun zusätzlich nochmal 2 Bytes "draufgelegt" also insgesamt 24 Bytes belegt!

Die größe des Lokaldatenstacks kannst du übrigens in den Referenzdaten einsehen! Dieser ist standardmäßig auf 256 Bytes ausgelegt (kann aber bei einigen CPUs verändert werden). Es ist also trotzdem Vorsicht geboten das dieser Stack nicht überläuft (solange du nichts mit String Datentypen oder riesigen Arrays vom Typ UDT zu tun hast wird das aber auch nicht so schnell passieren)!

Das kursiv geschriebene ist meine bisherige Auffassung zu diesem Thema und darf gerne von den Profis berichtigt werden ;)
 
nutellahase schrieb:
Also:
Code: 
OB1:
Call FC1
Call FC2

Im FC1:
Set
= xTemp

Im FC2:

U xTemp
= A0.0

Meine Behauptung (und bis dato bisherige Auffassung): A0.0 wird "1"
Zum Vergrößern anklicken....
Wenn das so passiert, dann ist das trotzdem zufällig! Es würde auch so sein, wenn die Temp-Variablen in FC1 und FC2 unterschiedliche Bezeichnungen haben. Eben nicht, weil es die gleiche Variable ist, sondern nur, weil sie zufällig nacheinander den gleichen Speicherplatz im Stack belegen.
Das passiert (vor allem bei kleineren Programmen) häufig auch mit der Temp-Variablen des FC's selbst - sie belegt zufällig wieder den gleichen Speicherplatz, wie beim vorigen Aufruf des FCs, und zufällig wurde der Speicherplatz zwischenzeitlich auch nicht anderweitig verwendet. Deshalb funktioniert dort das geplante Programm. Aber eben nur zufällig und nicht, wie es den Anschein macht, geplant.
 
nutellahase schrieb:
Hallo spirit!

Beispiele sind ja ansich was gutes, aber, sofern du die Möglichkeit hast, probier doch mal folgendes (jetzt bin ich nämlich selber neugierig geworden und ich habe leider keine Möglichkeit das zu Testen):

Lege ein neues Projekt an mit OB1 und zwei FCs oder FBs oder gemischt.

Im ersten Versuch rufst du im OB1 zuerst den ersten Baustein auf und danach den zweiten.
In beiden Bausteinen deklarierst du jeweils im temp. Bereich eine Bool Variable.
Im ersten Baustein setzt du die temp. Variable mit SET auf "1".
Im zweiten Baustein fragst du die temp. Variable ab und weißt sie z.B. einen Ausgang zu (ist ja nur ein Test).

Meine Behauptung (und bis dato bisherige Auffassung): A0.0 wird "1"

Versuch #2

Selbes Szenario, selber Code nur: Jetzt rufst du FC2 in FC1 auf!

Hier denke ich wird A0.0 "0" bleiben.
Zum Vergrößern anklicken....

Hi nutellahase,

ja die Zustände sind so, wie von dir vorhergesagt! Habe es eben getestet...

Und es stimmt, es passiert unabhängig davon, wie die Variablen heißen!
 
Dass es nicht auf die Variablennamen ankommt ist mir klar. Ich wollte damit eg nur zeigen, wie lokaldaten auf dem stack landen und wieder freigegeben werden (mMn trifft "zufällig" hier nur bedingt zu) und was eben passieren kann wenn man sie vorher nicht initialisiert.

Gesendet von meinem GT-I9300 mit Tapatalk
 

Similar threads

M
TIA Anwendungsbeispiel - Temp Static Variablen
2
Antworten
24
Aufrufe
3K
TP-Inc
T
M
Step 5 WF705 SSI Encoder Karte: schnelles Einlesen der Kanäle! Lösung!
Antworten
0
Aufrufe
1K
Maagic7
M
J
TIA S5->S7 Hochrüsten
Antworten
7
Aufrufe
3K
Thomas_v2.1
T
D
Sonstiges Code von S5 nach S7 wandeln
Antworten
4
Aufrufe
2K
PN/DP
PN/DP
R
S5-U95 Vergleich
Antworten
5
Aufrufe
4K
Heinileini
Heinileini
Zurück
Oben