Before using recipes in your project, you must indicate which steps, platform configuration settings, and variables you might need to change between recipes, and optionally prepare your operator view for creating and modifying recipes. There are also special considerations you must be aware of when re-deploying a project which utilizes recipes.
At design-time, most tasks involving recipes (for example, creating, deleting, and comparing them) are done from the Recipes pane. By default, all projects contain one recipe called MainRecipe. To create additional recipes, use the Create recipe button in the Recipes pane.
To identify a step as recipe-dependent, right-click on the step and select Persistent per recipe. Steps that are recipe-dependent will have a small R at the bottom-left corner.
The following steps cannot be recipe dependent:
Flow control steps, such as the Switch step. If you need to change these steps between recipes, consider using a recipe-dependent variable to control them.
The Status step named Status in your main flowchart. If you need to vary some part of this step between recipes, consider using an additional Status step, or recipe-dependent variables.
You must be careful when deleting or renaming steps that are linked to by recipe-dependent steps in a project that has already been deployed. For more information, see the Avoiding broken links in recipe steps section later in this chapter.
To identify a platform configuration setting as
recipe-dependent, click on the alternate options button
to the right of the platform configuration setting in
the
Platform Configuration dialog and select Persistent per recipe. If
this option is greyed-out, the selected setting cannot be
recipe-dependent.
To identify a variable as recipe-dependent, change its Persist value option to Persistent per recipe in the Manage Variables dialog, accessible from the Flowchart context menu.
If you modify the persistence of a step, variable, or platform configuration setting that is already Persistent per recipe, it will no longer be recipe-dependent and will retain the values from the currently selected recipe. Configurations for that step, variable, or platform configuration setting in other recipes will be lost permanently when the project is saved.
Each recipe is referenced by a unique ID and name, both of which you can modify from the Recipes pane. These are used when switching recipes at runtime using the LoadRecipe step. Recipe names can also be used to specify unique image sets for each recipe in your project. For more information on having separate image set folders for each recipe, see the Recipe subfolders for image sets subsection of this section.
The numeric ID value is useful in cases where you do not want to use a string to reference the recipe (for example, changing recipes from a PLC).
Names are not case sensitive, can be in any language, and cannot contain characters that are used in forming file paths. Your project will be easier to manage if you give recipes meaningful names.
To modify recipe-dependent values for a particular recipe, select that recipe in the Current recipe dropdown list of the Recipes pane. Any changes you make to recipe-dependent values in your project will apply only to this recipe. If you need to apply a change to other recipes, use the Apply multiple dialog, accessible by right-clicking on the value.
The following are examples of things that you might want to vary between recipes:
The value of a variable that is used as a condition in flow control.
The search region for a particular model of a PatternMatching step.
The limit values for an ImageProcessing step.
The model searched for by a ModelFinder step.
The contents of a collection, such as the collection of models of a PatternMatching step.
All of the recipes in your project that exist on your development computer are listed in the RECIPES tab of the Deploy Project dialog. Only recipes with a checkmark will be deployed to the runtime platform.
Re-deploying a recipe will overwrite the existing values for that recipe on your runtime platform. If you have already made modifications to the recipe at runtime, and you need to keep those changes, you must Import or Synchronize the recipe to your development computer before modifying it and re-deploying. There are additional considerations if steps or variables linked to by recipe dependent steps have been deleted or renamed since the project was first deployed. For more information, see the Avoiding broken links in recipe steps section later in this chapter.
The first time you deploy your project to a runtime platform, all of your project's recipes will be selected for deployment. When re-deploying your project, typically only the current recipe is automatically selected. Deselecting a recipe that already exists on your runtime platform will prevent updates to that recipe from being deployed. The recipe will not be deleted on your runtime platform.
When you start a project on your runtime platform, normally the startup recipe will be the recipe that was open when the project was last properly terminated. Deploying or re-deploying your project resets the startup recipe on the connected runtime platform. Matrox Design Assistant uses the following procedure to determine the new startup recipe:
If the current recipe at design-time is selected for deployment, it will be set as the startup recipe.
Otherwise, if the existing startup recipe has not been deleted, it will be set as the startup recipe.
If no recipe meets the other conditions, the first recipe listed in the RECIPES tab of the Deploy Project dialog selected for deployment will be set as the startup recipe.
You can import a recipe that only exists on your runtime platform to your development computer. You can synchronize recipes on your development computer with modifications that have been made on your runtime platform (for example, a search region modified in the operator view). You can import or synchronize selected recipes from the Recipes pane when your project is not running on your runtime platform.
Synchronizing a recipe from your runtime platform will permanently overwrite that recipe on your development computer. The overwritten version cannot be recovered. If you need to keep both sets of values, you must use 2 recipes. Note that other persistent values will also be overwritten during import or synchronization.
Recipes that are imported or synchronized will automatically be selected for deployment the next time you re-deploy your project.
You can specify that an image set should use a different source folder for each recipe. This is useful for managing different test images for each recipe. If you select the Append recipe subfolder option in the Images Sets page of the Platform Configuration dialog, the image set will use images from the subfolder, of the specified source folder, that has the same name as the current recipe. For example, if the source folder for the image set is {PATH("DA Documents")}\\Images and the current recipe is MyFavoriteRecipe, the image set would look for images in C:\Users\YOURUSERNAME\Documents\Matrox Design Assistant\Images\MyFavoriteRecipe (on a Windows platform). For more information on specifying a path, see the Specifying a path section in Appendix A: Expression syntax.
If you create a new recipe while the Append recipe subfolder option is selected for an image set, Matrox Design Assistant will automatically create a subfolder in the source folder for that image set. That subfolder will be given the same name as the default name given to the new recipe (for example, NewRecipe2). Matrox Design Assistant must have write permission at this location to automatically create these subfolders.
If you change the name of a recipe, you will also have to manually change the name of any image set subfolders to match.