Recipe Manager writes nothing because the CODESYS runtime accepts recipe files only inside its own PlcLogic folder. Point the recipe directory at the numbered PlcLogic folder of the runtime instance itself, not c:\recipes\ and not a subfolder, and the .txtrecipe file appears on save.
Recipe Manager opens its file dialog, walks to c:\recipes\, accepts a file name, and writes nothing: no new file, no overwrite, no error in the dialog. The runtime is the reason. CODESYS accepts recipe files only inside the PlcLogic folder of the running runtime instance, and c:\recipes\ and the default folder both sit outside it. Point the recipe directory at that PlcLogic folder itself and the .txtrecipe file appears on save. The sections below give the exact path layout, the four-point write chain, and a worked example that runs 3 saves and 1 load and counts the files 0, 1 and 2.
Why does Recipe Manager browse fine but write no file?
Because the browse and the write are separate operations: the dialog listing c:\recipes\ shows the runtime can read the folder, while the write passes a path check that only accepts folders inside the runtime's own PlcLogic area, and that check rejects c:\recipes\ with no error shown in the dialog.
The restriction exists for security reasons and covers the file read as well as the write. A folder that lists in the dialog is a folder the runtime can display; opening a recipe from it and saving one into it both run through the same path policy, and both fail outside PlcLogic, quietly.
What each symptom points to
- Dialog opens, folder lists, no file after Save: the recipe directory sits outside the runtime PlcLogic area.
- Same failure in the default folder: same cause, the default folder is outside the runtime tree too.
- A path under
PlcLogic\Recipeslists but read and write both fail: subfolder below PlcLogic, point the directory at PlcLogic itself. - Saves worked before and stopped after the device was re-created: new instance ID, the folder you used belongs to the old instance.
- Path already exact and the file still never appears: the service account lacks write rights on PlcLogic.
- Nothing written on download either: the
Recipe management in the PLCoption is off on the recipe object, the documented requirement for a file to be saved on the PLC.
Where does the save stop between the button and the disk?
The save passes four points: the Recipe Manager window issues the request over the device connection, the runtime receives it, the runtime's file access checks the target path against its allowed area, and the operating system writes the file with the rights of the service account.
The request stops at the third point for c:\recipes\ and for the default folder. The read-only attribute you already cleared lives at the fourth point, so it changes nothing while the third point rejects the path.
One physical check comes first. When the runtime runs on a different PC from the engineering tool, c:\recipes\ on the engineering PC is a different disk from the one the runtime sees. Confirm which machine hosts the runtime, then read every path on that machine.
Is the recipe directory inside the runtime PlcLogic folder?
Open the Storage tab of the recipe object and read the directory there: the path that works is C:\ProgramData\CODESYS\CODESYSControlWinV3x64\<instance ID>\PlcLogic, and every other path, c:\recipes\ and the default folder included, stops at the third point.
| Directory in the recipe object | Reading | Next step |
|---|---|---|
c:\recipes\ or any default outside the runtime tree |
Stopped at the path check | Move the directory to PlcLogic and repeat this check |
...\CODESYSControlWinV3x64\<instance ID>\PlcLogic itself |
Path policy satisfied | Check the instance ID, then the service account |
The working layout keeps the recipe files directly in PlcLogic, named <recipe>.<definition>.txtrecipe. A working installation produced Hello.RecipeDef.txtrecipe and ABC123.OtherRecipes.txtrecipe there, with no recipes subfolder holding them.
Does that PlcLogic folder belong to the runtime you are connected to?
Only when the numeric instance ID in the path matches the runtime instance behind your device connection: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\58719825\PlcLogic belongs to instance 58719825, and a PlcLogic folder under any other ID sits outside the allowed area for the runtime you are using.
The instance ID is device specific. A re-created device or a second runtime installation gets a different number, and the folder under the old number stays outside the allowed area for the runtime behind your connection. Open the folder that holds the application files of the running runtime, read the number from its path, and use that folder. A re-created device changes more than recipes; fixing a PLC runtime device mismatch safely covers the reconnect work.
Why does a subfolder like PlcLogic\Recipes still fail?
Because the subfolder failed in one installation: with the directory set to PlcLogic\Recipes the folder listed in the dialog, reads and writes still failed, and both started working when the directory pointed at PlcLogic itself.
Take the layout from the working installation: recipe files sit directly in PlcLogic, beside the application files, in no subfolder of their own. Set the directory to ...\PlcLogic with nothing after it, and expect the .txtrecipe files to appear in that folder.
Does adding the path to CODESYSControl.cfg help?
It did not help in one installation, and the runtime reads that file at startup, so a service restart belongs to every edit of it you test; treat the cfg route as closed until the directory itself is correct.
Revert the recipe-path addition once the directory points at the right PlcLogic folder. If you keep editing CODESYSControl.cfg, change one entry at a time and keep a copy of the original, because a bad edit can cut you off from the runtime; fixing a CODESYSControl.cfg edit that locked you out starts from that copy. After any edit, restart the runtime service and check whether the CODESYS runtime is running or stopped before you read the result.
Can the runtime service account write to the folder?
It can when the account running the CODESYS Control Win service holds Modify rights on PlcLogic; when it does not, the write fails at the fourth point, and the dialog can still list the folder on read rights alone.
- Open
services.mscand read the Log On As account of the CODESYS Control Win service. - On the PlcLogic folder, open Properties, then Security, and confirm that account, or a group holding it, has Modify and Write.
- From an elevated session, create a plain text file in PlcLogic. A failure there points at the rights; a success sends you back to the path checks.
The read-only checkbox is the wrong control for this fault. The Security tab is the one that governs the service account.
How does the whole fix run in an example scenario?
One recipe definition named dosing and 2 recipes, batch_7 and batch_8, give a count you can follow: 0 files in PlcLogic before the fix, 2 after it, and the folder count runs 0, 1, 2, 2 through the saves.
The line runs on a PC of its own, so the disk in play is that machine's C:\ProgramData\CODESYS\CODESYSControlWinV3x64\. Its instance ID is 58719825, which makes the allowed folder C:\ProgramData\CODESYS\CODESYSControlWinV3x64\58719825\PlcLogic. The recipe directory moves there, straight to the folder. The Recipe management in the PLC option is on. The c:\recipes\ line someone added to CODESYSControl.cfg is reverted, and the service restarts once.
Save batch_7: batch_7.dosing.txtrecipe appears in PlcLogic, 1 file. Save batch_8: 2 files. Save batch_7 again under the same name: still 2 files, and the modified timestamp on batch_7.dosing.txtrecipe advances. Load batch_7 back, and the stored values return to the recipe variables. Three saves and one load in total.
How do you confirm the save, the overwrite and the load?
Confirm three results in the order they happen: a <recipe>.<definition>.txtrecipe file appears in PlcLogic after the first save, its modified timestamp advances after the same recipe saves again, and loading it returns the stored values into the recipe variables.
Check one result at a time and stop at the first failure. A missing file sends you back to the path checks. Load with the process in a state where new setpoints are safe to apply; the load writes values into the running application.
Recommendation: Point the recipe directory at the PlcLogic folder of the instance your device connection targets, with nothing after PlcLogic, keep the Recipe management in the PLC option on, and test with two saves and one load. Work the service account rights in services.msc only when that path is already exact and the .txtrecipe file still never appears.
Questions
Do the recipe files land on the engineering PC or on the runtime host?
On the runtime host. The runtime resolves the directory you set, so c:\recipes\ on the engineering laptop is a different disk from the one the service writes to. If the PC in front of you has no C:\ProgramData\CODESYS\CODESYSControlWinV3x64 folder holding that instance ID, the runtime you are editing runs on another machine. Find that machine before you judge any path.
Several runtimes share one PC; which PlcLogic folder is mine?
Each runtime instance has its own numeric folder under C:\ProgramData\CODESYS\CODESYSControlWinV3x64, each with its own PlcLogic inside. Use the folder of the instance your device connection targets. The ID in the recipe directory and the ID behind the device must be the same number; when they differ, a save fails exactly the way it fails against c:\recipes\.
Can the recipe directory point at a network share?
The recipe documentation names one storage for recipe management in the PLC, the runtime's PlcLogic folder, and describes no share. Save in PlcLogic and copy the .txtrecipe files to wherever you archive them, on a schedule you set yourself.
What happens to the old recipe files after the device is re-created?
The old instance folder stays on disk under the old ID, and the new runtime will not accept it as its recipe directory. Copy the .txtrecipe files you still need into the PlcLogic folder of the new instance ID, then load one and check that the stored values arrive in the recipe variables.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.