Collapse
CollapsingX
  • - or -

Persistence and the SavePersistentData step


Persistence means that modifications made to a value at runtime will be saved and used next time the project is run. Even if you shut down and restart your runtime platform, persistent steps, variables, and platform configuration settings keep their values from the previous execution. Values that are not persistent are re-initialized every time the project is started.

Steps that change between recipes are always persistent. In addition, the following are persistent by default:

When persistent data is saved

Most changes to persistent data are saved immediately after they occur. However, changes made via either a Reconfigure step or a Store step are only saved when your project terminates properly, or when a SavePersistentData step is executed. If these steps make essential changes at runtime, you should use a SavePersistentData step to save these changes immediately afterwards to prevent data loss in the case of a power failure.

Executing the SavePersistentData step can take a significant amount of time. The time required scales with the total number and complexity of persistent steps and variables in your project. For example, if your project contains many models defined in persistent ModelFinder steps, saving persistent data can take several seconds. For this reason, you should not use the SavePersistentData step in time-critical flowcharts, such as those which handle inspection.

Modifying persistence

You can manage which variables are persistent from the Manage Variables dialog, accessible from the Flowchart menu.

You can manage which platform configuration settings are persistent from the Platform Configuration dialog. Click on the Alternate options button to the right of a platform configuration setting and modify the setting's persistence using either the Persistent or Persistent per recipe option. If the persistence options for a platform configuration setting are greyed-out, that setting cannot be persistent.

Steps that are persistent are identified with a 'P' in the flowchart. Steps which vary between recipes, and are therefore persistent, are identified with an 'R'. The persistence of a step can be changed using the Persistent and Persistent per recipe context menu items in the Flowchart Step context menu.

Re-deploying projects with persistent data

Persistent data on your runtime platform is deleted when you delete your project, or when you re-deploy it. If you need to modify a deployed project while retaining the persistent data already on your runtime platform, you must connect to your runtime platform and download the data. To do this, you can either:

  • Open the project in Matrox Design Assistant and use the Import All Recipes and Synchronize All Recipes buttons in the Recipes pane. This will import and synchronize all recipes and other persistent data of this project from your runtime platform to your development computer.

  • Import the entire project from your runtime platform using the File Import Project menu item.

Resetting persistent counters

One common use for persistence is retaining counter values between runs of a project. You can reset the count of a Status step, a Counter step, or an ImageWriter step using the ResetCounters step. The Status steps, Counter steps, and ImageWriter steps in your project will be listed with checkboxes in the ResetCounters step's Configuration pane. Selecting a Status step will reset its pass count, fail count, error count, and total count. Selecting a Counter step will reset its count. Selecting an ImageWriter step will reset its numbered file counter to the start index.

You can reset counters in the operator view by binding a button to a ResetCounters step, or to a subflowchart containing a ResetCounters step. Using a subflowchart will guarantee that the counter reset does not happen in the middle of an active inspection.

Using the Reconfigure step

Any step that is the target of a Reconfigure step is persistent by default. If a Reconfigure step reconfigures another step when executed at design-time, it permanently overwrites the step's previous values.

You would typically use the Reconfigure step to make modifications which would otherwise require multiple expressions to construct, such as those which involve working with individual pixels of an image. For example:

You can also use the Reconfigure step to modify a step's linkable inputs.