TIA Anwendungsbeispiel - Temp Static Variablen

[Martin2XK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe eine etwas genauere Frage zu dem Thema "Temp" und "Static" Variablen. Wie die Abarbeitung im TIA Portal (V17) funktioniert ist mir klar. Was mir aber leider noch nicht ganz klar ist, ist die Frage ob es ein Beispiel (also einen Anwendungsfall) gibt, bei welchen eine Temp Variable mehr Sinn macht als eine Static. Über die Suche habe ich u a den Beitrag hier gefunden. Er ist sehr gut finde ich.

TIA - Woher weiß ich, ob ich eine Variable in Static, Temp, constant usw. speichern muss?

Hallo, es fällt mir leider schwer zu verstehen, wie ich eine Variable deklarieren muss. Kann mir das jemand vielleicht so einfach wie möglich erklären? Vielen Dank

www.sps-forum.de

Meine Frage wird aber leider nicht so ganz beantwortet.

Nehmen wir mal an, dass sich in meinem FB 10 KOP Netzwerke befinden. Im ersten Netzwerk wird meine Temp zugewiesen (kein (S) sondern nur --( )-- ). Im letzten Netzwerk (Nr 10) wird etwas mit der Temp Variable gemacht. Also wenn 1 dann setze etwas zurück --(R)-- in dem Fall. Direkt im Anschluss bevor der nächste Zyklus gestartet wird, müsste doch meine Temp wieder 0 sein, dann kommt die Abarbeitung des ersten Netzwerkes und meine Temp ist logisch 1 .... Mit der Static Variable passiert doch das gleiche oder?

Gruß

 

[TP-Inc]

Bei Temp befolge ich einfach folgende Regel.
Wird etwas in jedem Zyklus zugewiesen und später (weiter unten) im selben Zyklus gelesen nehme ich Temp. Sobald etwas gesetzt wird, oder weiter oben (nächster Zyklus) gelesen wird nehme ich Static.

Wenn man verstanden hat wie der zyklische Ablauf einer SPS funktioniert erübrigt sich die Frage eigentlich.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

bevor der nächste Zyklus gestartet wird, müsste doch meine Temp wieder 0 sein

Über welche Steuerung redest du denn?

Bei TIA gibt es hier noch Unterschiede zwischen optimierten und nicht optimierten Bausteinen. Du solltest dich nie darauf verlassen,
dass eine temporäre Variable am Zyklusbeginn mit 0 oder FALSE belegt ist.

Mal ein Beispiel:

Beschreibung
Bei nicht optimierten Bausteinen werden die Werte temporärer Variablen nicht initialisiert, also mit Zufallswerten belegt, wenn sie im Baustein vor ihrer Verwendung nicht initialisiert werden. Variablen im temporären Bereich stehen nur innerhalb eines Zyklus zur Verfügung.

Quelle: Wie können Sie in STEP 7 (TIA Portal) Strukturen in optimierten Speicherbereichen bei der S7-1500 initialisieren?

 

[MFreiberger]

[..] ist die Frage ob es ein Beispiel (also einen Anwendungsfall) gibt, bei welchen eine Temp Variable mehr Sinn macht als eine Static.

Also, mit einer TempVariablen spare ich Speicherplatz. Die Steuerung reserviert bei Aufruf des jeweiligen Bausteins einen Speicherbereich, den sie wieder freigibt, wenn der Baustein beendet wird.
Zudem muss ich keinen FB (und damit für jeden FB-Aufruf einen weiteren Instanz-DB) programmieren. Multiinstanzen lasse ich jetzt mal außen vor.

Es gilt:
Was mit einer TempVariablen geht, geht auch mit einer StaticVariablen (automatische 0-Initialisierung durch die Steuerung mal außen vor (auch weil nicht ganz konsistent, also abhängig von Steuerung und DB-Attributen)).
Was mit einer StaticVariablen geht (Werte/Zustand merken) geht NICHT mit einer TempVariablen.

VG
MFreiberger

 

[PN/DP]

ob es ein Beispiel (also einen Anwendungsfall) gibt, bei welchen eine Temp Variable mehr Sinn macht als eine Static.

Arbeitsspeicher-Speicherplatz sparen durch Verwendung gemeinsam genutzten Speichers, der sich dann aber nichts für die Instanz merken kann, weil er außerhalb der Instanz von anderen Programmteilen benutzt wird.

Nehmen wir mal an, dass sich in meinem FB 10 KOP Netzwerke befinden. Im ersten Netzwerk wird meine Temp zugewiesen (kein (S) sondern nur --( )-- ). Im letzten Netzwerk (Nr 10) wird etwas mit der Temp Variable gemacht. Also wenn 1 dann setze etwas zurück --(R)-- in dem Fall. Direkt im Anschluss bevor der nächste Zyklus gestartet wird, müsste doch meine Temp wieder 0 sein

erstens setzt dein Baustein die Variable nur "vielleicht" zurück, und zweitens wird der Speicherbereich der TEMP-Variablen beim Verlassen des Bausteins freigegeben für die Benutzung durch andere Programmteile - und was die damit machen oder gemacht haben, kann dein Baustein beim nächsten Durchlauf nicht wissen. Also unbekannter Inhalt!
Dass bei bestimmten SPS unter bestimmten Bedingungen freundlicherweise (und unnötigerweise) für die unachtsamen oder ungebildeten Programmierer der TEMP-Speicher mit bestimmten Werten initialisiert wird, brauchst du dir besser nicht merken. Einfach merken: TEMP-Speicher VOR dem Lesen generell selbst etwas zuweisen. Dann ist man auf der sicheren Seite. Und meistens macht das noch nicht mal zusätzliche Arbeit.

 

[Martin2XK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke mir sind Static Variablen generell lieber. Es ist also nicht falsch, wenn ich Temp etwas seltener verwende ...

 

[DCDCDC]

Statische Variablen verwende ich auch dort, wo auch temporäre in Ordnung wären, ich aber gerne im DB den Status sehen möchte, ohne dass ich die Funktion öffnen und dort auch online gehen muss.

Alles andere was ich nicht benötige oder nur hin und her geschubst wird, bleibt im temp

 

[MFreiberger]

Und, wenn man eine Funktion 500x aufruft und darin zwei Positionswerte (dint) in static statt local zwischenspeichert, hat man schon 4kByte statt 8Byte verbraten, ohne, dass man etwas gewonnen hätte.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

.... Mit der Static Variable passiert doch das gleiche oder?

Ja, was zwischen dem Anfang und dem Ende eines Bausteins mit einer Variablen passiert, ist bei TEMP- und bei STAT-Variablen identisch, will sagen, es ist unerheblich, ob es eine TEMP- oder STAT-Variable ist.
Der Unterschied passiert nach dem Ende des Bausteins bis zum Anfang desselben Bausteins bei seinem nächsten Aufruf.
Die TEMP-Variablen leiden unter GedächtnisVerlust und man kann/darf sich nich nicht darauf verlassen, dass der aktuelle Zustand der Variablen am Anfang des Bausteins noch dem Zustand entspricht, den die Variable am Ende des Durchlaufs durch den Baustein beim vorherigen Aufruf hatte.
TEMP-Variablen sind zu Beginn eines Bausteins entweder wohl definiert (z.B. radikal gelöscht) oder rein "Zufalls-abhängig". In der Praxis heisst "Zufalls-abhängig", dass die Zustände meistens recht gut reproduzierbar sind. Deshalb bleibt es oft lange Zeit unbemerkt, wenn man vergessen hat, einer TEMP-Variablen einen Wert zuzuweisen, bevor man diese Variable abfragt.
STAT-Variablen braucht man, wenn Variablen ihren Inhalt unverändert beibehalten müssen zwischen dem Aufruf eines Bausteins und seinem nächsten Aufruf (derselben Instanz). Globale Variablen haben auch diese Fähigkeit, sind aber nicht immer die erste Wahl für solche Zwecke.
Immer, wenn es darum geht, stattfindende Veränderungen festzustellen, muss man einen aktuellen Zustand mit einem vorausgegangenen Zustand vergleichen. Das geht aber nur, wenn man daran gedacht hat, sich rechtzeitig den Zustand zuverlässig abzuspeichern, bevor er zum "vorausgegangenen" Zustand wird bzw. geworden ist. FlankenErkennung ist ein MusterBeispiel dafür, dass eine TEMP-Variable - also eine "ohne Gedächtnis" - den gewünschten Zweck NICHT erfüllen kann.
Man kann sich aber auch andere Dinge in STAT-Variablen merken. ZählerStände oder in welchem Schritt eine SchrittKette gerade aktiv ist u.s.w..

Wer braucht TEMP-Variablen? Eigentlich niemand. Hat man genügend STAT-Variablen, so muss man sich keinen Kopf machen, ob STAT nötig ist oder TEMP es genauso tut. Hat man aber nicht genügend STAT-Variablen, wie es z.B. in S5 der Fall war, so kann man schon auf die Idee kommen, einen Teil des Speichers effektiver - weil mehrfach(!) - zu nutzen. "SchmierMerker" nannte man diesen Bereich damals, weil er bevorzugt als "SchmierZettel" für NebenRechnungen und ZwischenErgebnisse, also für "kurzlebige" Angelegenheiten, benutzt wurde.
Spätestens bei umfangreichen Projekten ist es aber durchaus angenehmer und übersichtlicher, wenn man die Vielzahl der Variablen in kurzlebig und langlebig einteilen kann. Und wenn man zusätzlich noch leicht erkennen kann, ob man gerade kurzlebig oder langlebig vor sich hat.
Um gängige ProgrammierFehler vermeiden zu können, muss man sich stets Gedanken darüber machen, welche (wenigen?) Variablen langlebig sein müssen und welche (vielen?) kurzlebig sein dürfen (und es dann sein auch sollten).
Das Lesen von Programmen - egal, ob es nun fremde Machenschaften sind oder eigene - ist schwer genug. Man muss sich und anderen das Leben nicht noch schwerer machen.
Egoismus pur: mir hilft es bzw. gibt es ein beruhigendes Gefühl, wenn ich spüren kann "hier hat sich jemand genau überlegt, ob TEMP oder STAT".

 

[PN/DP]

mir sind Static Variablen generell lieber. Es ist also nicht falsch, wenn ich Temp etwas seltener verwende ...

Noch ein Argument, warum man NICHT Static Variablen verwenden sollte, wenn es nicht nötig ist: der Inhalt von Static Variablen kann von außerhalb des Bausteins absichtlich oder unabsichtlich verändert werden. Viel Spaß beim suchen, welcher Programmteil oder welches vernetzte Gerät (HMI, Visu, andere SPS!, ...) die Werte in den Variablen überraschenderweise überschreibt!
Auf TEMP Variablen kann nicht so leicht von außerhalb zugegriffen werden. Das geht nur aus den (wenigen) Bausteinen (FB, FC), die der Baustein selbst aufruft.

 

[Blockmove]

Noch ein Argument, warum man NICHT Static Variablen verwenden sollte, wenn es nicht nötig ist: der Inhalt von Static Variablen kann von außerhalb des Bausteins absichtlich oder unabsichtlich verändert werden. Viel Spaß beim suchen, welcher Programmteil oder welches vernetzte Gerät (HMI, Visu, andere SPS!, ...) die Werte in den Variablen überraschenderweise überschreibt!
Auf TEMP Variablen kann nicht so leicht von außerhalb zugegriffen werden. Das geht nur aus den (wenigen) Bausteinen (FB, FC), die der Baustein selbst aufruft.

Schreibzugriffe über HMI und Kommunikation auf Instanzdaten kannst du in TIA sperren bzw. musst du freigebn. Eben je nachdem wie deine Voreinstellungen sind. Ich persönlich verwende Temp mittlerweile recht selten. Bei Stat habe ich halt in der Deklaration alles beieinander.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wieviele Jahrzehnte hat es gedauert, bis die neumodernen TIA-Programmierer vor solchen Fremd-Beeinflussungen geschützt wurden? Und die TIA-Programmierer verlassen sich nun darauf, daß das auch wirklich immer funktioniert, und ahnen vielleicht auch gar nicht, daß sowas manchmal möglich ist ... im Gegenteil, sie wollen PUT/GET der Einfachhheit halber am liebsten verwenden, und denken, damit erlauben sie nur die eigenen gewünschten Schweinereien...

 

[schwimmer]

Auf TEMP Variablen kann nicht so leicht von außerhalb zugegriffen werden. Das geht nur aus den (wenigen) Bausteinen (FB, FC), die der Baustein selbst aufruft.

Statische Variablen verwende ich auch dort, wo auch temporäre in Ordnung wären, ich aber gerne im DB den Status sehen möchte, ohne dass ich die Funktion öffnen und dort auch online gehen muss.

Da zeigen sich wieder die zwei Seiten der Medaille. Nehme ich TEMP Variablen, kann ich auch selbst nicht mehr komfortabel drauf zugreifen, wie DCDCDC in #7 schon erwähnt hat, im DB, der Variablentabelle oder wenn ich mal etwas über einen längeren Zeitraum mitschreiben muss (z.B. externer Datenlogger)

 

[MFreiberger]

Da zeigen sich wieder die zwei Seiten der Medaille. Nehme ich TEMP Variablen, kann ich auch selbst nicht mehr komfortabel drauf zugreifen, wie DCDCDC in #7 schon erwähnt hat, im DB, der Variablentabelle oder wenn ich mal etwas über einen längeren Zeitraum mitschreiben muss (z.B. externer Datenlogger)

Aber es kann doch wohl nicht das Problem sein, sich Gedanken darüber zu machen, ob es sinnvoll ist eine Temp- oder eine StaticVariable zu nutzen? Die Vor- und Nachteile bzw. der jeweilige Verwendungszweck sind doch (spätestens seit diesem Thread) bekannt.

Wenn man "sauber" programmiert, sollte man nicht von außen auf einen Instanz-DB zugreifen wollen oder müssen. Stattdessen könnte man IN/OUT verwenden und Variablen eines Global-DB daran programmieren.

Und wenn man diese Art von "Komfort" gerne haben möchte, kann man das ja so programmieren. Man muss sich nur über die Probleme, die auftreten KÖNNEN im klaren sein. Auch, dass so ein Programm mit unter schwerer verständlich ist, ist ja kein KO-Kriterium. Aber, zumindest bei uns, müssen auch Servicetechniker, die nicht tagtäglich programmieren, mal etwas im Programm nachvollziehen können.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber es kann doch wohl nicht das Problem sein, sich Gedanken darüber zu machen, ob es sinnvoll ist eine Temp- oder eine StaticVariable zu nutzen?

Sehe ich auch so

 

[schwimmer]

Aber es kann doch wohl nicht das Problem sein, sich Gedanken darüber zu machen, ob es sinnvoll ist eine Temp- oder eine StaticVariable zu nutzen?

Was ich mit meinem Post ja auch nicht behauptet habe und auch nicht wollte.

Auch, dass so ein Programm mit unter schwerer verständlich ist, ist ja kein KO-Kriterium.

Ob jetzt die TEMP oder STATIC - Variablen verwendet werden, macht aber nicht unbedingt einen Unterschied wie gut oder schwer das Programm für einen Dritten verständlich ist.

 

[PN/DP]

Ob jetzt die TEMP oder STATIC - Variablen verwendet werden, macht aber nicht unbedingt einen Unterschied wie gut oder schwer das Programm für einen Dritten verständlich ist.

Es macht aber einen Unterschied, wie gut und wie zentral es beobachtbar ist.

 

[schwimmer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es macht aber einen Unterschied, wie gut und wie zentral es beobachtbar ist.

Deswegen arbeite ich eigentlich lieber mit STATIC-Variablen, zumal bei diesen eben auch die Möglichkeit besteht sie mal eben schnell zu forcen, wenn es während der IBN notwendig ist.
Bei Standartbausteinen, die immer wieder verwendet werden und die keiner mehr anlangen muss, sieht es natürlich anders aus.

 

[MFreiberger]

… und, ob man von außen auf die static zugreift. Dadurch wird es definitiv schwerer verständlich

 

[schwimmer]

… und, ob man von außen auf die static zugreift. Dadurch wird es definitiv schwerer verständlich

Da stimme ich dir zu. Alles was den Baustein verlässt wird bei mir auch über OUT bzw. IN/OUT gemacht.