Data Persistence

Persistent data are data that retain their values even when reloading the application. You can restore the values of persistent data after a download or a cold start.

CODESYS offers the following three mechanisms for achieving persistence:

    1. Declaration of VAR PERSISTENT variables in POUs.VAR PERSISTENT variables are managed and edited with the help of the persistence editor in a global persistent variable list. The controller must support this mechanism by means of a suitable memory (NVRam, UPS)! Typically the VAR PERSISTENT variables are even stored there in a memory segment of their own. The temporal performance is very good. However, the values are lost if names or data types are changed in the declaration. If the application requires such changes frequently, you should restrict yourself to the use of Retain variables or consider a definition via the mechanism of the persistence manager of the Application Composer. Regarding the difference to the Retain variables, please also observe the i-note below and the information about the variable types PERSISTENT and RETAIN.
    1. Declaration of persistent variables via the persistence manager of the Application Composer: You identify variables as persistent in the application program using attributes and the Application Composer stores the persistent variables with their values in an external archive file. Thus, there are no special requirements for the memory of the controller. In the following points the range of functions is larger than in the case of the VAR PERSISTENT mechanism, but at the expense of performance: depending on the controller, the reading and in particular the writing of a large number of persistent variables can take a very long time and can block the corresponding task for a long time.
    • Configurable memory and read-in behavior: You can fill different ‘persistence groups’ with variables and configure a certain memory and read-in behavior for each group. You can identify variables as persistent using a declaration or attributes.
    • Value retention, even if declarations change: If you delete persistent variables from the application or add new ones, an automatic mechanism ensures that no persistent values are lost. For the case of changes of data type you can configure suitable conversions that similarly ensure that the persistent values are retained.
    • External files: since the persistent data are managed only in external files, the PLC requires no special memory. In addition, you can edit the records in an external editor (for example: Notepad) as well as swapping them in a simple manner between applications.
    1. Recipes: a recipe contains a definable set of variables with values and can be stored as a file under a certain name. You can store different recipes for the same variables and write the respectively desired recipe to the controller. In order to create a recipe, you can read current values from the controller or fill the recipe manually or programmatically from the application. The management takes place in the Recipe Manager.

See also

Note

A further possibility to keep data remanent is the RETAIN variables. Persistent data are always also RETAIN. Like the persistent variables the RETAIN variables retain their values in the case of a reset warm (power failure), but not in the case of a repeated download of the application that only the persistent data survive. You can also combine the remanent properties by means of a declaration with RETAIN + PERSISTENT. The variables declared only with VAR PERSISTENT are always treated as VAR RETAIN PERSISTENT or VAR PERSISTENT RETAIN. As a result you obtain data that are only re-initialized when resetting the controller to the delivery state (Reset Origin).

Which mechanism for which application?
Some common applications are considered here; the concrete examples in parentheses refer to a building controller:
  Application (A) VAR PERSISTENT (B) Persistence Manager (C) Recipes
         
1

Retention of appliance settings

(Power failure -> Venetian blind still ‘knows’ how long it needs to drive up)

suitable1

(preferential application, but it is also possible via VAR RETAIN; it is better to use retain variables if the variable definition has to be changed frequently in the practical case.

suitable2

Advantage: also usable for controllers without hardware support through special functions (double file buffering)

 Possible, but very complicated
         
2 Retention of values even when the application program is changed/extended      
  2a: rare extensions (new switch and new light were installed, the remainder remains unchanged)

suitable1

(preferential application)

 suitable2 Possible, but complicated
  2b: more liberal changes, also deletion or changing of the data type of variables (the building controller is running and is persistent, but now a new function is installed so that a further variable must be persistent in a function block; for example, the automatic switch-off of a forgotten lamp after a certain time) not suitable

suitableas far as possible 2

(preferential application)

 Possible if textual, but complicated
3 Use of different value sets as required(it should be possible to store and if necessary load operating settings for summer, winter and vacation) not suitable not suitable

suitable

(preferential application)
         
4 Transfer of settings from one system to anotherthat uses similar variables not suitable suitable2 suitable:sup:3
         
5 Settings should be textually readable(in order to be able to compare and edit states/changes) not suitable suitable2 suitable:sup:3

1 Disadvantage: runtime system must support the mechanism: NVRam memory or UPS; advantage: speed; recommended application: 1 and 2a

2 Disadvantage: long waiting periods during initialization and shutdown in case of large numbers of variables (> 10000) ; advantage: no special memory required; value retention even in case of changes/extensions/deletions;

3 Advantage: externally editable, transferable; disadvantage: complicated

See also