Multiple Views in a Single Recipe
  • 29 Nov 2024
  • PDF

Multiple Views in a Single Recipe

  • PDF

Article summary

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

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

  2. when performing the same inspection on multiple parts or angles of a part (eg., presence/absence of studs on five 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:

OVModel
8.89 MB


Importable Example flow for download:

Note

Configuration inside Classification Block Logic nodes will be lost on import.

flows (2)
7.76 KB

This example is a simple version with two 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 the presence/absence of bits on two sides of a drill bit case. One side has five bits on the bottom, and the other side has eight bits on both the top and bottom. We will call the side with 16 bits side A and five bits side B.

Side A (16 bits)

Side B (five bits)

Create and Train a New Recipe

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.

  1. Create a recipe. In this case, it is a classification recipe but this same principle can be used with segmentation.

  2. Set up the Template Image and Alignment for the first view:

    Note

    The Aligner is unavailable when inspecting more than one view on the same recipe. The Template Image and Aligner is only used to set the base image for the Inspection Setup.

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

  4. Return to the Template Image and Alignment to replace the image with side B, either from a new capture or from the library.

  5. Use the lock icons next to each ROI to avoid moving any ROIs from side A, then draw and name the ROIs for side B.

    Note

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

  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.

    Labeling side A, Pass

    Labeling side A, Fail

    Labeling side B, Pass

    Labeling side B, Fail

Configure Node-RED Logic

  1. Navigate to the IO Block (Configure IO from the Recipe Editor) to open your Node-RED flow. Create a source to tell the OV20i which side is currently being inspected. This can be robot position data, information from the PLC, or anything else you want to use. In the example below, we will simulate this using two Inject nodes, one that sends the string "A" and one that sends the string "B".

  2. 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:

    flow.set('side',msg.payload);
    return msg;


    image(86)

  3. 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.

    image(87)

  4. 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 is active.

    image(88)

    Note

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

  5. 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.

    image(89)

  6. 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.

Test the Recipe

This completes the Node-RED flow and now it's time to test the recipe end-to-end.  

  1. 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.

  2. Now when we remove a drill bit on the A-side, and inspect again, we get the failure result we want.

  3. 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.

  4. 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


Was this article helpful?

ESC

Eddy AI, facilitating knowledge discovery through conversational intelligence