temporäre Lokalvariablen

Earny

Level-1
Beiträge
422
Reaktionspunkte
38
Zuviel Werbung?
-> Hier kostenlos registrieren
hallo,
behält eine temporäre Lokalvariable im OB1 ihren Wert von Basteinaufruf zu Bausteinaufruf?
Konkret wurde im Programmcode am Ende des Zyklus die temporäre boolsche Lokalvariable "Var1" auf den Wert True gesetzt und dann in den ersten Anweisungen im OB1 abgefragt. Dabei zeigte sie immer noch den Wert True.
Ich dachte, temporäre Lokalvariablen verlieren ihren Wert von einem Bausteinaufruf zum nächsten.

Generell: Speichern temporäre Lokalvariablen im OB1 ihren Wert von Bausteinaufruf zu Bausteinaufruf, oder ist das hier mal zufällig so? Ich meine mal irgendwo gelesen zu haben, dass der Wert einer temp. Lokalvariable bei S7 nicht definiert ist, wenn noch kein Schreibbefehl erfolgte.


Gruß
Earny
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sie müssen ihren Wert nicht verlieren, können aber.
Wenn du z.B. nur den OB1 hast und greifst nirgendwo anders
auf Temponäre Var zu, kann es sein das diese Variable ihren
zustand behält.

Du solltest niemals in einer Lokalvariablen, Bausteinübergreifend
einen Wert speichern, das geht in die hose.

gruß helmut
 
Na na ...
Also erstmal muß auch im OB1 eine TEMP-Variable wenigstens ein Mal korrekt zugewiesen werden ... und dann, was ist, wenn ein Interrupt-OB aufgerufen wird ? Das mit der TEMP-Variablen funktioniert auch in einem FC wenn es davon nur einen Aufruf gibt - und dann baut einer einen 2. FC und ruft ihn auch auf ...!?
Also ... ich sehe das wie Helmut und würde so einen Scheiß lassen ...

Gruß
LL
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... und dann, was ist, wenn ein Interrupt-OB aufgerufen wird ?

alle OBs haben einen eigenen speicherbereich.

aber warum probiert ihr es nicht einfach aus? bastelt einen sekundentakt zähler mit flankenauswertung über ein tempvariable und einen mit globalem merker und vergleicht die werte.

habe ich recht, sind sie gleich - habt ihr recht, dann nicht...
 
Eigentlich hat es doch geheißen, das jede Prioritätsklasse Ihren eigenen Speicherbereich hat,
d.h. für mich, das OB1 und alles was im selbigen aufgerufen wird sich diesen Stack teilen.

Die von Larry beschriebene Interrupt-OB vermischung kann nicht vorkommen,
das beeinflussen von OB1 Temp-Var mit Temp-Vars von anderen FC/FB die im OB1 aufgerufen imho aber schon.

@vl
Solange der Stack nur maßvoll verwendet ist, dürfte das immer funktionieren.

Mfg
Manuel
 
.....
das beeinflussen von OB1 Temp-Var mit Temp-Vars von anderen FC/FB die im OB1 aufgerufen imho aber schon.
.....
:confused::confused: Wie das? Das würde ja bedeuten, dass eine vor einem FC/FB-Aufruf bereits zugewiesene Tempvar nach dem Bausteinaufruf innerhalb des OB1 ihre Gültigkeit verloren haben könnte. Das ist aber definitiv nicht so.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
alle OBs haben einen eigenen speicherbereich.

aber warum probiert ihr es nicht einfach aus? bastelt einen sekundentakt zähler mit flankenauswertung über ein tempvariable und einen mit globalem merker und vergleicht die werte.

habe ich recht, sind sie gleich - habt ihr recht, dann nicht...

ich hab es mal ausprobiert, in OB1 und OB35 eine Bolsche Variable als Bool
20.0 eingebracht. Ich konnte Sie getrennt ansprechen und Sie haben ihre
zustände gespeichert.

Wieder etwas gelernt.
Der Nachteil der Intelligenz besteht darin,
das man ständig gezwungen ist dazuzulernen.
 
Es ist trotzdem Vorsicht angebracht, da es möglich ist, einen Anypointer auf die Lokaldaten des Vorgängerbausteins zusammenzubauen und sowohl lesend als auch schreibend zu verwenden.
 
Es ist trotzdem Vorsicht angebracht, da es möglich ist, einen Anypointer auf die Lokaldaten des Vorgängerbausteins zusammenzubauen und sowohl lesend als auch schreibend zu verwenden.

das ist mal schöner seemannsgarn ... wir bauen uns einen anypointer, der auf den letzten aufruf des OB1 zeigt :ROFLMAO:

wenn ich BEWUSST auf die lokaldaten des vorgängerbausteins zugreife, also aus einem FC auf die des OB, dann hat das einen grund, der gerechtfertig ist und dieses konstrukt ist dann als solches so aufgebaut, dass nichts passiert... hinzu kommt, dass ich nur jeden davor warnen kann, ein solches konstrukt zu bauen, das ist großer mist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
"können" nicht im OB1

Es gibt zu viele unterschiedliche Implementierungen von S7-CPUs (alleine innerhalb von SIEMENS mindestens 4 verschiedene) um sich darauf zu verlassen, dass eine Eigenschaft, die SIEMENS im Handbuch ausdrücklich NICHT EMPFIEHLT auszunutzen.

Lokalvariablen vor der Benutzung initialisieren, egal wo!
 
@vierlagig:
Nicht auf den letzten Aufruf des OB1. Im aktuellen. Aber die Definition des Vorgängerbausteins ist dir schon geläufig, oder??
 
... hinzu kommt, dass ich nur jeden davor warnen kann, ein solches konstrukt zu bauen, das ist großer mist.
*ACK*

... da mir nämlich ein solches Konstrukt (wenn der Zugriff schreibend erfolgt) generell die temporären Lokaldaten des aufrufenden Bausteins verhunzt.
Egal ob nun im OB1 oder irgendwo anders.
 
besten Dank für die Antworten. Meine eigenen Tests haben auch die Aussagen von 4L bestätigt. Trotzdem bleibt ein ungutes Bauchgefühl, wenn man die anderen Aussagen und die nachfolgenden Zitate berücksichtigt.

Hans Berger schreibt in seinem AWL-SCL-Buch zum Thema "Temporäre Lokaldaten" auf S. 258:
".....Temporäre Lokaldaten sind Operanden, die im Lokaldaten-Stack (L-Stack) im Systemspeicher der CPU liegen. Das Betriebssystem der Zentralbaugruppe stellt die temporären Lokaldaten für jeden Codebaustein bei dessen Aufruf zur Verfügung. Die Werte im L-Stack sind beim Aufruf eines Bausteins quasi zufällig."

In der STEP7-Hilfe ist unter dem Stichwort "temporäre Lokaldaten" zu lesen:
"...Beim Erstellen von Organisationsbausteinen können Sie temporäre Variablen (TEMP) deklarieren, die nur während der Bearbeitung des Bausteins zur Verfügung stehen und dann wieder überschrieben werden. Vor dem ersten Zugriff müssen die Lokaldaten initialisiert werden. Außerdem benötigt jeder Organisationsbaustein für seine Startinformation 20 Lokaldaten-Byte.
Die CPU besitzt einen begrenzten Speicher für die temporären Variablen (Lokaldaten) gerade bearbeiteter Bausteine. Die Größe dieses Speicherbereichs, des Lokaldaten-Stacks, ist CPU-abhängig. 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."

Wenn das Speicherverhalten von irgendwelchen mehr oder weniger zufälligen Konstellationen abhängt, dann sollte man so wohl besser nicht programmieren.

Gruß
Earny
 
Zuviel Werbung?
-> Hier kostenlos registrieren
beim berger sag ich: ist ein OB ein codebaustein? wie ist die definition und wie kann man die grenzen deutlich machen. OB1 ist für mich immer noch kein codebaustein, er ist DAS hauptprogramm.

bei der s7-hilfe: durch die absatzlosigkeit bekommen diese aussagen eine unschärfe, die ihres gleichen sucht, wie immer :rolleyes:

ich möchte aber auch noch loswerden: dass eine flanke im OB1 benötigt wird und diese dann auch noch mit temp-variablen arbeitet ist nicht der normale weg, wie ich programme schreibe ... aber ist man sich dieses verhaltens bewußt kann man, ohne auf evtl. beschränkte ressourcen zurückgreifen zu müssen, einige funktionen zur ibn mal eben umsetzen ... zykluszähler z.b.
 
b
Wenn das Speicherverhalten von irgendwelchen mehr oder weniger zufälligen Konstellationen abhängt, dann sollte man so wohl besser nicht programmieren.

Gruß
Earny

Dann hast Du den Sinn und Zweck noch nicht richtig verinnerlicht.
Diese Temp's machen schon Sinn, müßen aber mit bedacht eingesetzt werden.
Ich benutzte die z.B. nur für Berechnungen innerhalb eines Netzwerkes als Speicher oder im Netzwerk direkt dahinter.
Wenn man damit umzugehen weiß sind die Temp's eine gute Erweiterung.
WICHTIG: Man muss nicht die Vorteile sondern in erster Linie die Grenzen kennen.
 
...Vorgängerbaustein...
Ja, wir haben das schon verstanden....:rolleyes:
Da bin ich nicht so sicher:
Im Zusammenhang mit dem zu bauenden Anypointer bezeichnet "Vorgängerbaustein" den Vorgänger (Aufrufer, caller) in einer Kette von Unterprogrammaufrufen.

Wenn aber Vierlagig schreibt:
das ist mal schöner seemannsgarn ... wir bauen uns einen anypointer, der auf den letzten aufruf des OB1 zeigt :ROFLMAO:
glaube ich, daß er es so versteht, als sei ein Pointer auf die Daten des OB1 im vorhergehenden Zyklus gemeint.
 
Zurück
Oben