通用

变量及其数据的生命周期从创建变量时开始，到删除变量并释放内存时结束。变量创建、初始化或实例化的时间取决于所声明的作用域。释放内存的时间通常也取决于作用域。例如，全局变量的内存会在退出应用程序时释放。

它们可以比平时保留更长时间的数据。为此提供了以下机制。

数据保留机制

(A):持久性全局变量列表，使用关键字 ‎PERSISTENT RETAIN‎

当重新加载应用程序时，持久变量会保留其值。此外，在下载、热启动或冷启动后，这些值都会恢复。
(B):用关键字 ‎RETAIN‎

保留变量在热启动后会保留其值，但在重新加载应用程序、下载或冷启动后则不会。
(C):的持久性管理器变量。 CODESYS Application Composer

持久性管理器的变量存储在外部文件中。
(D):配方变量

配方变量及其值存储在配方文件中。

另见

机制比较

哪种机制适合哪种应用？表中列出了一些常见的使用案例。具体示例指的是楼宇控制系统。

表格 391：机制和用例比较
	使用案例	(A) 持久变量	(B) 保留变量	(C) 持久性管理器的变量	(D) 配方变量
1	应用程序必须维护设备设置。示例：停电后，楼宇管理部门必须掌握百叶窗需要升起多长时间的信息。	适合¹ 首选用例在这种情况下，也可以使用保留变量来代替持久变量。这对声明经常更改的变量非常有利。	适用首选用例当变量的声明经常更改时，保留变量是一个优势。	适用² 这对于没有任何硬件支持的控制器来说非常有利。特殊功能使其成为可能，例如双文件缓冲。	有可能，但非常复杂，因此不建议使用。
2	程序更改或扩展后，应用程序也必须保持数值不变。
	2a:罕见的扩展示例：应用程序员用一个新开关扩展了程序，并安装了一盏新灯。在此之前，楼宇控制必须仍有保存的数值。	适合¹ 首选用例	适用	适用²	有可能，但很复杂。
	2b:无限制更改，包括删除或更改变量的数据类型楼宇控制正在运行，并且持续运行。当应用程序员为控制器添加新功能并因此在功能块中添加另一个持久变量时，必须保留之前保存的值。例如，FB 中的程序扩展了一个变量，该变量可控制以前不受控制的灯泡在一定时间后自动熄灭。扩建后，建筑管理部门必须掌握所有受控灯具的时间。	不适合	适用在线更改后，保留变量的数据将尽可能得到保留。	合适的尽可能² 首选用例	如果是文本，则有可能，但比较复杂
	2c:应用程序必须在下载后保持数值不变。	适用	不适合	适用	适用
3	应用程序必须能够使用不同的值集。示例：必须保存夏季、冬季和节假日的运行设置，并在需要时导入。	不适合	不适合	不适合	适用首选用例
4	应用程序必须能够使用其他系统的设置。必须能够使用类似的变量将设置转移到另一个工厂。	不适合	不适合	适用²	Suitable³
5	应用程序必须提供人类可读的数据。用户必须能够读取、比较和编辑数据。	不适合	不适合	适用²	Suitable³

¹ 缺点：只有当运行时系统支持该机制，且有 NVRAM 内存或 UPS 时才有可能。优势速度；建议应用：1 和 2a

² 缺点：如果变量集较大（大于 10000），则初始化和关闭过程中会出现较长的延迟。优势无需特殊内存；即使在更改、扩展或删除的情况下，也能保留数值。

³ 优势：可远程编辑，可转让。缺点复杂

调用联机命令时变量的生命周期

“在线” 菜单中的用户输入	与通常寿命不同 `‎RETAIN‎` 和 `‎PERSISTENT‎`	`‎ RETAIN‎`	`‎PERSISTENT‎` `‎RETAIN PERSISTENT‎` `‎ PERSISTENT RETAIN‎`
命令“在线更改”	x	x	x
命令“重置预热”	i	x	x
命令“冷复位”	i	i	x
命令“下载”	i	i	x ¹
命令“重置原点”	i	i	i

x :变量保留其值。

i :变量已初始化。

¹ 注：有关持久数据的结构，请参阅 "下载机制 "中的信息。

另见

下载启动项目时变量的寿命

普通变量的值会丢失并重新初始化。

当出现以下情况时，持久性变量的值将受到保护：

内存中的持久性变量结构与持久性数据列表中的结构一致。

当出现以下情况时，保留变量的值将受到保护：

内存中的持久性变量结构与持久性数据列表中的结构一致。
持久变量与应用程序相匹配（GUID 必须一致）。

当应用程序启动时，恢复保留变量和持久性变量值的要求未得到满足时，就会出现 "保留不匹配"。硬件制造商的文档中描述了对这种差异的应对措施。

请注意：有关持久数据的结构，请参阅 "下载机制 "中的信息。

另见

⮫ “下载机制”