Persistente Variablen behalten ihren Wert bei einem erneuten Laden der Applikation, nach einem Download, Warmstart oder Kaltstart.

Für die Verlängerung der Lebensdauer ist ein spezieller nichtflüchtiger Speicherbereich auf der Steuerung nötig, beispielsweise als NVRAM oder USV. Das Sichern der Daten in einem solchen Speicher erfordert keinen zusätzlichen Zeitbedarf, was ein Vorteil gegenüber dem Datenerhalt mit Persistence Manager ist. Wenn die Steuerung keine Hardware-Unterstützung bietet, werden die Daten üblicherweise in einer Datei gespeichert. Dann bleiben die Daten zwar erhalten, wenn Sie die Steuerung korrekt herunterfahren. Bei einem Stromausfall oder einem "Stecker ziehen" kommt es aber zum Datenverlust.

Verhalten

Persistente Variablen werden also nur dann neu initialisiert, wenn Sie die Steuerung in den Auslieferungszustand zurücksetzen, beispielsweise wenn Sie den Befehl „Online  Reset Ursprung“ wählen.

Wenn Sie dagegen einen erneuten Download der Applikation ausführen, bleiben die persistierten Daten nach Möglichkeit erhalten. Das hängt davon ab, wie tiefgreifend die Änderungen waren, die zum Download führten. Eine Änderung des Applikationsnamens führt immer zu einer vollständigen Neuinitialisierung. Änderungen der Implementierungen führen nie zu einer Neuinitialisierung: Die Datenpersistenz bleibt vollständig erhalten. Änderungen der Deklarationen führen zu einer Initialisierung nur der neuen Variablen bei Persistenz der bestehenden Variablen, wenn Folgendes beachtet wird: Sie ändern die Deklarationen so, dass die persistente Variablenliste konsistent bleibt. Das ist der Fall, wenn Sie eine neue Variable hinzufügen oder eine bestehende löschen. Inkonsistenzen können entstehen, wenn Sie die Bezeichner oder die Datentypen der vorher deklarierten, persistenten Variablen bearbeiten und ändern.

Mechanismus beim Download

Wenn Sie im Persistenzeditor die Variablenliste bearbeiten, bewirken Sie, dass die Variablenliste nicht so wie im Editor dargestellt gespeichert wird, sondern automatisch nachbearbeitet wird, bevor sie gespeichert wird.

Bei der Nachbearbeitung wird eine Variable, die Sie entfernt haben, durch eine Platzhaltervariable mit dem gleichen Speicherbedarf ersetzt. Das führt dazu, dass im Prozessabbild die nachfolgenden Variablen ihre Adressen beibehalten. Außerdem wird eine Variable, die Sie hinzufügen, ans Ende der Liste verschoben. Durch die Nachbearbeitung können Änderungen, die zu Persistenzverlust führen würden, neutralisiert werden. Aber Sie erzeugen Lücken, die zusätzlichen Speicher belegen.

Beim Download wird auf der Steuerung der CRC-Wert der Variablenliste und die Länge der Liste (Anzahl der Variablen) hinterlegt. Beim erneuten Download wird der neue Prüfwert mit dem aktuell auf der Steuerung befindlichen Prüfwert verglichen. Dann wird die Variablenliste sukzessive bis zu der angegebenen Länge verglichen. Wenn Sie eine Deklaration, also den Namen oder den Datentyp, bearbeitet haben, wird die Variable neu initialisiert. Ansonsten bleibt ihr Wert erhalten. Beim erneutem Download überprüft also CODESYS, ob die im Persistenzeditor deklarierte Variablenliste noch konsistent zur bereits auf der Steuerung liegenden Variablenliste ist.

Der Mechanismus funktioniert dann gut, wenn die Variablen selbst nicht gravierend geändert werden. Zu weitreichende Änderungen bei den Bezeichnern und den Datentypen führen auch weiterhin zu einer Neuinitialisierung und dem Verlust der Persistenz. Wenn Sie aufgrund Ihrer Anwendungsanforderungen häufige Änderungen voraussehen, ist eine solche Liste deshalb grundsätzlich nicht empfehlenswert. Außerdem ist bei einem Online-Change nach einer Datentypänderung eine persistente Variable weniger robust als eine Variable mit üblicher Lebensdauer.

Grundsätzlich sollten Sie nach einiger Zeit die Variablenliste von Lücken bereinigen und den Befehl „Liste neu ordnen und Lücken bereinigen“ ausführen. Nach dem Bereinigen passt die Liste aber nicht mehr zu der Liste auf der Steuerung und Sie haben eine Initialisierung aller persistenten Variablen provoziert. Die Persistenz aller Variablen geht verloren.

Daten retten über den Rezepturverwalter

Um die globale persistente Variablenliste zu bereinigen ohne die Persistenz zu verlieren, können Sie die Daten mit Hilfe des Rezepturverwalters in einer Rezeptur sichern. Dabei wird im Rezepturverwalter eine Liste für alle Variablen der persistenten Variablenliste erzeugt und gleichzeitig werden deren aktuellen Werte von der Steuerung als Rezeptur abgespeichert. Wählen Sie anschließend den Befehl „Liste neu ordnen und Lücken bereinigen“ und führen Sie danach einen erneuten Download aus. Wenn Sie nun den Befehl „Werte aus Rezeptur wiederherstellen“ auswählen, werden die in der Rezeptur gespeicherten Werte wiederhergestellt.

Änderung einer bestehenden Deklaration in der Persistenten Variablenliste

Wenn Sie Namen oder Datentyp einer Variablen ändern, gilt das als neue Deklaration und bewirkt beim nächsten Online-Change oder Download eine Initialisierung der Variablen. Bei komplexen Datentypen liegt eine Änderung bereits dann vor, wenn eine neue Komponente hinzugefügt wurde, oder wenn Sie in der Tiefe einer verwendeten Struktur beispielsweise den Typ einer Variablen von ‎INT‎ nach ‎UINT‎ ändern.

Grundsätzlich sind komplexe benutzerdefinierte Datentypen für die Verwaltung in einer persistenten Variablenliste nicht geeignet, da selbst kleine Änderungen bewirken, dass die Variable mit allen Komponenten initialisiert wird.

Doppelallokation von Speicher bei Instanzpfaden

Sie können globale Variablen oder lokal in einem Funktionsbaustein oder einem Programms deklarierte Variablen persistieren. Dafür ergänzen Sie die Deklaration mit dem Schlüsselwort ‎PERSISTENT‎. Zusätzlich fügen Sei in der persistenten globalen Variablenliste den Instanzpfad auf diese Variable ein. Wählen Sie dafür im Persistenzeditor den Befehl „Alle Instanzpfade hinzufügen“.

Nachteil dieses Mechanismus ist, dass sowohl an der Deklarationsstelle als auch an der Stelle des Instanzpfades Speicher allokiert wird. Diese persistente Variable belegt doppelten Speicherplatz. Außerdem werden die Daten in jedem Zyklus an beide Stellen kopiert. Insbesondere wenn es sich um große, strukturierte Werte handelt, kann das zeitintensiv sein.

Speicherlokation bei persistenten Funktionsbaustein-Instanzen

Eine Funktionsbaustein-Instanz liegt immer vollständig im Speicher. Das ist notwendig, damit der gleiche Code auf verschiedenen Instanzen arbeiten kann. Wenn nun nur eine Variable in einem Funktionsbaustein mit ‎PERSISTENT‎ gekennzeichnet wird, wird die Funktionsbaustein-Instanz vollständig mit allen Variablen im remanenten Speicher abgelegt, obwohl nur die eine Variable als persistent behandelt wird. Nichtflüchtiger Speicher steht aber nicht in gleichem Umfang zur Verfügung wie Arbeitsspeicher.

Ein Funktionsbaustein, der als Variable einen Pointer auf eine Instanz im SRAM hat, wird nicht im gesicherten Speicher abgelegt.

Import von CoDeSys V2.3-Projekten

Wenn Sie ein CoDeSys V2.3-Projekt öffnen, um es in CODESYS V3 zu importieren, bleiben die Deklarationen von persistenten Variablen nicht erhalten. Sie müssen die Deklarationen überarbeiten und in einer eigenen persistenten globalen Variablenliste neu erstellen.