# Beckhoff Twincat PLC - Adressfreie Variablen definieren / retain-persistente Var.



## Gerri (19 Februar 2009)

*Hallo, als TwinCat Anfänger habe ich eine wahrcheinlich eher simple Fragen zur Variablendefinition. *

*1.)*

*Wo bzw. Wie kann man Merker adressfrei definieren bzw. ist das überhaupt so möglich?*

*2.)*

*Wo liegt der Unterschied zwischen Retain und Persistenten Variablen?*


----------



## trinitaucher (19 Februar 2009)

Gerri schrieb:


> *Wo bzw. Wie kann man Merker adressfrei definieren bzw. ist das überhaupt so möglich?*


Gegenfrage:
Wozu benötigst du solche Merker?
In TwinCAT kann man dafür einfach Variablen nehmen.

Richtige "Merker" in TwinCAT sind mit Adressen verbunden, aber sind eigentlich nicht wirklich notwendig. Außer für einige Bibliotheken, wo der Konfirmität halber Merker definiert sind. Z. B. bei der Modbus-Bibliothek weiß ich's.


Gerri schrieb:


> *Wo liegt der Unterschied zwischen Retain und Persistenten Variablen?*


Weiß ich auch nicht so richtig. PERSISTENT ist angeblich "moderner". Ich nutze nur persistens.


----------



## Ralle (19 Februar 2009)

Gerri schrieb:


> *Wo liegt der Unterschied zwischen Retain und Persistenten Variablen?*



Sieh mal hier und im weiterführenden Link: http://www.sps-forum.de/showpost.php?p=183327&postcount=2


----------



## Gerri (19 Februar 2009)

@trinitaucher: Hab das dann wohl falsch verstanden adressfreie Merker sind gleich adressfreie Variablen. Ob Merbit, Merkbyte o.ä. ist dabei nebensächlich. 
Wie definiert man nun Variablen?


----------



## trinitaucher (19 Februar 2009)

Gerri schrieb:


> Wie definiert man nun Variablen?


Hä?  
Vielleicht schonmal in die Doku geschaut?
http://infosys.beckhoff.com/index.php?content=content/1031/tcplccontrol/html/tcplcctrl_sample.htm


----------



## Gerri (19 Februar 2009)

sind das nicht temporäre Variablen, also nur innerhalb dieses Prg gültig? Ich rede von Globalen Variablen die im ganzen Projekt bearbeite werden können.

Vielleicht bin ich auch zu sehr von Step 7 beeinflusst.


----------



## Ralle (19 Februar 2009)

Vielleicht hilft dir das: http://infosys.beckhoff.com/content/1031/tcplccontrol/html/tcplcctrl_resglobvar.htm


----------



## Der Nils (19 Februar 2009)

Moin

unter Ressourcen / Globale Variablen
z.B.
VAR_GLOBAL

Test_Eingang      AT%I*  :BOOL;
Test_Ausgang     AT%Q* :BOOL;

Test_Virtuell       AT%MD48 :BOOL;

END_VAR


----------



## Gerri (19 Februar 2009)

Ok, ich denke ich weiss nun was ich wissen wollte. Man Kann in der Globalen Variablenliste den Variablen eine Adresse zuordnen oder eben das Feld Adresse auch leer lassen. 

Ich hab da wohl zu kompliziert gedacht!

MV


----------



## trinitaucher (19 Februar 2009)

Gerri schrieb:


> sind das nicht temporäre Variablen, also nur innerhalb dieses Prg gültig? Ich rede von Globalen Variablen die im ganzen Projekt bearbeite werden können.


TwinCAT ist ein bisschen so wie objektorientierte Programmierung.
Es gibt Programme, Funktionsbausteine (ähnlich wie "Klassen", bekannt aus Hochsprachen) und Funktionen.
Ein Programm kann mehrere Funktionsbausteine enthalten.
Variablen können "lokal", also entweder in den Funktionsbausteinen oder Programmen deklariert werden. Dann haben sie *nur dort* Gültigkeit, wo sie deklariert wurden.
Oder du deklarierst "globale Variablen". 
Registerkarte "Ressourcen" => "Globale Variablen". Diese Variablen haben im ganzen Projekt Gültigkeit.

Adressen benötigst du nur bei Verknüpfungen mit der Hardware.


Gerri schrieb:


> Vielleicht bin ich auch zu sehr von Step 7 beeinflusst.


Schlimm, schlimm, schlimm ....


----------



## zotos (19 Februar 2009)

Gerri schrieb:


> sind das nicht temporäre Variablen, also nur innerhalb dieses Prg gültig? Ich rede von Globalen Variablen die im ganzen Projekt bearbeite werden können.
> 
> Vielleicht bin ich auch zu sehr von Step 7 beeinflusst.



???

Auch für einen Step7 Programmierer sollten die Begriffe:

"lokale oder globale" und "temporäre oder statische" Variable klar sein.

----
Zugriff:

Lokal: Sind nur innerhalb des einen PRGs/FCs/FBs zugänglich (bzw. sollten es sein)

Global: Ja die sind eben von überall zugänglich.

----
Lebensdauer:

Temporär: Nur für den einen Aufruf gültig. Also im nächsten SPS Zyklus sind die Daten die man vorher darein geschrieben hat futsch. Klassisches Beispiel die lokalen Variablen von FCs.

Statisch: Diese Variablen behalten den Wert den man ihnen zugewiesen hat auch für die folgenden SPS Zyklen. 

----

Variablen werden in den Köpfen der PRGs/FBs/FCs oder eben wie bereits weiter oben (von Nils) beschrieben im Bereich der globalen Variablen deklariert.

----

Einige Unterschiede zu Siemens:
Es gibt PRGs also Programme mit lokalen statischen Variablen ohne das man davon eine Instanz bilden muss.
Variablen müssen keiner Adresse zu geordnet werden. Das macht das System selbst. 
Eine Instanz eines FBs legt man genau so an wie eine Variable.
Man kann Symbolische Konstanten verwenden die man wärend der Laufzeit nicht verändern kann.


----------



## zotos (19 Februar 2009)

Und zu Retain und Persistent hier mal was aus der Hilfe:


----------



## Gerri (19 Februar 2009)

temporäre und statische Variablen sind in Step7 lokale Variablen.

Da ich bis Jetzt in TwinCat keine Instanzen benötigt habe, war mir nicht bekannt ob bzw. wie man diese definiert.

Das TwinCat den Wert der lokalen Variablen über den aktuellen Zyklus hinaus behält war mir nicht klar, find ich aber gut.

"Variablen werden in den Köpfen der PRGs/FBs/FCs oder eben wie bereits weiter oben (von Nils) beschrieben im Bereich der globalen Variablen deklariert." 

-> In den Köpfen also lokal, im Bereich der globalen Variablen als global (macht ja auch Sinn so)


----------



## trinitaucher (19 Februar 2009)

@ zotos:
Wo deklarierst du in TwinCAT bitte "Temporäre" oder "Statische" Variablen?
Das wäre mir neu.

@Gerri:


> Das TwinCat den Wert der lokalen Variablen über den aktuellen Zyklus hinaus behält war mir nicht klar, find ich aber gut.


Nicht dass du das falsch verstehst. Die Variablen (generell ALLE Variablen, außer CONSTANT) behalten solange ihren Wert, bis ihnen ein anderer Wert zugewiesen wird, oder z.B. durch einen Reset die Werte zurückgesetzt werden.
Das Variablen von Funktionen jedes Mal ihren Wert verlieren ergibt sich aus der Ausführungsvorschrift für Funktionen selbst (keine internen Zustände).


----------



## zotos (19 Februar 2009)

trinitaucher schrieb:


> @ zotos:
> Wo deklarierst du in TwinCAT bitte "Temporäre" oder "Statische" Variablen?
> Das wäre mir neu.


Temporär:
Die lokalen Daten im Kopf eines FCs sind temporäre Variablen.

Statisch:
Die lokalen Variablen der FBs und PRGs so wie alle globalen Variablen sind statische Variablen.


----------



## MarkusP (20 Februar 2009)

> Lokal: Sind nur innerhalb des einen PRGs/FCs/FBs zugänglich (bzw. sollten es sein)


@Zotos,
hier muss ich nun mal genauer nachfragen. Du sagst "sollten es sein". Man kann jedoch auch auf lokale Variablen überall zugreifen, z.B. in der Form PRG_xxxx.MeineLokaleVar

Ohne eine Diskussion loszubrechen ob man dies tun soll, ist meine Frage, ob das ein Fehler ist (von Codesys bzw. TwinCAT) oder so gewollt ist.

Egal ob gewollt oder "programmiertechnisch schön", manchmal ist es doch sehr praktisch; ich hasse jede Variable immer GLOBAL anlegen zu müssen, entspricht doch eher den klassischen Programmiersystemen.

Danke für Deine (Eure) Rückmeldungen


----------



## trinitaucher (20 Februar 2009)

Zugreifen kannst du auf diese "internen" Variablen schon, aber ob es sinnvoll ist, sollte man sich überlegen.

Denn du wirst (logischerweise) immer den Wert dort vorfinden, der bei der letzten Ausführung des FBs oder PRGs dort hineingeschrieben wurde. Dann muss man sehen, wie ein solcher Zugriff das Verhalten beeinflusst. Insbesonders, wenn man schreibend zugreift.

Globale Variablen sind halt überall im Projekt gültig und können nur *einmalig* vorkommen.
Ein Aufruf ala FB.Variable ist immer *instanzgebunden*. Die Variable FB1.Variable ist dann natürlich ungleich FB2.Variable.

Wenn man auf globale Variablen verzichten möchte, aber eine ähnliche Funktionsweise benötigt, kann man auch VAR_IN_OUT verwenden. Man ist gezwungen diesen Ein-/ausgängen einen Wert zuzuweisen, hat aber quasi nur einen Speicherbereich. Ähnlich wie Pointer.


----------



## MarkusP (20 Februar 2009)

@trinitraucher
Schreibend zugreifen geht ohnehin nur, wenn die Variablen als VAR_INPUT oder wie du richtig beschreibst als VAR_IN_OUT deklariert sind. (außer über Pointer, damit geht es immer)
Aber eigentlich ist die "lokale" Variable eigentlich keine "richtige lokale" Variable? (siehe vorheriges Zitat von Zotos)
Ich kenne lokale (private) Variablen u.a. von Hochsprachen früherer Zeiten. Die waren wirklich lokal, und außerhalb unerreichbar.
Ob's schön oder sinnvoll ist, sei dahingestellt.



> Globale Variablen sind halt überall im Projekt gültig und können nur *einmalig* vorkommen.


Variablen wie PRG_xxxx.MeineLokaleVariable können auch nur einmal vorkommen



> Ein Aufruf ala FB.Variable ist immer *instanzgebunden*. Die Variable FB1.Variable ist dann natürlich ungleich FB2.Variable.


Damit ist die Variable auch einmalig...

Schönen Abend


----------



## zotos (21 Februar 2009)

MarkusP schrieb:


> @Zotos,
> hier muss ich nun mal genauer nachfragen. Du sagst "sollten es sein". Man kann jedoch auch auf lokale Variablen überall zugreifen, z.B. in der Form PRG_xxxx.MeineLokaleVar
> 
> Ohne eine Diskussion loszubrechen ob man dies tun soll, ist meine Frage, ob das ein Fehler ist (von Codesys bzw. TwinCAT) oder so gewollt ist.
> ...



Ohne daraus eine groß Diskussion zu machen. Das muss wohl jeder für sich entscheiden ob es Sinnvoll ist oder nicht und zu welchem Grad man dies verwendet.

Ich selbst nutze den direkten Zugriff auf interne Variablen nicht gerne. Aber gerade bei kleinen Tests greif ich dann doch darauf zurück.

Die Frage ist doch wie übersichtlich ist das und wer findet sich da noch zurecht. Auf die Input und Output Variablen greife ich gerne direkt zu aber dann im unmittelbaren Zusammenhang so das man das auch direkt sehen kann. 

Ich denke nicht das es ein Fehler in CoDeSys ist. Zumal ja unterschieden wird ob man Schreibrechte hat oder nicht.
Eine Ausnahme ist da die Visu die auch direkt auf die Variablen zwischen VAR udn END_VAR schreibend zugreifen kann. Ich habe das auch schon verwendet und finde es trotzdem nicht gut. In produktiven Systemen nutze ich da eine Koppelstruktur.

Ich denke es gibt da kein schwarz oder weiß aber helles und dunkles grau. 

Alles Geschmackssache.


----------



## MarkusP (21 Februar 2009)

> Eine Ausnahme ist da die Visu die auch direkt auf die Variablen zwischen VAR udn END_VAR schreibend zugreifen kann. Ich habe das auch schon verwendet und finde es trotzdem nicht gut. In produktiven Systemen nutze ich da eine Koppelstruktur.


Dass die Visu hier eine Ausnahme darstellt, habe ich auch schon bemerkt, stellt schon ein gewisses Risiko dar, Werte ungewollt zu überschreiben. Ist also irgendwie nicht ganz durchgängig.

Danke für deinen Beitrag,

Schönes WE


----------



## Werner29 (24 Februar 2009)

MarkusP schrieb:


> Man kann jedoch auch auf lokale Variablen überall zugreifen, z.B. in der Form PRG_xxxx.MeineLokaleVar
> 
> Ohne eine Diskussion loszubrechen ob man dies tun soll, ist meine Frage, ob das ein Fehler ist (von Codesys bzw. TwinCAT) oder so gewollt ist.



Die Norm erlaubt das eigentlich nicht, CoDeSys bewusst schon. Also: ein gewollter Fehler. Wenn man sowas mal erlaubt hat, kann man es natürlich nie wieder verbieten.


----------



## MarkusP (24 Februar 2009)

Das nenne ich nun mal eine Antwort auf eine Frage.
Das war nämlich genau meine Frage.

Danke


----------



## Der Nils (25 Februar 2009)

Hallo

Wenn wir schon mal das Thema Variablen haben ....
es gibt ja Bausteine um Persistente Variablen zu schreiben oder zu lesen,
jetz hab ich aber nirgends gelesen ob das mit einem BC 9050 auch geht.

Ziel ist es das ein paar Sollwerte vom Typ ,,INT,, oder ,, REAL ,, in der Regelung nach dem Kaltstart erhalten bleiben.


----------



## Doofundstinkt (13 Mai 2010)

Hallo,

ich habe bei meiner Haussteuerung Variablen im Bereich "Globale Variablen" mit Adresse definiert:

    nOut_Temperatur_Sollwert_Schlafzimmer        AT%Q*: INT;
    nOut_Temperatur_Sollwert_Gaestezimmer       AT%Q*: INT;

Ziel ist es, dass im Bussystem die Solltemperaturen nach einem Stromausfall erhalten bleiben.

Die finde im Bereich "TwinCat_Configuration" inkl. Adresse wieder:

    .nOut_Temperatur_Sollwert_Schlafzimmer AT %QB1 : INT;
    .nOut_Temperatur_Sollwert_Gaestezimmer AT %QB2 : INT;

Bei einem Absturz des Bussystems haben sich da jetzt Phantasie- Temperaturen (-20.000 bis + 20.000) eingetragen. Diese möchte ich jetzt wieder in den normalen Bereich bringen (ca. 210)

Ich habe schon diverse sachen versucht, die Temperaturen anzupassen. Hierunter waren z.B. Werte forcen, Werte schreiben und ich hab mir auch ein kleines Programm geschrieben, welches die Werte zurücksetzen soll.

Welchen Tip könnt ihr mir noch geben, um die Temperaturen zurückzusetzen?

Kann ich die o.g. Adressen eigentlich manuell ändern? 
Im Bereich "TwinCat_Configuration" steht der Hinweis: (* Generated automatically by TwinCAT - (read only) *)
Ich möchte noch weitere Variablen definieren und das will noch nicht so richtig klappen:

(*Zeitsteuerung Raffstores*)

    Werktag_rauf                                AT%Q*:TOD;
    Werktag_runter                            AT%Q*:TOD;
    Samstag_rauf                                AT%Q*:TOD;
    Samstag_runter                            AT%Q*:TOD;
    Sonntag_rauf                                AT%Q*:TOD;
    Sonntag_runter                            AT%Q*:TOD;

Gruß

Ingo


----------



## Jolene0815 (14 Oktober 2016)

Werner29 schrieb:


> Die Norm erlaubt das eigentlich nicht, CoDeSys bewusst schon. Also: ein gewollter Fehler. Wenn man sowas mal erlaubt hat, kann man es natürlich nie wieder verbieten.



 Dann muss man ja auch gar nicht. Aber es spräche noch nichts gegen ein Mittel, welches lokale Variablen auch wirklich lokal macht, oder? Ein "private" oder was auch immer? Gibt es irgendetwas in der Art? 

 Ich bin nicht gerade sonderlich programmiererfahren und sitze gerade an meinem ersten TwinCAT-Projekt. 
 Vielleicht habe ich deshalb auch das Gefühl, tierisch ausgebremst zu werden. 

 VG,
 Alex


----------

