Where does FC_WritePersistentData write, and on which machine?
The C6015 is an industrial PC running a full operating system (typically Windows 10 IoT), and its persistent variable file is stored on the solid-state disk inside that IPC. The TwinCAT runtime that executes the PLC task performs the write. It writes to the file system of the machine it runs on, and the engineering laptop is not in that path.
Data path for a persistent write:
| Hop | Element | Role |
|---|---|---|
| 1 | PLC task on the runtime | Holds the PERSISTENT variables in RAM and executes the trigger. |
| 2 |
FC_WritePersistentData call |
Serializes the persistent area when the trigger fires. |
| 3 | Runtime host file system | Writes the boot data under C:\TwinCAT\3.1\Boot\Plc. |
| 4 | Runtime start | Reads that file back into the persistent variables at start. |
The engineering PC is only in the path while XAE is online. Unplugging or powering down the laptop changes nothing about hops 2 to 4.
Why did the Boot\Plc folder show up on the engineering computer?
The folder appears on the machine where the runtime executed. If C:\TwinCAT\3.1\Boot\Plc was populated on the laptop, the PLC ran on the laptop's local runtime, not on the C6015. Two causes are common:
- The active target system in XAE is
Local(or a local route), so the project runs and writes on the laptop. - The project was tested locally before the route to the C6015 was selected and activated.
Check the target selector in the XAE toolbar and the route list under System > Routes. Then open a remote desktop session to the C6015 and browse the same path. A boot data file with a fresh timestamp after a write trigger confirms the write happened on the IPC. The laptop file is a leftover from the local run and does not transfer to the target.
Which remanent mechanism fits: persistent file or retain?
TwinCAT 3 treats both as remanent, meaning values survive power-down and restart. They differ in where the data goes and what triggers the save.
| Criterion | Persistent | Retain |
|---|---|---|
| Storage | File on the IPC's operating system disk | Additional NovRAM |
| Save trigger | Explicit write (FC_WritePersistentData) or controlled shutdown handling |
None; the value is held in NovRAM continuously |
| Failure mode | Unsaved changes are lost on power loss between the last write and the outage; a failed trigger goes unnoticed | Depends on NovRAM presence and size on the specific device |
| Extra hardware | None beyond the IPC's SSD | NovRAM must exist on the device |
| Fit | Configuration data changed rarely | Values that change often or must survive an unannounced power cut |
Retain on NovRAM is the more reliable option because it does not depend on a triggered save. Read the C6015 datasheet for the NovRAM presence and capacity of your exact variant before you rely on it.
Recommendation: keep configuration data as persistent variables and write them with FC_WritePersistentData on change. That needs no additional module. Move to retain only when the values change often and the target has NovRAM.
How do I set up persistent configuration storage on the C6015?
- Set the XAE target system to the C6015 route. Confirm the route shows a connected state and the runtime is in Run mode.
- Declare the configuration variables in a
PERSISTENTvariable list or with the persistent attribute, in a single dedicated global list so the layout stays stable. - Call
FC_WritePersistentDatafrom a rising-edge trigger that fires only when a configuration value changes (for example, on a "Save" command from the HMI). Do not call it cyclically. - Check the function's return value and alarm on failure. A silent write failure is the main weakness of the persistent method.
- Activate the configuration and restart the runtime to load the boot project onto the C6015.
What breaks persistent data on this class of IPC?
- Cyclic write calls. Every trigger is a file write to the SSD. Limit writes to real configuration changes to keep disk wear negligible.
- Power loss before the write. Persistent variables changed in RAM but not yet written revert to the last saved file. Use a UPS with controlled shutdown, or trigger the write immediately after each change.
- Changing the persistent variable layout. Adding, removing, or resizing persistent variables changes the data structure. Re-verify the restored values after every download that touches the persistent declarations.
- Testing on the wrong host. Values saved on the laptop's local runtime do not exist on the C6015. Test on the target.
- Ignoring the return value. If the write fails (disk full, permissions, path), the variable still holds its RAM value and the fault appears only after the next restart.
How do I confirm the values survive a power cycle on the C6015 alone?
- Open a remote desktop session to the C6015 and list the boot folder:
Get-ChildItem C:\TwinCAT\3.1\Boot\Plc | Sort-Object LastWriteTime -Descending. Note the newest file's timestamp. - Change a persistent configuration value, trigger the write, and confirm the file timestamp advances and the function returns no error.
- Disconnect the C6015 from the engineering PC and network. Power-cycle the IPC.
- After the runtime reaches Run, read the variable (HMI or a later online session) and compare it to the value written in step 2. A match proves the file on the C6015's SSD, not a laptop copy, restored the value.
FAQ
Why does the persistent file appear on my laptop instead of the C6015?
The runtime that executed the PLC code wrote it, so the active target was the laptop's local runtime. Select the C6015 route, activate the project there, and check C:\TwinCAT\3.1\Boot\Plc on the IPC via remote desktop.
Why does a C6015 not need an extra module for persistent variables?
It is an IPC with its own operating system and SSD, so the boot file is stored on that internal disk. An additional memory device applies only to retain variables that rely on NovRAM.
Why does my persistent variable revert after a power cut?
The value changed in RAM but FC_WritePersistentData had not yet written it to the file. Trigger the write on every configuration change and check its return value, or add a UPS with controlled shutdown.
Why does retain survive power loss without a save trigger?
Retain variables sit in NovRAM, which holds the value continuously, so no file write is involved. Confirm on the C6015 datasheet that your variant includes NovRAM and check its capacity.