Recipes

Functional Explanation

The recipe system allows named sets of parameter values to be stored, loaded, and applied to project variables at runtime. A recipe type defines a group of variables that belong together as a parameter set. Each recipe is one named row of values for those variables. Operators can apply a recipe to write all its parameter values to the linked variables in one action, or take a snapshot to capture the current variable values as a new or updated recipe.

Recipes are managed at runtime through the RecipeManagerObject placed on a page. Recipe types and variable linking are configured by administrators directly within the RecipeManager interface. There is no separate configuration page for recipes in the system menu.

Recipe Types

A recipe type is a named group that collects a set of variables together under one recipe category. Each recipe type can contain multiple individual recipes (sets of values). Administrators create and manage recipe types from the RecipeManager gear icon, which is visible only to users in the Administrators group.

Recipes

A recipe is one named set of parameter values belonging to a recipe type. Each recipe stores a value for every variable linked to its recipe type. Operators can add, edit, delete, import, and export recipes from the RecipeManager at runtime.

Recipe Type Parameters

By default every recipe value is edited as free text. A recipe type can declare its parameters as Recipe Type Parameters, each with an Editor that decides how the value is edited in the Recipe Manager: a checkbox or a selection list instead of a text field. The value itself stays a text value in the recipe, in exports and in imports; the editor only decides how the operator enters it and how it is displayed.

Administrators manage the list from the Recipe Manager gear icon: Edit Recipe Types, then the Parameters action of a recipe type. The Recipe Type Parameters dialog lists one row per parameter with its Editor, its options and a preview. Add Parameter offers the parameter names the recipes and the linked targets of the type already carry, Import CSV and Export CSV exchange the whole list (columns Parameter, Editor, CheckedValue, UncheckedValue, Items, Values), and the option Add missing parameters to every recipe of this type appends a blank value for every listed parameter that a recipe lacks. Every listed parameter is stored, including parameters left on Auto.

Administrators also see an Editor icon on every row of the parameter table in the Recipe Manager. The icon shows the editor of that row. A solid icon means the parameter is a Recipe Type Parameter and opens the dialog on that row. A dashed icon means the recipe carries a parameter the recipe type does not declare yet; it asks Add to the Recipe Type Parameters, optionally together with the other undeclared parameters of the recipe, with Add or Add and edit. Add Parameter in the Recipe Manager is unchanged and adds a parameter to the selected recipe only.

A Checkbox editor writes its Checked value or Unchecked value; when both are empty the values True and False are used, which is what Snapshot stores for a Boolean variable. A Selection editor offers the Items; the matching entry of Values is written, and when Values is empty or its count differs from Items, the items themselves are written. A recipe value that is not in the list, for example from an older recipe or an import, is shown as Custom with the same marking as an empty value and blocks Load until a listed option is chosen or an Administrator widens the list. With a target selected, the Current Value column of a Selection parameter shows the item label of the live value.

Linking Variables to a Recipe Type

A variable takes part in recipes through two fields on its configuration page (Modbus TCP Variables, OPC UA Variables, Ethernet/IP Variables, DNP3 Variables, MQTT Variables, Local Variables, and the other protocol variable pages): Recipe Targets and Recipe Parameter Name. Both must be set for the variable to be included in a recipe.

Recipe Targets is the name of the target this variable belongs to. It is a free name and does not have to match a recipe type name, because types and targets are connected separately with Link Targets. It supports the placeholder {Device}, which resolves to the owning device name, so one naming rule can spread a set of variables across several devices. {DeviceName} is accepted as a legacy alias for {Device}.

A variable can belong to several targets. Enter the targets as a comma-separated list, for example {Device}EntryTemp,{Device}EntryAll: the variable is then a parameter of PLC1EntryTemp and of PLC1EntryAll, and a recipe of either target writes it. This allows one recipe type per section next to one recipe type that covers all sections. Spaces around the commas are ignored.

Recipe Parameter Name is the explicit name of the parameter this variable represents inside the recipe. Variables that fill the same role across different targets share the same Recipe Parameter Name, which is how Load and Snapshot match values to variables. Because the parameter name is set explicitly, several recipe instances can live inside one device: for example two production lines on the same PLC, where {Device}.Line1.Flow and {Device}.Line2.Flow each carry Recipe Parameter Name Flow but different Recipe Targets (Line1 and Line2). A variable with an empty Recipe Parameter Name is not included in any recipe.

Once both fields are set, the variable becomes a parameter of that target, and every recipe of the recipe type linked to that target can write it.

Linking a Recipe Type to a Target

A recipe type must be linked to a target before it can be applied. A target is not created in the Recipe Manager and it is not a page object. A target appears as soon as at least one variable carries that name in its Recipe Targets field, with the {Device} placeholder resolved, so a variable set with Recipe Targets {Device}EntryTemp on PLC1 and PLC2 produces the targets PLC1EntryTemp and PLC2EntryTemp. The link tells the Recipe Manager which recipe type may be applied to that target. A target is linked to one recipe type.

Target linking is done from within the RecipeManager interface by administrators using the Link Targets button.

Runtime Operations

The following actions are available to operators from the RecipeManagerObject at runtime. Add Recipe, Edit Recipe, Delete Recipe, Add Parameter, value changes, Snapshot, Import and moving a recipe to another type require the Recipe Edit Right of the user group. Load requires the Recipe Load Right in addition to the write rights on each linked variable. Members of the Administrators group hold both rights. Buttons a user may not use are not shown.

With Part 11 compliance mode enabled and Download recipes to the process selected under Signature Required Actions, Load opens the Electronic Signature dialog and writes the values after a valid signature. Cancel leaves the target unchanged.

Configuration API and MCP

Recipe types are also available as the RecipeTypes entity of the Configuration API, on /API/Config/RecipeTypes with GET, POST, PUT and POST /Delete, and through the MCP configuration tools with the entity type RecipeTypes. One document carries the recipe type with its recipes and their parameter values, the targets linked to it and its Recipe Type Parameters, so the recipe set of a plant can be created, read and updated from a script or from an AI assistant without opening the Recipe Manager.

A target belongs to one recipe type. Linking a target on one type unlinks it from any other type, exactly as the Link Targets dialog does. Only targets that variables declare in their Recipe Targets field are accepted; the validation message lists the known targets. On an update, a list that is omitted keeps the current content and a list that is given replaces it whole. A recipe with a known id keeps that id, a recipe without an id is added.

Loading a recipe onto a target remains an operator action in the Recipe Manager. The Postman collection EnvisionSCADA Config API contains worked requests in the Recipe Types folder.

Notes

Recipe types, target links and Recipe Type Parameters are managed by users in the Administrators group from within the RecipeManager runtime interface. The gear icon for type management is only visible to administrators.

Renaming a recipe type does not affect the variables. The target links and the recipes are stored inside the recipe type and are kept. Renaming a target works differently: change the Recipe Targets field on every variable of that target, then link the new target name to the recipe type again, because the old link points to a target that no longer exists.

To apply one recipe across several devices, give the matching variables on each device the same Recipe Parameter Name and use the {Device} placeholder in Recipe Targets so each device forms its own target. To keep several recipe instances inside one device, give them the same Recipe Parameter Name and different Recipe Targets.

When a variable belongs to several targets, a value written by a recipe of one target also changes the current value seen by the other targets. Recipe Parameter Names must be unique within every target the variable belongs to, so a combined target needs parameter names that differ between the sections it collects.

Variables that resolve to duplicate Recipe Parameter Names within one target are flagged in the target link overview. Resolve duplicates before applying recipes to avoid unpredictable write behavior.

In exports and in the configuration API the field is named RecipeTargets. A project exported by an older version used the name recipes for the same field, and it is read back correctly on import, so an older export still loads. An integration that writes this field over the API should use RecipeTargets.