Verständnisfrage zu PERSISTENT RETAIN: Position speichern

Jörn · 3 März 2021

Moin,

ich hoffe die Frage klingt nicht zu blöd. Es geht um TwinCAT 3.1 (Build 4014.12) und die Beschreibung im InfoSys ist mal wieder ein wenig verwirrend.

Ich habe einen Hubtisch, um Bauteile in eine Förderstrecke einzuschleusen. Die Übergabeposition Hubtisch auf Ebene mit Förderstrecke ist nicht eine der Endlagen des Hubtisches, deshalb gibt es eine Übergabeposition. Der Wert der Übergabeposition steht in einer GVL namens GVL_Persistent:

Code:

VAR_GLOBAL PERSISTENT RETAIN
   rPosUebgabe:   LREAL := 13.4;   // Übergabeposition Hubtisch
END_VAR

Dieser Wert ist mechanisch bedingt und deshalb ändert der sich auch nicht. Er soll immer genau diesen Wert haben. Mein Kollege, der die Routine schrieb, deklarierte sie deshalb PERSISTENT RETAIN. Letztens musste ich etwas an der Hardware-Konfiguration ändern und nach dem Aktivieren der Konfiguration waren der Übergabewert plötzlich 0.0 und es stand auch 0.0 in der GVL_Persistent drin.

So, wie ich die Beschreibung im InfoSys verstanden habe (1), hätte die Variable rPosUebgabe eigentlich ihren Wert nicht ändern dürfen. Entweder hätte er auf dem aktuellen Wert von 13.4 bleiben müssen oder mit 13.4 "neu" initialisiert werden müssen. Das ist aber offensichtlich passiert. Ist das ein Fehler oder übersehe ich irgendwas?

Vielen Dank schonmal.

Gruß
Jörn

(1) https://infosys.beckhoff.com/index.php?content=../content/1031/tc3_plc_intro/2527625355.html&id=

JSEngineering · 3 März 2021

Moin,

die Ursache kenne ich nicht, aber in solch einem Falle deklariere ich die als CONSTANT:

https://infosys.beckhoff.com/index.php?content=../content/1031/tc3_plc_intro/2527625355.html&id=

Dann ändern die sich definitiv nicht und können auch nicht "versehentlich" geändert werden.

Gruß
Jens

oliver.tonn · 3 März 2021

Erstmal, wenn sich der Wert eh nicht ändert, warum nehmt Ihr nicht VAR GLOBAL CONSTANT?
Bei der Sache mit den persistenten und retain Daten ist so mancher schon auf die Nase gefallen. Soweit die SPS keinen NVRam Bereich hat werden die Werte in einer Datei gespeichert und beim nächsten Start wieder gelesen, aber ich habe schon öfters gehört, dass es da Probleme gegeben hat. Besser man ruft regelmäßig den FB WritePersistentData oder FB_WritePersistentData auf.

Jörn · 3 März 2021

JSEngineering schrieb:
... in solch einem Falle deklariere ich die als CONSTANT ...

Dann ändern die sich definitiv nicht ...

Top, genau das habe ich für diesen Anwendungsfall gesucht.

Ich hab noch ein paar andere Variablen in der GVL_Persistent gefunden, die ihren Wert besser behalten. Da stehen Daten der Bauteile drin, die auch nach einem RESET, Neustart, wasauchimmer, ... besser nicht zurückgesetzt werden. Gottlob war die Anlage beim Ändern der Konfiguration, was die persistenten Variablen gelöscht hat, leer. Ganz hinten hängt noch eine Datenbank des Kunden dran, von der ich Daten bekomme und zu der auch Daten zurückgemeldet werden (müssen).

Jörn · 3 März 2021

oliver.tonn schrieb:
Erstmal, wenn sich der Wert eh nicht ändert, warum nehmt Ihr nicht VAR GLOBAL CONSTANT?

Ist in Arbeit.

oliver.tonn schrieb:
Bei der Sache mit den persistenten und retain Daten ist so mancher schon auf die Nase gefallen. Soweit die SPS keinen NVRam Bereich hat werden die Werte in einer Datei gespeichert und beim nächsten Start wieder gelesen, aber ich habe schon öfters gehört, dass es da Probleme gegeben hat. Besser man ruft regelmäßig den FB WritePersistentData oder FB_WritePersistentData auf.

Das Datengeschubse passiert zum Glück nicht so häufig. Ich denke ich werde bei Erhalt neuer Daten einfach FB_WritePersistenData aufrufen und dann sollte es passen.

asci25 · 3 März 2021

Code:

VAR_GLOBAL PERSISTENT RETAIN

Das ist ja eine interessante Deklaration. Also entweder nehme ich Persistent oder Retain. Das hängt von der Steuerung ab.

Bei Persistenten Daten werden die Inhalte beim System-Stop auf die Festplatte geschrieben und beim System-Start wieder geladen. Bei einem plötzlichen Stromausfall kann natürlich nicht geschrieben werden. Jedoch liegt bei TwinCAT immer noch eine Sicherheitskopie vor, wenn die persistenten Daten schon einmal geschrieben wurden. Wichtig ist also vor dem Ausschalten das System sauber runterzufahren. Am besten geht das mit den Steuereungen, die eine 1-Sekunden-USV haben. Dafür muss der für die Steuerung vorgesehene USV-FB zyklisch im Main aufgerufen werden. Wenn der FB einen Stromausfall erkennt, stoppt das System, die Daten werden geschrieben und dann das Windows beendet.
Bei einer Steuerung mit einem Standard-Batterie-Pack, muss die USV so konfiguriert werden, dass bei einem Stromausfall ein Shutdown ausgeführt wird. Das ist nicht die Standard-Einstellung.
Ohne einer USV also immer das Windows bei Verwendung von persistenten Daten sauber runterfahren.

Retain verwende ich so gut wie gar nicht. Das hatte ich jetzt mal auf einer Wago-SPS, die hatte aber auch so genannten Retain-Speicher. Ich vermute, das entspricht dem so genannten NOV-Ram bei den Beckhoff-CPU's. Soweit ich weiß, muss der aber addresiert werden und dann im System-Manager verknüpft. Dann geht es auch ohne Stromausfallsicherung. Also eher was für die kleinen Steuerungen.

Ich persönlich fahre mit den persistenten Daten aber besser, weil bei mir schon gößere Datenmengen anfallen. Probleme habe ich selten. Und für den Notfall kann mein HMI regelmäßig Datensicherungen des persistenten Datenbereichs anlegen und die schnell wieder hochladen. Das ist übrigens auch sehr praktisch bei eine Erstinbetriebnahme einer neuen Anlage. Daten kopieren übertragen - läuft.

Mavorkit · 3 März 2021

asci25 schrieb:
Code:

VAR_GLOBAL PERSISTENT RETAIN

Das ist ja eine interessante Deklaration. Also entweder nehme ich Persistent oder Retain. Das hängt von der Steuerung ab.

Bei Persistenten Daten werden die Inhalte beim System-Stop auf die Festplatte geschrieben und beim System-Start wieder geladen. Bei einem plötzlichen Stromausfall kann natürlich nicht geschrieben werden. Jedoch liegt bei TwinCAT immer noch eine Sicherheitskopie vor, wenn die persistenten Daten schon einmal geschrieben wurden. Wichtig ist also vor dem Ausschalten das System sauber runterzufahren. Am besten geht das mit den Steuereungen, die eine 1-Sekunden-USV haben. Dafür muss der für die Steuerung vorgesehene USV-FB zyklisch im Main aufgerufen werden. Wenn der FB einen Stromausfall erkennt, stoppt das System, die Daten werden geschrieben und dann das Windows beendet.
Bei einer Steuerung mit einem Standard-Batterie-Pack, muss die USV so konfiguriert werden, dass bei einem Stromausfall ein Shutdown ausgeführt wird. Das ist nicht die Standard-Einstellung.
Ohne einer USV also immer das Windows bei Verwendung von persistenten Daten sauber runterfahren.

Retain verwende ich so gut wie gar nicht. Das hatte ich jetzt mal auf einer Wago-SPS, die hatte aber auch so genannten Retain-Speicher. Ich vermute, das entspricht dem so genannten NOV-Ram bei den Beckhoff-CPU's. Soweit ich weiß, muss der aber addresiert werden und dann im System-Manager verknüpft. Dann geht es auch ohne Stromausfallsicherung. Also eher was für die kleinen Steuerungen.

Ich persönlich fahre mit den persistenten Daten aber besser, weil bei mir schon gößere Datenmengen anfallen. Probleme habe ich selten. Und für den Notfall kann mein HMI regelmäßig Datensicherungen des persistenten Datenbereichs anlegen und die schnell wieder hochladen. Das ist übrigens auch sehr praktisch bei eine Erstinbetriebnahme einer neuen Anlage. Daten kopieren übertragen - läuft.

Hi asci25,

Persistent ist wie du schon geschrieben hast, dass die Daten beim Neustart erhalten bleiben, Retain bewirkt, dass die Variablen beim Übertragen des geänderten Programmes (kein online Change) ihren Wert behalten. Ich benutze das z.B. in Lüftungsanlagen oder ähnlichem, sonst würde der extrem träge Regler jedesmal wieder bei 0 anfangen. So vermeide ich hier dann das Schwingen beim Anfang.

Gruß

Mavorkit

Gesendet von meinem SM-G950F mit Tapatalk

Chräshe · 7 März 2021

oliver.tonn schrieb:
Besser man ruft regelmäßig den FB WritePersistentData oder FB_WritePersistentData auf.

Der Tipp ist etwas kritisch zu betrachten. Das „regelmäßige Speichern“ ist kein Problem, wenn 5x am Tag gewisse Einstell-Werte gesichert werden.
Wenn man allerdings meint, sicherheitshalber jede Minute den FB WritePersistentData anstoßen zu müssen, reduziert das die Lebensdauer vom Speicher drastisch.
Falls die vorhergesagte Lebenserwartung von 1.000.000 Zyklen für Flash-Speicher noch aktuell ist, würde das Speichern alle 60 Sekunden den Ausfall in 1,9 Jahren sehr wahrscheinlich machen.

https://www.sps-forum.de/codesys-un...l?49643-FAQ-alles-rund-um-TwinCAT=#post362870

oliver.tonn · 7 März 2021

Chräshe schrieb:
Der Tipp ist etwas kritisch zu betrachten. Das „regelmäßige Speichern“ ist kein Problem, wenn 5x am Tag gewisse Einstell-Werte gesichert werden.
Wenn man allerdings meint, sicherheitshalber jede Minute den FB WritePersistentData anstoßen zu müssen, reduziert das die Lebensdauer vom Speicher drastisch.
Falls die vorhergesagte Lebenserwartung von 1.000.000 Zyklen für Flash-Speicher noch aktuell ist, würde das Speichern alle 60 Sekunden den Ausfall in 1,9 Jahren sehr wahrscheinlich machen.

100% Ackn. zu dem Vorschlag/der Kritik von Chräshe. Das Wort regelmäßig war auch etwas ungünstig gewählt von mir. Ich meinte damit nicht, dass man den FB alle paar Sekunden aufrufen soll, sondern, wenn sich was ändert.
Allerdings bezieht sich die Zyklusangabe auf eine einzelne Zelle und der Speichercontroller verhindert, soweit die Karte nicht rappel voll ist, dass Dateien immer an die selbe Stelle geschrieben werden.

JSEngineering · 7 März 2021

Meine Erfahrung hat aber auch gezeigt - mit anderen Speichermodulen - dass der Flash durchaus sehr langsam werden kann. Denn es werden “gelöschte“ Zellen nicht immer frei gegeben.
Erst eine Formatierung macht den Flash wieder schnell, sprich es stehen genügend freie Zellen für den Controller zur Verfügung, um schreiben zu können, ohne Daten umzuorganisieren.

Also es muß nicht gleich kaputt sein, aber irgendwann dauert das Schreiben von ein paar kB dann eine halbe Minute...

Guga · 8 März 2021

Jetzt muss ich auch noch meinen Senf loswerden:

Code:
VAR_GLOBAL PERSISTENT RETAIN

Die doppelte Definition ist Quatsch.
In TC2 erfolgte beides in einer Datei auf der Festplatte. Bei Retain waren die Daten und auch Checks anders codiert und es gab ein Dominanzverhalten (keine Ahnung mehr welches der beiden Varianten dominant war).
In TC3 ist der Mechanismus von RETAIN komplett neu. Es wird zyklisch auf einen (internen) NovRam geschrieben, und hier gibt es die Daten jeweils vom letzten und vorletzten Abbild um Datenkonsistenz zu garantiere. Es braucht aber den internen NovRAM und die Verlinkung. Aber auch hier muss eine Definition Dominant sein.

Guga

oliver.tonn · 8 März 2021

Guga schrieb:
Jetzt muss ich auch noch meinen Senf loswerden:
[/COLOR]
[/COLOR]
Die doppelte Definition ist Quatsch.
In TC2 erfolgte beides in einer Datei auf der Festplatte. Bei Retain waren die Daten und auch Checks anders codiert und es gab ein Dominanzverhalten (keine Ahnung mehr welches der beiden Varianten dominant war).
In TC3 ist der Mechanismus von RETAIN komplett neu. Es wird zyklisch auf einen (internen) NovRam geschrieben, und hier gibt es die Daten jeweils vom letzten und vorletzten Abbild um Datenkonsistenz zu garantiere. Es braucht aber den internen NovRAM und die Verlinkung. Aber auch hier muss eine Definition Dominant sein.

Guga

Bei TC3 bringt die doppelte Definition tatsächlich nichts, aber ansonsten stimmt die Aussage zu TC3 nur bedingt. Nicht alle Beckhoff CPUs haben ein NVRAM, die CX50X0 und CX51X0 haben z.B. keins und da werden die Daten auch weiterhin in einer Datei abgelegt, was hier nachzulesen ist und da wird gar nichts zyklisch abgelegt. Im Falle eines Stromausfalls werden die Daten bei Nutzung des FBs der Sekunden USV automatisch gesichert, aber ich meine bei einem Neustart des CX über das Startmenü eben nicht.
Bei TC2 meine ich mich zu erinnern, dass es früher mal so war, dass PERSISTENT und RETAIN einen unterschiedlichen "Funktionsumfang" hatten und man deshalb in gewissen Situationen beide nutzen musste.

Jörn · 10 März 2021

Kurze Rückinfo:

Der verbaute IPC hat kein NVRAM, aber es gibt eine USV (mit dem Akku-Pack C9900-U330). Alle hardwareabhängigen Werte, die also nicht (mehr) geändert werden, sind nun CONSTANT und alles andere PERSISTENT. Der Test, ob die USV auch tut was sie soll, erfolgt heute zu Feierabend.

Gruß
Jörn

asci25 · 10 März 2021

Hast Du die USV auch so konfiguriert, das der PC runterfährt? Sonst wird das nichts.

Jörn · 11 März 2021

asci25 schrieb:
Hast Du die USV auch so konfiguriert, das der PC runterfährt?

Kann ich nicht sagen, weil aktuell der Bildschirm bei Stromausfall nicht von der USV mit versorgt wird. Ausgegangen ist der PC nach 2 Minuten aber.

Die Einstellung Max. Zeit auf Akkuspannung vor kritischen Alarm steht aber auf 2 Minuten, d.h. es sollte passen.

oliver.tonn · 11 März 2021

Da es keine Sekunden USV ist bin ich mir nicht sicher, ob der USV FB da überhaupt etwas bringt. Mit dieser Form der USV habe ich noch nie gearbeitet.

Jörn · 11 März 2021

Für diese USV gibt es unter Start -> Beckhoff -> USV Konfiguration ein entsprechendes Tool (1). Da kann man unter Alarmkonfiguration Max. Zeit auf Akkuspannung vor kritischen Alarm einstellen. Wenn die abgelaufen ist, wird der PC automatisch heruntergefahren.

(1) https://infosys.beckhoff.com/conten...html/tcups_becfdlg.htm?id=7390721842132975312

asci25 · 11 März 2021

oliver.tonn schrieb:
Da es keine Sekunden USV ist bin ich mir nicht sicher, ob der USV FB da überhaupt etwas bringt. Mit dieser Form der USV habe ich noch nie gearbeitet.

Nein, diese FB's sind CPU-Spezifisch und kommen auf den Embedded-PC mit 1Sekunden-USV z.B der 5000er und kleiner, und teilweise auch bei den CX2000'er zum Einsatz. Der FB dient nur zum schnellen Runterfahren des TwinCAT-Systems bei Spannungsausfall. Das funktioniert da sehr gut. Bei dem Battery-Pack geht man anders vor.

Anton234 · 6 August 2023

Bei der aktuellen TwinCAT Version 3.1 wird in Retain und Persistent unterschieden.

Hat der Controller einen Nov-RAM, werden Retain-Variablen angelegt und mittels eines Retain Handlers in den Nov-Ram geschrieben (siehe Handbuch des Controllers).
Hat der Controller eine "1-Sekunden USV" (muss ab Werk eingebaut sein), dann werden Persistente Variablen angelegt. Hier ist der Aufruf des Controller spezifischen Bausteins erforderlich Bsp. FB_S_UPS_CX9020_U900 (ebenfalls im Handbuch gut beschrieben). Die Persistenten Daten werden auf der Speicherkarte abgelegt. Bsp: Hard Disk/TwinCAT/3.1/Boot/PLC/Port_851.bootdata

Verständnisfrage zu PERSISTENT RETAIN: Position speichern

Level-1

Level-3

Level-3

Level-1

Level-1

Level-2

Level-1

Level-2

Level-3

Level-3

Level-2

Level-3

Level-1

Level-2

Level-1

Level-3

Level-1

Level-2

Level-2

Similar threads

Wir schützen deine Privatsphäre