Seleccione su idioma
Viper.NET acelera y simplifica la creación de aplicaciones de procesamiento de imagen en la industria. En Viper.NET todo el proceso, desde el inicio hasta el resultado está listo, integrado y automatizado. Los usuarios pueden confiar en interfaces bien desarrollados que son utilizados y optimizados continuamente tanto en nuestras máquinas como integrados en otros fabricantes. Un modelo flexible de plugin y otras muchas características de libre configuración de Viper.NET hace posible una rápida extension de las funciones requeridas por el usuario.
Viper.NET utiliza Cognex VisionPro, una de las mejores librerias de vision para PC del mundo. Además Viper.NET da la oportunidad de utilizar las enormes funciones de HALCON.
Viper.NET usa grupos de herramientas de Cognex para la conexión con Cognex VisionPro. Cada grupo de herramientas describe una tarea de procesamiento de imagen. Un grupo de herramientas está integrado en Viper.NET usando el llamado ToolGroupItem que define (además del grupo de herramientas) algunas cosas adicionales:
En Viper.NET los ToolGroupItems están unidos en "Jobs". El job es el responsable de la ejecución de un ToolGroupItem. Solo un ToolGroupItem puede ser ejecutado por cilclo. Sin embargo varios jobs puede ser definidos y ejecutados en paralelo. Un tipo de vision consiste de 1 a n jobs.
Todo job es asignado a una estación en la cual hay disponible un interface externo. Las estaciones no son dependientes de los tipos, sino pudiendo ser usadas desde diferentes sistemas de control (Ej. PLCs) al mismo tiempo.
Debido a esta estructura un sistema deo control con un solo trigger puede iniciar varias tareas de procesamiento de imagen en paralelo. Esto reduce significativamente el esfuerzo de integrar inspección óptica automática por ejemplo en una máquina de mesa rotatoria. El handshake de comunicación entre el sistema de control y Viper.NET consiste solo en unos cuantos Bits. Tambien es posible definir varias estaciones que se comunican don diferentes PLCs.
Para procesar y analizar las imágenes lo primero de todo es adquirir las mismas.
Viper.NET provee interfaces intuitivos para la adquisición de imágenes:
CogAcqFifo (Cognex Standard)
Además de estos, otros interfaces pueden ser integrados de forma rápida y directa si fuese necesario.
En particular la conexion nativa de cámaras GigE tiene muchas ventajas en comparación con los drivers genéricos.
Ejemplo SVS Vistek: Las cámaras designadas con SVS Vistek están equipadas con salidas PWM que son acitvadas directamente o en modo de sequencia. Con estas salidas PWM, se pueden controlar directamente las luces de la cámara, con la opción de controlar la intensidad de estas luces de forma muy precisa a través de la señal PWM.
Ejemplo Baumer: Durante la adquisición de imágenes la cámara genera mensages que son recuperados o capturados. Un mensage muy imprtante es "EXPOSURE_END", esto indica el final de la exposición del chip. Este sería el tiempo mas corto en el que se podría mover la parte de nuevo. El mensage es procesado por el sistema antes de adquirir la imagen. Esto ahorra bastantes milisegundos en el manejo de las unidades.
In Viper.NET todas las fuentes de imagen están usadas y configuradas fuera de la tarea de procesamiento de imagen. El análisis no comienza hasta que todas las fuentes de imagen son adquiridas. Normalmente la adquisición se realiza en paralelo. El número de fuentes de imagen no está limitado.
Otra ventaja de Viper.NET es el control integrado de la iluminación que permite la definición de escenas de luz adecuadas a cada situación.
La misma escena de luz puede ser utilizada por varias cámaras o solo por una.
Hasta ahora el módulo de control de iluminación soporta los siguientes controladores:
Viper.NET soporta numerosos sistemas de control, los cuales están integrados y abstraídos con un módulo separado de Entradas/Salidas.
Esta integración tiene múltiples ventajas:
El módulo de Entrada/Salida se puede configurar y probar usando la herramienta "GInOutHwExplorer" en cuestión de minutos, lo cual reduce la duración de la puesta en marcha.
La funcionalidad de Viper.NET es extensible con plugins, estos permiten hacer cambios en el proceso, o interfaces de usuario, o integración de procesos totalmente automáticos. La misma funcionalidad del procesamiento de imagen está encapsulada en un plugin. Esta es la razon por la cual el software es también capaz de realizar el control de proceso en aplicaciones laser. Este método de desarrollo se utiliza en casi todo los proyectos de software de GEFASOFT.
En Viper.NET las imágenes adquiridas durante el proceso son automáticamente almacenadas. El usuario puede en todo momento elegir que imágenes son guardadas (Ej. Solo imágenes de partes malas).
Viper.NET ayuda al usuario a analizar las imágenes después del proceso. Todas la imágenes guardadas puede ser procesadas automáticamente.
Los resultados son mostrados en la ventana principal de Viper.NET. El procesamento de una sola imagen o imágenes dentro de un directorio o subdirectorio también es posible. De esta forma modificaciones en parámetros o flujos de trabajo pueden ser verificadas de forma rápida. Sistemas de control como PLCs pueden iniciar el análisis en modo automático (Ej. ejecutar nuevamente las rutinas de procesamiento de imagen en imágenes de referencia).
Los resultados de una inspección son mostrados en las llamadas "views", las cuales son configuradas por "ToolGroupItem". Cada "view" puede tener un número de SubDisplays:
Cada usuario puede tener su propia visualización. Esto permite la opción de crear sofisticadas vistas para super-usuarios (Ej. Análisis), e imágenes estandar / error display durante la producción normal.
Basado en un job ejemplo de Cognex (Detectar un defecto usando filtro NxM medio)
Los valores por defecto y los resultados tienen que ser a menudo intercambiados con sistemas superiores de control como PLCs. Viper.NET dispone también de un efectivo mecanismo para ello.
En el módulo de Entrada/Salida se pueden crear y nombrar variables que definen tanto el origen y el destino del área de datos como la conversión de estos. Estas variables pueden ser conectadas a un determinado terminal durante la configuración de un ToolGroupItem.
Los datos de entrada son leidos al inicio del proceso (trigger) y escritos en el correspondiente terminal antes de la ejecución del ToolGroup. Los datos de salida son enviados al sistema de control solo si no hay un error en la ejecución (esto puede ser configurado de forma diferente).
Sobre todas estas prestaciones se puede activar un bit de resultado en el nivel de Entrada/Salida. El estado de un bit (High/Low) se determina durante la validación de los resultados de los datos de análisis de los terminales.
