Der Standardweg – und warum ihn fast jeder nimmt
Wer in CODESYS Parametersätze, Maschinenkonfigurationen oder Rezepte verwalten will, greift zuerst zum eingebauten Recipe Manager. Er ist da, er ist kostenlos, und für den einfachen Fall tut er, was er soll: Du definierst eine Variablenliste – die Rezeptdefinition – und speicherst dazu verschiedene Wertesätze. Über den RecipeManCommands-Funktionsbaustein lassen sich Rezepte auch aus der Applikation heraus lesen, schreiben und in Dateien sichern.
Für eine überschaubare, feststehende Parameterliste ist das eine solide Lösung. Ehrlicherweise: Wenn dein Projekt genau das braucht, brauchst du nichts anderes.
Interessant wird es dort, wo die Realität komplexer ist als „feste Liste, ein paar Wertesätze". Und das ist in modernen Maschinen eher die Regel als die Ausnahme.
Wie das native Modell tickt
Der entscheidende Punkt, um die Grenzen zu verstehen: Der Recipe Manager ist ein Engineering-Zeit-Werkzeug. Die Rezeptdefinition – also welche Variablen zu einem Rezept gehören – wird zur Entwicklungszeit im Recipe-Manager-Objekt festgelegt. Jeder Eintrag ist an den vollständigen Instanzpfad einer Variablen gebunden. Zur Laufzeit werden die Werte dann in Textdateien auf der Steuerung gepuffert, benannt nach dem festen Schema <Rezept>.<Rezeptdefinition>.txtrecipe.
Dieses Modell stammt aus einer Welt, in der die Datenstruktur einer Maschine zum Zeitpunkt der Programmierung vollständig bekannt und danach unveränderlich ist. Genau diese Annahme trägt in vielen heutigen Projekten nicht mehr.
Wo es in der Praxis knirscht
Die folgenden Punkte sind keine theoretischen Bedenken – sie tauchen regelmäßig in den CODESYS-Foren auf, meist mit selbstgebauten Workarounds als Antwort.
1. Die Variablenliste ist statisch. Was zu einem Rezept gehört, entscheidest du im Engineering. Ändert sich der Bedarf zur Laufzeit – ein Modul kommt dazu, eine Option wird zugeschaltet, ein Kunde will einen weiteren Parameter – musst du die Definition anfassen, neu übersetzen und ausrollen. Für ein Produkt, das in vielen Varianten beim Kunden läuft, ist das ein Wartungsmultiplikator.
2. Bindung an Instanzpfade – fragil beim Refactoring. Jede Rezeptvariable hängt an ihrem vollen Pfad. Wer den Namen aus dem Rezept sauber zurück in die Applikation bekommen will, pflegt in der Praxis eine eigene Beschriftungsspalte und kopiert die vollständigen Variablenpfade von Hand hinein – im Rezepteditor gibt es dafür kein Copy-Paste. Das ist zu Beginn mühsam und wird jedes Mal zur Fehlerquelle, wenn jemand eine Variable umbenennt oder verschiebt.
3. Datei- und Flash-Thematik. Rezepte leben als Textdateien im Dateisystem der Steuerung. Wer häufig speichert, riskiert auf Controllern mit begrenzten Schreibzyklen den vorzeitigen Flash-Verschleiß – weshalb Entwickler eigene Timer- und Änderungserkennungs-Logik bauen, statt einfach speichern zu können. Kommt ein unerwarteter Spannungsverlust mitten in den Schreibvorgang, kann die Datei beschädigt zurückbleiben.
4. Nicht echtzeitfähig. Die Rezeptbefehle greifen intern auf Dateien zu und brauchen je nach Gerät einige Millisekunden. Sie gehören ausdrücklich nicht in zeitüberwachte Tasks – was die Integration in den zyklischen Ablauf umständlich macht.
5. Reibung an der API. Von Methoden, die Erfolg zurückmelden, ohne tatsächlich zu schreiben, über ein Neuladen, das kommentarlos nichts tut, bis zu Beispielprojekten, die sich nicht fehlerfrei übersetzen lassen: Die programmatische Nutzung kostet mehr Nerven, als man einem „eingebauten" Feature zutrauen würde.
Der gemeinsame Nenner
Keiner dieser Punkte ist ein Bug im engeren Sinn. Sie sind die logische Folge eines statischen, dateibasierten Modells, das zur Entwicklungszeit denkt. Sobald deine Anforderung „dynamisch, strukturiert und zur Laufzeit veränderlich" lautet, arbeitest du gegen die Grundannahme des Werkzeugs an – und genau dann füllt sich dein Code mit Workarounds.
Der laufzeitbasierte Gegenentwurf
Die Alternative kehrt die Grundannahme um: Statt eine feste Variablenliste im Engineering einzufrieren, verwaltest du Daten zur Laufzeit – dynamisch registriert, strukturiert abgelegt und selbstbeschreibend.
„Selbstbeschreibend" ist dabei der Kern. Ein Wert trägt seine Metadaten mit sich – logischer Name, Grenzen (min/max), Einheit – statt nur ein anonymer Eintrag hinter einem Variablenpfad zu sein. Damit ergeben sich drei Dinge fast von selbst:
- Refactoring-sicher: Angesprochen wird über einen logischen Namen, nicht über den Instanzpfad. Umbenennen im Code bricht die Datenverwaltung nicht.
- Zur Laufzeit erweiterbar: Neue Werte kommen hinzu, ohne die Definition im Engineering-Tool anzufassen und alles neu auszurollen.
- Direkt HMI-tauglich: Weil jeder Wert Name, Grenzen und Einheit kennt, kann die Bedienoberfläche generisch darauf aufsetzen, statt für jeden Parameter eigens verdrahtet zu werden.
Wie wir das gelöst haben
Genau dieses Modell steckt im AS Data Manager. Er ist als Bibliothek für flexible, laufzeitbasierte Daten- und Rezeptverwaltung gebaut und ersetzt die statische Konfiguration durch einen dynamischen, strukturierten Ansatz – deine Daten spiegeln damit immer den aktuellen Zustand der Anwendung, nicht einen im Engineering festgeschriebenen Stand.
Praktisch heißt das: alle Maschinendaten strukturiert an einem Ort, zuverlässig gespeichert, jederzeit verfügbar und direkt mit der Bedienoberfläche verbunden. Dein Team baut Funktionen, statt Datenverwaltung zu programmieren.
Dahinter steht keine Laborlösung. Der AS Data Manager läuft bereits hundertfach im Serieneinsatz bei Maschinen- und Geräteherstellern – und ist genau deshalb jetzt auch im CODESYS Store erhältlich. Gerade im Maschinenbau ist das das entscheidende Argument: kein unerprobtes Experiment, sondern ein Baustein, der sich im Feld längst bewährt hat.
Und weil man so etwas erst glauben sollte, wenn man es selbst ausprobiert hat: Der AS Data Manager lässt sich in einer kostenlosen Stufe mit bis zu 10 Werten ohne Lizenz nutzen. Das reicht, um das Konzept an einem echten Stück Applikation zu testen, bevor irgendeine Entscheidung ansteht.
Wann die native Lösung trotzdem die richtige ist
Damit das fair bleibt: Wenn du eine kleine, feststehende Parameterliste hast, die sich über die Lebensdauer der Maschine nicht ändert, keine Laufzeit-Dynamik brauchst und mit dem Datei-basierten Speichern gut lebst – dann ist der eingebaute Recipe Manager genau richtig, und du brauchst keine zusätzliche Bibliothek. Der Umstieg lohnt sich dort, wo Variantenvielfalt, Laufzeit-Änderungen, Refactoring-Sicherheit oder eine generische HMI-Anbindung zum Thema werden.
Wenn du dich an einem dieser Punkte gerade wiedererkannt hast, ist ein Blick den Nachmittag wert.