The standard route – and why almost everyone takes it
If you want to manage parameter sets, machine configurations or recipes in CODESYS, you first reach for the built-in Recipe Manager. It's there, it's free, and for the simple case it does what it should: you define a variable list – the recipe definition – and store several value sets against it. Using the RecipeManCommands function block, recipes can also be read, written and saved to files from within the application.
For a manageable, fixed parameter list, that's a solid solution. Honestly: if your project needs exactly that, you don't need anything else.
It gets interesting where reality is more complex than "fixed list, a handful of value sets." And in modern machines, that's the rule rather than the exception.
How the native model works
The key point for understanding the limits: the Recipe Manager is an engineering-time tool. The recipe definition – that is, which variables belong to a recipe – is set at development time in the Recipe Manager object. Each entry is bound to the full instance path of a variable. At runtime the values are then buffered in text files on the controller, named according to the fixed scheme <recipe>.<recipedefinition>.txtrecipe.
This model comes from a world in which a machine's data structure is fully known at programming time and unchangeable afterwards. That very assumption no longer holds in many of today's projects.
Where it grinds in practice
The following points are not theoretical concerns – they show up regularly in the CODESYS forums, usually with home-grown workarounds as the answer.
1. The variable list is static. What belongs to a recipe is decided at engineering time. If the need changes at runtime – a module is added, an option is switched on, a customer wants one more parameter – you have to touch the definition, recompile and roll it out. For a product that runs in many variants at customer sites, that's a maintenance multiplier.
2. Bound to instance paths – fragile under refactoring. Every recipe variable hangs on its full path. Anyone who wants to get the name cleanly back from the recipe into the application ends up maintaining a separate label column and copying the full variable paths in by hand – the recipe editor offers no copy-paste for this. It's tedious to begin with and becomes a source of errors every time someone renames or moves a variable.
3. File and flash issues. Recipes live as text files in the controller's file system. Save often, and on controllers with limited write cycles you risk premature flash wear – which is why developers build their own timer and change-detection logic instead of simply being able to save. If an unexpected power loss hits mid-write, the file can be left corrupted.
4. Not real-time capable. The recipe commands access files internally and take several milliseconds depending on the device. They explicitly do not belong in watchdog-monitored tasks – which makes integration into the cyclic flow awkward.
5. Friction with the API. From methods that report success without actually writing, to a reload that quietly does nothing, to sample projects that won't compile cleanly: programmatic use costs more nerves than you'd expect from a "built-in" feature.
The common denominator
None of these points is a bug in the strict sense. They are the logical consequence of a static, file-based model that thinks in design-time terms. As soon as your requirement reads "dynamic, structured and changeable at runtime," you're working against the tool's core assumption – and that's exactly when your code fills up with workarounds.
The runtime-based counter-design
The alternative inverts the core assumption: instead of freezing a fixed variable list at engineering time, you manage data at runtime – dynamically registered, structured and self-describing.
"Self-describing" is the heart of it. A value carries its metadata with it – logical name, limits (min/max), unit – rather than being an anonymous entry behind a variable path. Three things then follow almost by themselves:
- Refactoring-safe: access is via a logical name, not the instance path. Renaming in code doesn't break the data management.
- Extensible at runtime: new values are added without touching the definition in the engineering tool and rolling everything out again.
- HMI-ready: because every value knows its name, limits and unit, the operator interface can build on it generically instead of being wired up for each parameter individually.
How we solved it
This exact model is built into the AS Data Manager. Designed as a library for flexible, runtime-based data and recipe management, it replaces static configuration with a dynamic, structured approach – so your data always reflects the current state of the application, not a state frozen at engineering time.
In practice that means: all machine data structured in one place, reliably stored, available at any time and directly connected to the operator interface. Your team builds features instead of programming data management.
This is no lab experiment. The AS Data Manager already runs in hundreds of production machines at machine and device manufacturers – which is exactly why it is now also available in the CODESYS Store. In mechanical engineering that's the decisive argument: not an untested experiment, but a building block that has long proven itself in the field.
And because you should only believe something like this once you've tried it yourself: the AS Data Manager can be used in a free tier with up to 10 values without a licence. That's enough to test the concept on a real piece of your application before any decision is on the table.
When the native solution is still the right one
To keep this fair: if you have a small, fixed parameter list that doesn't change over the machine's lifetime, need no runtime dynamics and are happy with file-based storage – then the built-in Recipe Manager is exactly right, and you don't need an extra library. The switch pays off where variant diversity, runtime changes, refactoring safety or a generic HMI connection become the issue.
If you just recognised yourself in one of these points, it's worth an afternoon's look.