Strategies for inspecting product variants

In many applications the same project is used to inspect many variants of the same product. The terms Product Switch, Project Switch, Job Switch, SKU Switch, Product Changeover, and Recipe Selection are used in various industries. These terms are also used differently by various smart camera providers. In Matrox Design Assistant, the primary mechanism for working with product variants is recipe selection. In some circumstances, other strategies based on configuration files or switch steps are more appropriate.

Using recipes

It is common for a majority of the steps in a project to involve things that do not vary for a particular hardware installation, such as PLC communication, I/O, acquisition, logging, and archiving. Having several recipes in a single project allows you to leave these steps intact while altering the step inputs and variables that must change for each product variant.

For example, a slow moving conveyor might be used to inspect car chassis with 40 different wheel options. To verify that the correct wheel option has been installed for each vehicle, you can use a ModelFinder step and have it search for a different model depending on the current recipe.

Using a different recipe for each product variation has several advantages:

It is easy to identify which steps differ between recipes in the flowchart.
Changing recipes is fast, taking less than 2 seconds in almost all cases.
Industrial communication connections are not lost while switching recipes.
New recipes can be created from the operator view at runtime, allowing new product variations to be inspected without the need to reconnect your runtime platform to your development computer.
You will only need to maintain settings that do not change for each variant in one place.

For more information about working with recipes, see the Recipes overview section in Chapter 55: Recipes.

Using text and spreadsheet files

The TextReader step can be used to import information from text and spreadsheet files at runtime. If your project must handle a large number of product variants and the differences between them can be defined entirely using numbers and strings (for example, not requiring the loading of new models), loading information from a text file or spreadsheet might be the best method for changing inspections settings. This is particularly effective if such a spreadsheet already exists (for example, as part of your product ordering system).

For example, a high speed production line might produce rivets in a variety of sizes. Each type of rivet is defined entirely by 3 numbers: head diameter, shaft diameter, and length. It is not necessary to build a new recipe for the hundreds of possible combinations. Instead, you can use a TextReader step to read these numbers from a CSV file that was generated using third-party spreadsheet software. You can reference each variant by column number, potentially allowing easy integration with other systems (such as PLCs and product ordering software).

For more information on reading information from a CSV file, see the Reading CSV files subsection of the TextReader step overview section in Chapter 47: TextReader and TextWriter steps.

Using the Switch step

When changing the settings of existing steps is insufficient to inspect a product variant, you can use the Switch step to perform different steps as required. This makes switching between product variants essentially instantaneous.

For example, a medium speed production line might produce substrates with up to 80 inserts. Each substrate can have a different number and placement of inserts, with 20 different configurations offered. The order and thickness of each insert needs to be inspected. You can use a different set of steps for each configuration and control which steps are executed using a Switch step.

Using the Switch step to manage product variants has some disadvantages when compared to recipes and the TextReader step:

Your runtime platform must allocate resources for every step in your project, including steps that are bypassed by a flow-control step. Even if a single product variant requires only a modest amount of memory to inspect, having a significant number of cases with memory-intensive steps (such as the ImageProcessing step or the ModelFinder step) can lead to out of memory errors. For more information on memory management, see the Memory usage section in Chapter 59: Optimizing your runtime projects.
New cases cannot be added to a project at runtime.

Using hybrid strategies

When product variants also have sub-variants, it can be useful to manage them with a combination of the methods mentioned above. This is particularly effective when the sub-variants only differ by a few details.

For example, a medium speed production line might produce the casing for many different shapes and sizes of television remote controls, intended for sale in multiple regions. The silkscreen labels must be inspected to ensure that they have been printed correctly. For any one type of remote, most of the labels are pictographs that do not vary by region. You can use recipes to configure the ModelFinder steps in your project to inspect the pictographs on each remote variant. However, some of the labels contain text which varies by region. Since only a small number of labels vary depending on the target region, you can use a Switch step to change inspection settings for those particular labels.