Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:sw:01-mervis:variable-backup-hidden [2023/12/06 22:19] avsetula [Backup of retain variables] |
en:sw:01-mervis:variable-backup-hidden [2023/12/20 13:47] (current) avsetula |
||
|---|---|---|---|
| Line 27: | Line 27: | ||
| ---- | ---- | ||
| - | In many cases, it is not necessary to periodically store 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. | + | 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. | 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. | ||
| Line 38: | Line 38: | ||
| 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. | 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. | ||
| - | V závislosti na požadavcích programu je vhodné nastavit co možná nejdelší interval ukládání proměnných. | ||
| ---- | ---- | ||
| Line 84: | Line 83: | ||
| <WRAP center round info 90%> | <WRAP center round info 90%> | ||
| - | In ST language it is necessary to create / move variables to a separate global variable declaration retain. | + | In ST language it is necessary to create / move variables to a stand-alone global declaration of retain variables. |
| </WRAP> | </WRAP> | ||
| Line 90: | Line 89: | ||
| ==== Deploying solution and backing up variables ==== | ==== Deploying solution and backing up variables ==== | ||
| - | When the solution is deployed, the program is always stopped and the backup of all variables is started at the same time. This makes it possible to choose whether the PLC should be started with the default variables set in the Mervis IDE report or whether all available values should be restored from the backup. | + | 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. |
| {{ .:variable-backup:variable-backup_06-deploy.png?direct |}} | {{ .:variable-backup:variable-backup_06-deploy.png?direct |}} | ||
| Line 96: | Line 95: | ||
| |< 100% 40% 60%>| | |< 100% 40% 60%>| | ||
| ^ Operation ^ Variable values ^ | ^ Operation ^ Variable values ^ | ||
| - | | Warm restart | Restored from backup to PLC | | + | | Warm restart | Restored backup from PLC | |
| | Cold restart | Setting default values from IDE | | | Cold restart | Setting default values from IDE | | ||
| | Clear flash variables | Always force default values from IDE | | | Clear flash variables | Always force default values from IDE | | ||
| Line 107: | Line 106: | ||
| ===== Examples of using variable backup ===== | ===== 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, the less the system storage will be stressed and its lifetime will be greatly extended. | + | 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 ==== | ==== Disabled variable backup ==== | ||
| - | Even basic modifications will reduce the total amount of data written, but if it doesn't affect the operation of the program, it is possible to not use variable backup at all. | + | 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. |
| ---- | ---- | ||
| Line 126: | Line 126: | ||
| ==== Event variable backup ==== | ==== Event variable backup ==== | ||
| - | Below are some examples of using backups of all variables without periodic storage. The retain variables are not mentioned here as they do not allow backups in response to an event. All of the following examples are based on the assumption that the retain variables are not needed at all and the interval for saving them is set to 1 hour. However, the setting of backup retention is not essential, as their use always depends only on the needs based on the program design. | + | 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. |
| <WRAP center round info 90%> | <WRAP center round info 90%> | ||
| - | The Mervis IDE build created in version 2.5.0, containing all the logic mentioned below, is available for download via {{ :en:sw:01-mervis:variable-backup:variable-backup_merviside-solution-v250.zip |this link}}. | + | The Mervis IDE solution created in version 2.5.0, containing all the logic mentioned below, is available for download via {{ :en:sw:01-mervis:variable-backup:variable-backup_merviside-solution-v250.zip |this link}}. |
| </WRAP> | </WRAP> | ||
| === Backup by button from HMI ==== | === 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. | |
| - | The simplest case of an event-driven backup is a manual backup 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. In the case where the user changes values in the HMI interface and then clicks the SAVE button, the backup variables are called. | + | |
| <WRAP center round important 90%> | <WRAP center round important 90%> | ||
| - | **WARNING!** If the backup of variables is called more often than 8 times a day, it is up to consideration whether it is better to mark the variables with the retain flag and save the values periodically according to the defined interval. | + | **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. |
| </WRAP> | </WRAP> | ||
| Line 156: | Line 155: | ||
| 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. | 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 requires control from the HMI, the variable button is controlled directly ** | + | **This block is controlled by its internal variable 'button', and its value can be changed only from the HMI!** |
| </WRAP> | </WRAP> | ||
| Line 162: | Line 161: | ||
| === Backup on value change === | === Backup on value change === | ||
| - | Another option is a backup in response to a value change. If the value changes (for example in the HMI), a backup of the variables is automatically triggered. The advantage of this solution is that human error is eliminated, because the request for a backup of variables occurs at the same time as the value change and it cannot happen that the user forgets to confirm the changes. | + | 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 block whose output is connected to the backupTrig trigger variable: | + | In the program, there is only the monitored variable and the changeChecker function block whose output is connected to the backupTrig trigger variable: |
| {{ :en:sw:01-mervis:variable-backup:variable-backup_12-program-changeChecker.png?direct |}} | {{ :en:sw:01-mervis:variable-backup:variable-backup_12-program-changeChecker.png?direct |}} | ||
| Line 185: | Line 184: | ||
| === Backup for multiple events === | === Backup for multiple events === | ||
| - | The disadvantage of the previous solution is that if there is a need to monitor more than one value, or the value needs to be changed multiple times, the solution is no longer suitable and the logic needs to be extended. | + | 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. | 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 any number of pulseButton, changeChecker and other blocks is supplemented with OR function as pulse concentrators and the mentioned backupTrigger block: | + | The program with random number of pulseButton, changeChecker and other blocks is supplemented with OR function as pulse concentrators and the mentioned backupTrigger block: |
| {{ :en:sw:01-mervis:variable-backup:variable-backup_14-program-backupTrigger.png.png?direct |}} | {{ :en:sw:01-mervis:variable-backup:variable-backup_14-program-backupTrigger.png.png?direct |}} | ||
