Variable Backup
Unipi devices with Mervis OS allow variable backups in several ways, this article will describe their setup, storage location, risks and appropriate usage.
Backup all / retain variables
By default, variable backup is set so that the values of all variables (including retain) are saved every 3 hours, which is also the shortest possible interval. In addition, variables marked with the retain flag are backed up according to the retain periodical saving interval, which is set to 5 seconds by default.
In many cases, it is not necessary to periodically save all variables. When it is necessary to back up values that the operator has set during the program run, such as time programs, specific settings, etc., it is useful to back up variables by trigger variable (BOOL). In this case, the periodic saving of all variables can be disabled and they are saved only when a request occurs.
When backing up by a trigger variable, it is very important to know the approximate number of writes per day/month and compare it with the number of writes of periodic saving. When developing a program, it is therefore necessary to compare whether it is more storage friendly to mark selected variables with the retain flag with more frequent backups, instead of frequent requests to backup all variables.
If some values need to be saved frequently, it is always a good idea to mark these variables with the retain flag. Variables with the retain flag can be backed up at intervals from 1 second to 1 hour (depending on the setting). It is not possible to disable the retain saving. Typically, the retain flag is used for variables containing, for example, values of operating hour counters, meters (electricity meters, flow meters) and similar values that need to be retained in the event of a power outage or other unexpected situation.
Backup of all variables
Variables are backed up on system storage, so it is important to optimize the number of writes. Depending on the program requirements, it is advisable to set the longest possible saving interval.
1. Periodic backup
The shortest possible saving period is 3 hours, this limitation is to protect the system storage. It is also possible to disable periodic storage completely.
The maximum saving period is given by the time data type, which is 49d17h2m47s295ms.
2. Event depending backup
The backup of variables can also be called from the program using the “Trigger Variable” (BOOL). Saving is triggered on every rising edge (transition from FALSE to TRUE), whether periodic saving is enabled or disabled.
Backup of retain variables
Beside backing up all variables, you can mark selected variables with the retain flag and backup them more frequently according to the interval set in the 'Configuration Retain' field.
WARNING! The shorter the storage interval, the sooner the maximum number of writes to the storage is reached, which can cause irreversible damage!
Backing up variables with the retain flag cannot be disabled or triggered from the program, just like backup of all variables. However, if no variable or function block containing a variable with this flag is defined, nothing will be backed up. So it depends on the saving interval, but also on the volume of data to write, or the number of variables and their data types.
Retain flag
If some variables need to be backed up more frequently, for example to prevent power failure, these variables can be marked with the retain flag. Typically, this is used to back up counted or calculated values obtained from connected devices or from a program.
The retain flag can be set when creating or changing a variable definition:
In ST language it is necessary to create / move variables to a stand-alone global declaration of retain variables.
Deploying solution and backing up variables
When the solution is deployed, the program is stopped and the backup of all variables is triggered at the same time. Thus, it is possible to choose whether to start the PLC with the default variable values set in the Mervis IDE solution or whether to restore all available values from a backup.
| Operation | Variable values |
|---|---|
| Warm restart | Restored backup from PLC |
| Cold restart | Setting default values from IDE |
| Clear flash variables | Always force default values from IDE |
A warm restart means restarting the program with the values that were in the PLC just before the solution was deployed.
A Cold Restart will start the PLC regardless of any stored values. All values are set to the default values when the solution is deployed.
Examples of using variable backup
The correct setting of variable backup is individual for each PLC deployment, but always necessary. The more sophisticated the variable backup is, the less the system storage will be stressed, thus greatly extending its lifetime.
Disabled variable backup
Any increasing of the save interval will reduce the total amount of data written, but if it does not affect the program, it is possible to disable the backup of variables.
Backing up retain variables cannot be turned off completely, but if no variable or function block containing a variable with the retain flag is defined, nothing will be backed up.
Backing up all variables can be disabled easily, directly in the PLC configuration in its properties:
Event variable backup
Below are some examples of using variable backup without periodic saving. The retain variables are not mentioned here as they do not allow backups in response to an event. All of the following examples assume that retain variables are not needed at all and that the interval for saving them is set to 1 hour. However, the setting of the backup retains is not essential, as their use always depends on the requirements of the program.
The Mervis IDE solution created in version 2.5.0, containing all the logic mentioned below, is available for download via this link.
Backup by button from HMI
The simplest case of an event-based backup is manual backup by request from the HMI. By request, it means a click on the SAVE button (digital setter), which is mapped to the internal variable of the pulseButton block, whose output is a one cycle pulse connected to the backupTrig trigger variable.
CAUTION! If the backup of variables is called more often than 8 times a day, it is worth to consider whether it is better to mark some variables with the retain flag and save these values periodically according to the defined interval.
Only variables and the mentioned pulseButton block are defined in the program:
The internal logic of the pulseButton block is shown and explained below:
Block description:
The local variable button is connected to the CLK input of the R-TRIG block.The R_TRIG block at the rising edge at the CLK input sets the output Q to the state TRUE for the length of one program cycle.The BD13 block and the F_TRIG block are used to delay the signal by the set time (pushTime). After the set time has elapsed, the “button” variable is set to FALSE using the “SEL” block.
This block is controlled by its internal variable 'button', and its value can be changed only from the HMI!
Backup on value change
Another option is a backup in response to a value change. If the value changes (for example in the HMI), variable backup is automatically triggered. The advantage of this solution is that human error is eliminated, because the request for a variable backup occurs at the same time as the value change and it cannot happen that the user forgets to confirm the changes.
In the program, there is only the monitored variable and the changeChecker function block whose output is connected to the backupTrig trigger variable:
The internal logic of the changeChecker block is very simple:
Block description:
The block has one input, one output and consists of functions NE, SEL and local variable TEMP.
The NE function compares the IN input and the TEMP variable and if they are different, sets its output to TRUE. The output of the NE function is written to the OUT output of the block and the G input of the SEL function, thus writing the IN input to the TEMP variable. In the next cycle of the program, the block output will again be FALSE since the IN and TEMP values are equal again.
Note: if the IN value does not change every cycle (which would result in the output permanently switching to TRUE), the output is pulsed with a pulse of one program cycle length.
Backup for multiple events
If there is a need to monitor more than one value, or it is necessary to change the value more than once, the previous options are no longer suitable and the logic must be extended.
Both of the above mentioned variants can be used simultaneously and their outputs can be connected to the inputs of the OR function. The output of the OR function is connected to the IN input of the backupTrigger block, which ensures that the backup is triggered after the set delay interval from the last pulse on the IN input has elapsed. If another pulse arrives at the IN input in the meantime, the interval is reset to the default delay value.
The program with random number of pulseButton, changeChecker and other blocks is supplemented with OR function as pulse concentrators and the mentioned backupTrigger block:
The internal logic of the backupTrigger block is shown and explained below:
Block description:
The backupTrigger function block acts as a concentrator and filter for variable backup requests to prevent too frequent or unnecessary writes to system storage. The output of this block serves as the “Trigger Variable” of the Variable Backup.
The block has several IN inputs and pulse control is required for all of them, i.e. it must not be permanently set to TRUE. If such a variable, block/function output, or physical input must be connected to the IN input, the connection must be completed with the R_TRIG block.
The DELAY input specifies the delay for normal event saving (e.g. 5m) from the last pulse on the IN inputs. The saveDELAY input, in turn, serves as an emergency output switch if the pulses on the IN inputs are more frequent than the DELAY set.
Everything is handled by a single OR function for the IN inputs, blocks BD12 and BD13 for the mentioned delays, and also R_TRIG and F_TRIG to guarantee that the output will always be a pulse.
