Multiple Views/Captures in a single recipe

This example shows you how to set up a single recipe that can inspect different parts, angles or views without changing to other recipes.  There are a variety of reasons to do this, but two primary use cases:

1 - when there isn't enough time between captures to change recipe,

2 - Performing the same inspection on multiple parts or angles of a part (eg. presence absence of studs on 5 different positions in a car body). In this case this method prevents the need to train the same model (stud presence/absence) multiple times across different recipes.

Example Recipe for download:

Importable Example flow for download (configuration inside Classification Block Logic nodes will be lost on import):

This example is a simple version with 2 views and one inspection type, but you can use this same technique for an unlimited number of inspection types and views.  This inspection we will look for presence/absence of bits on two side of a drill bit case.  One side has 5 bits on the bottom, and the other side has 8 bits on both the top and bottom. We will call the side with 16 bits side A and 5 bits side B.

Instead of one recipe per side, because of the different layouts, we will combine both sides into one recipe so we don’t need to train the same presence/absence model twice.

Step 1:' Create a recipe, in this case it is a classification recipe but this same principal can be used with segmentation.

Step 2: Set up the aligner for the first view:

Aligner Block Only Used for ROI setup

Alignment is unavailable when inspecting more than one view on the same recipe.  The block is only used to set the base image for ROI drawing.

Step 3: Draw ROIs for side A.  Name them something that helps identify which side they belong to.  In this case I named the ROIs A1-A16.

Step 4: Return to the aligner block to replace the image with side B, either from a capture or from the library.

Step 5: Using the lock buttons next to the ROI names to avoid moving any ROIs from side A, draw and name the ROIs for side B.  

Repeat the process if needed

For more complex recipes, repeat this process for as many different views as you want to inspect.

Step 6: Label and train the classification model using images from both sides A and B.  When capturing and labeling side A, do not label the side B ROIs and vice versa.

Step 7: Configure Node-Red

Open your node-red flow in the configure IO page.  Create a source to tell the OV20i which side is being inspected currently.  This can be robot position data, information from the PLC, or anything else you want to use.  I will simulate this using two inject nodes, one that sends the string "A" and one that sends the string "B"

Since the side data coming in might be momentary, but we want to check to see which side is active, we will store the state data using a Flow Variable, which will persist until the next side information is received.  Hook your data source up to a function block containing the following code:

You can test to see if your side data is being properly stored by opening up the context data sidebar, sending a message and then hitting refresh on the Flow variable Pane.  The flow data pane will only update when manually refreshed using the small refresh button.

Once the side data is properly stored in the flow variable, add a switch node connected to All Block Outputs.  This will be the block that routes the message with the inspection data according to which side is active in the Flow Variable.   Configure it to look at the Flow Variable and route the message to port 1 if A is active and 2 if B.

Expand as needed

In more complex examples this can be expanded to as many different views as you need to inspect.

Connect each output port of the switch to a Classification Block Logic block, and configure each one according to the rules you want to inspect for that side.  The switch node will only route a message to one of the nodes at a time. The image below shows the configuration for the B-side port of the switch.  Notice it doesn't reference any of the A ROIs, so the logic will ignore that side's results when the inspection is routed through this node.

Finally hook the logic blocks up to the Inspection Pass/Fail block.  This allows the results to show up on the HMI, as well as be passed to any attached PLC or other flow component.

This completes the node-red flow and now it's time to test the recipe end-to-end.  First - we will send the A side command using our node-red inject node.  Then we will use the HMI to inspect a good part.  Notice how despite one of the B-side regions failing, the whole inspection passed.

Now when we remove an A-side bit, and inspect again, we get the failure result we want.

Moving on-to the B-side, we send the B signal using our node-red inject, and refresh the flow variable section in the context data pane to make sure that it’s stored.

Now when we flip to the B-side of a good part, we see that the inspection passes despite the A side regions all failing.

Congratulations!  You now know how to use one recipe and model across multiple views of a part.  This will allow complex inspections at high speeds and tight integration with robots.  It will also save you significant time that would be spent training multiple models that do the same inspection, just on different views.