DOCUMENTACIÓN CON IA
¿Qué desea saber?
Múltiples vistas en una sola receta
This guide 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:
- cuando no hay suficiente tiempo entre capturas para cambiar la receta,
- cuando se realiza la misma inspección en varias piezas o ángulos de una pieza (p. ej., presencia/ausencia de studs en cinco posiciones diferentes en la carrocería de un automóvil). En este caso, este método evita tener que entrenar el mismo modelo (presencia/ausencia) varias veces en diferentes recetas.
The following 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. In 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 (5 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.
-
Create a new recipe. In this case, it is a classification recipe but this same principle can be used with segmentation.
-
Set up the Template Image and Alignment for the first view:
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.

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

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

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

For more complex recipes, repeat this process for as many different views as you want to inspect.
- 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
-
Navigate to the IO Block (Configure IO from the Recipe Editor) to open your Node-RED flow.
-
Create a source to tell the OV10i 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 nodos Inject, uno que envía la cadena "A" y otro que envía la cadena "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:
flow.set('side',msg.payload);
return msg;

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

For more complex recipes, repeat this process for as many different views as you want 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.

Test the Recipe
Now that the Node-RED flow is configured, it's time to test the recipe end-to-end.
- Primero, enviaremos el comando del lado A usando nuestro nodo Inject de Node-RED. Luego utilizaremos la HMI para inspeccionar una pieza buena. Observe cómo, a pesar de que una de las regiones del lado B falla, toda la inspección pasa.

- Ahora, al quitar una broca en el lado A, y volver a inspeccionarlo, obtenemos el resultado de fallo que queremos.

- Pasando al lado B, enviamos la señal B usando nuestro nodo Inject de Node-RED y refrescamos la sección de la variable de flujo en el panel de datos de contexto para asegurarnos de que está almacenada.

- Ahora, al cambiar al lado B de una pieza buena, vemos que la inspección pasa a pesar de que todas las regiones del lado A fallan.

¡Felicidades! Ahora sabe cómo usar una receta y un modelo en múltiples vistas de una pieza. Esto permitirá inspecciones complejas a altas velocidades y una integración estrecha con robots. También le ahorrará un tiempo significativo que se gastaría entrenando múltiples modelos que realizan la misma inspección, solo en diferentes vistas





