The first version of a PLC application is often built around the current machine. The next machine, firmware update, or customer request exposes whether the software was designed as a reusable system or as a collection of fixed values.
This part of the series covers persistent data and modular configuration patterns in CODESYS.
RETAIN and PERSISTENT are different decisions
Both mechanisms can preserve data across a restart, but they should not be treated as interchangeable.
| Data class | Intended question |
|---|---|
| Normal variable | Can this value be rebuilt during startup? |
| RETAIN | Should this value survive a power cycle? |
| PERSISTENT | Should this value survive application download or replacement? |
The exact behavior depends on the target runtime and project configuration, so the storage policy must be verified on the actual controller. The engineering principle is simple: preserve only data that has a defined business or machine purpose.
What should be stored?
Good candidates may include:
- Calibrated limits
- Production counters
- Recipe selection
- Operator-approved parameters
- Maintenance state
- Acknowledged configuration settings
Temporary communication buffers, calculated values, and values that can be safely initialized should normally remain ordinary variables. Persisting everything increases complexity and can make troubleshooting harder.
Use a configuration model instead of scattered variables
A scalable application groups related settings into a clear configuration structure.
TYPE ST_LineConfig : STRUCT
TemperatureWarning : REAL;
TemperatureAlarm : REAL;
SampleIntervalMs : UDINT;
EnableCloudUpload : BOOL;
END_STRUCT
END_TYPE
The application can then validate, load, save, and display one configuration model rather than managing unrelated values across many program units.
Validation belongs at the boundary
User-configurable values should be checked before they affect control logic. A useful validation layer checks:
- Minimum and maximum limits
- Unit and scale
- Dependency between parameters
- Compatibility with the selected recipe
- Permission required to change the value
For example, an alarm threshold should not be accepted if it is lower than the warning threshold. Invalid data should produce a clear diagnostic instead of silently entering the control algorithm.
Modular software structure
A maintainable CODESYS project often separates:
- I/O mapping
- Device or communication drivers
- Equipment function blocks
- Sequence and state logic
- Alarm and diagnostic handling
- HMI and external integration
This separation makes it possible to replace a sensor or communication method without rewriting the machine sequence.
A safe startup sequence
Load default configuration
↓
Load retained/persistent values
↓
Validate ranges and dependencies
↓
Apply approved configuration
↓
Enable machine and external communication
The application should make it visible whether the loaded values are defaults, restored values, or values rejected during validation.
Conclusion
Memory persistence is not only a storage feature. It is part of the machine’s operational contract. Combined with structured configuration and modular function blocks, it allows one CODESYS application to be reused across equipment variants without losing control over safety and behavior.
The next article introduces OPC UA information modeling, subscriptions, and security.