Save and load values of {PUBLIC} variables from / to file

Example_Load & Save_VAR shows how to save resp. retrieve values of {PUBLIC} variables from PLC program.

A function block is used to save the values of variables to a file fbSavePubVar().

A function block is used to read the values of variables from a file fbLoadPubVar().

FW v9.7 or higher is required in the Foxtrot CP-1xxx central unit. Foxtrots of the CP-2xxx series support functionality in all versions. Mosaic must be version 2016.2 or higher.

Principle of operation

The example uses the properties of the Mosaic environment, which includes each {PUBLIC} variable in a * .pub file. This file can be automatically sent to Foxtrot as part of the transmitted code (see Project Manager | Export files, where "Generate assembler (.pub file)", "Automatically send newer files to PLC" and "Send assembler file (.pub)) must be checked. ").

The fbSavePubVar() function block selects variable names from a .pub file, reads their current value using the GetVarValueByName () function, and then saves the variable name and value to a file on the SD card. 

The save format corresponds to a .csv file, separated by a ";" (semicolon). The comma cannot be used due to multidimensional fields where the comma is part of the variable name. Lines in the file end in CR and LF.

The fbLoadPubVar() function block is used to restore the values of variables that were previously stored by the fbSavePubVar() block.

Variables to be backed up in this way must have the {PUBLIC} directive and the {OPEN_UP} directive specified in the definition. The {PUBLIC} directive causes a variable to be listed in a .pub file.

The {OPEN_UP} allows to work with variables via their name (regardless of the location in the PLC memory). This is then used by the GetVarValueByName() and SetVarValueByName() functions. hus, the stated principle of backing up the values of variables does not depend on the location of the variables in memory. In other words, it only depends on the names of the variables. If the variable name does not change, it will be possible to restore its value (even if the variable's data type has changed between saving and restoring).

Example of variable declarations for automatic backup:

VAR_GLOBAL
  g_jedna  {PUBLIC} {OPEN_UP} : INT;
  g_dva    {PUBLIC} {OPEN_UP} : REAL;
  g_str    {PUBLIC} {OPEN_UP} : T_MY_STRUCT;
  g_arr    {PUBLIC} {OPEN_UP} : ARRAY[1..5] OF INT;
  g_arrStr {PUBLIC} {OPEN_UP} : ARRAY[1..5] OF T_MY_STRUCT;
END_VAR

Example control

The example is controlled by setting the following variables:

  rqSample   : BOOL;     // set values of variables (for saving control)
  rqSave     : BOOL;     // save .pub variables to backup (VarList.var file)
  rqLoad     : BOOL;     // load variables from the saved backup

So first you need to set rqSample to TRUE, which will fill the control values into the stored variables. Then set rqSave to TRUE, which will generate a backup file VarList.var. Then we can select HALT and RUN with a cold start, which will cause the variables to be reset. And then we set​​​​​​​ rqLoad to TRUE and this will load the backed up values from the VarList.var file.

Pros

Saving is performed automatically on the basis of a .pub file, when changing stored variables, it is not necessary to modify the code for saving or. loading. Storage is memory independent, ie variable mapping does not matter. It is thus possible to restore the values of the variables even in the case of new versions of the PLC program, where the mapping may differ significantly. 

You can even use a backup created on another PLC system (if it contains the required variables) to restore the values.

Cons

The example stores all variables marked by the {PUBLIC} and {OPEN_UP}. This can sometimes be a nuisance

Risks

Saving resp. loading takes place in several PLC cycles (to reduce time). The input variable indicates how many variables are processed in one PLC cycle​​​​​​​ maxItems. This means that the stored values may not be consistent, which can be a problem especially when storing field values resp. structures.
Writing to the file also takes place in several cycles. From this point of view, it is necessary to take into account that the PLC power supply may fail during the writing of the backup and the file will not be saved. It is therefore advisable to store the backup alternately in two files so that at least one file is available for data recovery.

Note

When debugging with the Foxtrot PLC simulator of the CP-1xxx series in Mosaic, it is necessary to manually copy the .pub file from the SendRoot directory to the ROOT directory (which uses the simulator instead of the SD card). The backup is then also saved in the ROOT directory. This operation is not necessary for the CP-2xxx series simulator.