持久变量在重新加载应用程序、下载、热启动或冷启动后都会保留其值。

控制器上需要一个特殊的非易失性内存区域，如 NVRAM 或 UPS，以延长使用寿命。在这种内存中保护数据不需要额外的时间，这是与使用持久性管理器保留数据相比的一个优势。如果控制器不提供硬件支持，那么数据通常存储在文件中。如果正确关闭控制器，数据将被保留。但是，如果发生断电或拔出插头，数据就会丢失。

行为

因此，只有将控制器重置为出厂设置（例如，单击“Online  Reset Origin” ）时，才会重新初始化持久变量。

另一方面，如果您再次下载应用程序，则会尽可能保留持久化数据。这取决于导致下载的变化有多大。更改应用程序名称总是会导致完全重新初始化。对实现方式的更改永远不会导致重新初始化：数据的持久性被完全保留下来。只有在现有变量是持久化变量的情况下，对声明的修改才会导致新变量的初始化。添加新变量或删除现有变量时就是这种情况。如果编辑和更改先前声明的持久性变量的标识符或数据类型，可能会出现不一致。

下载机制

在持久性编辑器中编辑变量列表会导致变量列表在保存前被自动编辑，而不是在编辑器中显示时被保存。

在后处理过程中，您移除的变量会被具有相同内存需求的占位变量取代。因此，后续变量将保留其在进程映像中的地址。此外，您添加的变量会被移至列表末尾。后处理可以中和可能导致持久性丧失的变化。但是，你创建的间隙会占用更多内存。

下载时，变量列表的 CRC 值和列表长度（变量个数）将存储在控制器中。再次下载时，新的测试值将与控制器上当前的测试值进行比较。然后依次比较变量列表，直至指定长度。如果您编辑了声明（例如名称或数据类型），那么变量将被重新初始化。否则保留其值。重复下载时，CODESYS 会检查持久性编辑器中声明的变量列表是否与控制器上已有的变量列表保持一致。

当变量本身没有被大幅修改时，该机制就能很好地发挥作用。对标识符和数据类型的过多更改仍会导致重新初始化和失去持久性。如果您预计应用需求会经常变化，则不建议使用这种列表。此外，在数据类型变更后的在线变更中，持久变量的稳健性不如正常寿命的变量。

最好在一段时间后清除变量列表中的空隙（命令“重新排序列表和清除空隙” ）。但是，在清理之后，列表不再与控制器上的列表相匹配，而且您还触发了所有持久性变量的初始化。所有变量的持久性都会丧失。

使用配方管理器恢复数据

要在不丢失持久性的情况下清理全局持久性变量列表，可以使用配方管理器将数据保存在配方中。这将在配方管理器中为持久变量列表中的所有变量创建一个列表，同时控制器会将其当前值存储为配方。然后执行命令“Reorder List and Clear Gaps” 并再次执行下载。现在，当您执行命令“Restore Values from Recipe” 时，配方中保存的值就会被恢复。

更改持久性变量列表中的现有声明

如果你更改了变量的名称或数据类型，这将被解释为一个新的声明，并导致在下一次在线更改或下载时重新初始化变量。对于复杂数据类型，当添加了一个新的组件，或将一个变量的类型从‎INT‎ 改为‎UINT‎ 时，例如，在使用的结构深度中，就会发生变化。

基本上，复杂的用户自定义数据类型不适合在持久变量列表中进行管理，因为即使是很小的变化也会导致变量与所有组件一起被初始化。

在实例路径的情况下重复分配内存

您可以在函数块或程序中持久化全局变量或本地声明的变量。为此，请在声明中添加关键字‎PERSISTENT‎ 。此外，还要在持久性全局变量列表中插入该变量的实例路径。为此，请在持久性编辑器中执行“Add All Instance Paths” 命令。

这种机制的缺点是，内存既要在声明处分配，也要在实例路径处分配。该持久变量的内存分配为双 。此外，数据在每个周期都会被复制到这两个地方。这可能会很耗时，尤其是涉及到大结构值时。

持久功能块实例的内存位置

功能块实例总是完全存储在内存中。这是必要的，这样相同的代码才能在不同的实例上运行。如果一个功能块中只有一个变量被标记为‎PERSISTENT‎ ，那么该功能块实例将与所有变量一起完全存储在永久内存中，尽管只有一个变量被视为永久变量。不过，非易失性存储器的可用程度不如主存储器。

将指向 SRAM 中实例的指针作为变量的功能块不会存储在受保护内存中。

从CoDeSys V2.3 项目导入

当您打开CoDeSys V2.3 项目并将其导入CODESYS V3 时，持久变量的声明不会被保留。您必须修改声明，然后在单独的持久性全局变量列表中重新创建。