lokale TEMP-Variablen initialisieren

[Tigerente1974]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Benutzen von temporären Lokalvariablen scheint ja nicht uneingeschränkt beliebt zu sein. Ich denke aber, dass sie durchaus Sinn machen und benutze diese zum Teil auch.
In der Regel speichere ich damit Zwischenergebnisse von BOOL-Verknüpfungen oder irgendwelchen Berechnungen (ADD_I, MUL_R, etc...) Das klappt auch ohne Probleme.
Mein Kollege hat jetzt mal eine TEMP-Variable an den (Q) Ausgang eines IEC TON-Timers gehängt. Das ging dann schief, denn der Ausgang wird scheinbar nicht unbedingt von dem IEC-Baustein beschrieben. Sprich: Die Zeit war noch nicht abgelaufen, die TEMP-Variable hatte aber den Zustand 1, als sie weiter unten im Baustein abgefragt wurde.
Wenn man nachliest, findet man auch die Information, dass temporäre Lokaldaten initialisiert werden sollen/müssen.

Das erschließt sich mir nicht ganz. Gilt das auch für die Verwendung als Zwischenergebnisse, wie ich sie zuerst beschrieben habe. Es dürfte doch wohl egal sein, ob ich zuerst eine 0 auf die Lokaldaten schreibe, oder diese mit einer =-Zuweisung (bei BOOL) bzw. als Ergebnis einer Berechnung zuweise.
Oder sagt man, je nachdem wie die Variable dann verwendet wird -wie in dem 2. Beispiel mit dem IEC-Timer- ist das IMMER zu empfehlen und deswegen macht man das auch immer.
Wenn ja, wie wäre es dann richtig?
Benutzt man die symbolische Adressierung (R #Testmerker) hat man die Sicherheit, dass beim Einfügen von weiteren Variablen nichts "verrutscht" Bei vielen BOOL-Variablen ist das aber viel Handarbeit.
Schreibt man eine 0 auf das Lokaldatenwort in dem die BOOL-Variablen liegen, muss man immer im Auge behalten, dass ggf. der Adressbereich vergrößert werden muss, wenn man noch weitere Variablen einfügt.

 

[Ralle]

Temporäre Variablen muss man dann initialisieren, wenn man sie evtl. nicht jeden Zyklus im Baustein beschreibt, damit sie bei einer Abfrage einen Grundzustand haben z.Bsp. False. Wenn sie jeden Zyklus beschrieben werden, dann braucht man sie nicht initialisieren.

Dein TON sollte eigentlich den Ausgang Q immer aktualisieren, es sei denn er wird umsprungen, oder der EN-Eingang ist nicht 1. Was genau TON mit Q macht, wenn EN nicht True ist, kann ich dir gerade nicht sagen, probiere das doch einfach mal aus. Wenn dem so ist, sollte man die Temp-Var am Ausgang einfach am Anfang des Bausteines mit False belegen.

 

[blasterbock]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe da mal Probleme in einer ähnlichen Art gehabt.
Es stellte sich dann heraus, dass die Funktion, die benutzt wurde, eine feste Adresse benötigt, auf die geschrieben werden kann.

Ich weiß aber momentan nicht mehr, in welchem genauen Zusammenhang das war.

Alter hat halt nichts Schönes.

 

[Larry Laffer]

... mit dem TEMP am Ausgang eines IEC-Timers funktioniert aber definitiv (die Einschränkung von Ralle mit dem überspringen mal außer acht gelassen) wenn die Abfrage des TEMP's auf jeden Fall hinter dem Aufruf des Timers erfolgt. Da muß also noch etwas anderes mitspielen ...

Gruß
Larry

 

[PN/DP]

Temporäre Lokalvariablen eignen sich nur zum Zwischenspeichern von irgendwas, weil sie vor dem Beschreiben einen unbestimmten Zustand haben und ab Bausteinende ungültig werden. Beim nächsten Bausteinaufruf kann sonstwas in den Lokalvariablen stehen (der selbe Speicherbereich kann auch von anderen Bausteinen benutzt werden), deshalb muß man vor einem Lesen der temporären Lokalvariablen erstmal was in diese reinschreiben. Man braucht sie vor einem Schreibzugriff nicht extra zu initialisieren, man muß wie gesagt nur sicherstellen, daß vor einer lesenden Verwendung auch genau in dem Zyklus/Bausteinaufruf mindestens einmal was reingeschrieben wurde.

Wenn Du eigentlich gekapselte "private" Lokalvariablen mit Gedächtnis zum nächsten Zyklus meinst, dann mußt Du einen FB programmieren und die Lokalvariablen in den STAT-Bereich legen.


Beim Problem Deines Kollegen mit der lokalen TEMP-Variable am Q-Ausgang eines IEC-TON-Timer muß noch was anderes mitgespielt haben. Wenn der TON aufgerufen wird, dann wird danach auch garantiert der Wert des Q-Bits in die Ausgangs-Variable kopiert (von eventuellen Firmwarefehlern mal abgesehen). Es ist unerheblich, ob der TON selber seinen Q-Ausgang in diesem Zyklus beschrieben hat (die TON-Instanz inklusive seinem Q-Bit liegt in einem IDB!). Direkt nach dem Aufruf hat die temporäre Variable den gleichen Wert wie das Q-Bit. Nur wenn der TON nicht aufgerufen wird kann die Ausgangs-Variable einen anderen Wert als das Q-Bit haben, weil dann das Q-Bit nicht in die Ausgangs-Variable kopiert wird.

Harald

 

[Tigerente1974]

Zuviel Werbung?
-> Hier kostenlos registrieren

Erst einmal Danke für die Antworten.

Dass der Zustand von TEMP-Variablen nicht definiert ist, wenn der Baustein aufgerufen wird, war mir soweit klar.
Nach meinem Verständnis macht es demnach auch keinen Sinn, eine Lokalvariable zu nutzen, indem diese verwendet wird, bevor eine Zuweisung -welcher Art auch immer- gemacht wurde. Konstruktionen mit TEMP-Merkern die initialisiert werden müssen, weil die Zuweisung nicht in jedem Zyklus stattfindet, gefallen mir auch nicht besonders. Da würde ich doch eher auf STAT-Variablen zurückgreifen.

Aus dieser Sicht scheint mir ein Lehrsatz wie "TEMP-Variablen müssen immer initialisiert werden" eine übervorsichtige Formulierung zu sein.

Die Aussage meines Kollegen erschien mir demnach auch nicht wirklich nachvollziehbar. Ich vermute es ist tatsächlich so, dass irgendwo noch etwas anderes reingespielt hat. Wahrscheinlich ist es sinnvoll, das noch einmal in einer Testumgebung nachzustellen und der Sache genau auf den Grund zu gehen, mein Kollege weiss in der Regel auch ziemlich gut was er so macht...