Conexión de GX Simulator con Factory I/O mediante OPC

La puesta en servicio virtual se vuelve valiosa cuando la escena simulada se comporta como una máquina controlada y no como una animación desconectada. En un proyecto de PLC Mitsubishi, esto requiere una ruta de datos trazable desde el simulador de ingeniería GX, pasando por un servidor OPC compatible, hasta las etiquetas de Factory I/O.

El objetivo no es simplemente hacer que una cinta transportadora se mueva. Una configuración útil demuestra la asignación de direcciones, la dirección de las señales, el comportamiento de la secuencia, los enclavamientos, la temporización, la respuesta ante la pérdida de comunicación y la lógica de reinicio antes de que las E/S físicas estén disponibles.

Una pequeña cinta transportadora virtual puede revelar defectos de asignación, temporización y recuperación antes de que lleguen a un panel de control real.

Confirma la compatibilidad del software antes de asignar las etiquetas

“GX Simulator” puede referirse a funciones de simulación asociadas con distintas generaciones de GX Works y familias de CPU MELSEC. Los productos OPC también difieren según la versión y según expongan OPC DA u OPC UA. Factory I/O ofrece opciones de controladores que pueden no admitir todas las combinaciones de la misma manera.

Registra la familia exacta del PLC, la versión de GX Works, el componente del simulador, el producto y la versión del servidor OPC, el tipo de interfaz y la versión de Factory I/O. Después, verifica que el servidor OPC pueda conectarse a esa CPU simulada. No asumas que un método de conexión que funciona con un módulo Ethernet físico funcionará automáticamente con un simulador de software.

Mitsubishi describe MX OPC como un software que expone datos de controladores programables MELSEC mediante OPC. El hardware MELSEC iQ-R más reciente también puede utilizar un módulo de servidor OPC UA integrado, pero esa arquitectura es diferente de un servidor alojado en un PC y conectado a un controlador simulado. Mantén esas rutas diferenciadas en las notas de diseño y durante la resolución de problemas.

Escribe el contrato de datos antes de configurar el software

Crea una lista de E/S con una fila para cada señal. Incluye la etiqueta de Factory I/O, la dirección del dispositivo Mitsubishi, el tipo de datos, la dirección, el significado de ingeniería, el estado predeterminado, el estado seguro, el requisito de actualización y el propietario. Normalmente, la simulación debe ser propietaria de los estados de las entradas de campo, mientras que la lógica del PLC debe ser propietaria de los comandos de los actuadores.

Esta regla de propiedad evita que dos aplicaciones escriban en el mismo punto. Un sensor fotoeléctrico simulado puede escribir en un dispositivo de entrada del PLC, mientras que el PLC escribe un comando de motor que Factory I/O lee. Si ambos lados escriben en una etiqueta, la visualización puede parpadear o parecer aleatoria aunque todas las conexiones individuales estén técnicamente activas.

Los dispositivos de bits, las palabras, los enteros con signo, los valores de punto flotante y las matrices requieren un manejo explícito de los tipos. Un cliente OPC puede mostrar un valor correctamente mientras Factory I/O interpreta el tipo o el orden de bits de forma incorrecta. Comienza con un punto booleano y una palabra cuyos valores cambiantes sean inequívocos. Amplía la configuración solo después de comprobar la dirección y el escalado.

Construye y prueba la conexión por capas

Primero, crea un programa de PLC mínimo y ejecútalo en el simulador GX compatible. Fuerza o alterna un dispositivo interno conocido y confirma que el monitor de escalera muestre el estado esperado. Esto establece que el programa, la CPU seleccionada y el simulador están funcionando.

En segundo lugar, configura el servidor OPC para ese controlador simulado. Crea solo unas pocas etiquetas de prueba. Utiliza el propio cliente o la vista de diagnóstico del servidor para confirmar la calidad, la marca de tiempo, el valor y la capacidad de escritura. Un valor marcado como “malo” o “incierto” debe corregirse en esta capa antes de abrir Factory I/O.

En tercer lugar, configura el cliente OPC de Factory I/O y busca o introduce las etiquetas verificadas. Asigna un sensor simulado y un comando de actuador. Confirma ambas direcciones de forma independiente: cambia la entrada de la escena y observa la memoria del PLC; después, cambia la salida del PLC y observa la escena.

Este método por capas separa las fallas. Si la memoria GX no cambia, el problema está en la simulación del PLC. Si GX cambia pero el cliente OPC no, revisa la configuración del servidor y el direccionamiento de los dispositivos. Si el servidor OPC funciona correctamente pero Factory I/O permanece estático, revisa la conexión del cliente, los nombres de los elementos, los derechos de acceso y la asignación de etiquetas.

La verificación por capas aísla las fallas de configuración del PLC, del servidor OPC y de Factory I/O.

Ten en cuenta la temporización de tres sistemas independientes

El ciclo del PLC, el sondeo del servidor OPC, la suscripción del cliente y la actualización de la física de Factory I/O no ocurren en el mismo instante. Un pulso de sensor más corto que el intervalo de muestreo combinado puede desaparecer antes de que el PLC lo detecte. La carga de la red o del PC puede añadir fluctuaciones incluso en una estación de trabajo local.

Los eventos importantes deben diseñarse para sobrevivir al muestreo. Un dispositivo simulado puede mantener un estado hasta recibir confirmación, o la lógica del PLC puede enclavar una transición detectada hasta que la secuencia la consuma. Alargar todos los pulsos resulta práctico para una demostración, pero puede ocultar defectos en el manejo de flancos. Adapta el comportamiento de la prueba al sensor físico y a la velocidad de producción esperados.

Mide el retardo efectivo de extremo a extremo en lugar de asumir que la frecuencia de actualización OPC configurada representa toda la latencia. Cuando la temporización sea importante para la secuencia, registra la transición de la escena, la marca de tiempo de OPC, la observación del PLC, la decisión sobre la salida y la acción resultante en la escena.

Planifica las limitaciones de OPC DA y de la estación de trabajo

OPC DA clásico utiliza la tecnología COM de Microsoft. Cuando todas las aplicaciones se ejecutan con una misma cuenta de Windows en un solo equipo, la configuración suele ser más sencilla. Las configuraciones distribuidas introducen problemas de identidad de DCOM, permisos, firewall y cuentas de servicio. Una conexión que funciona de forma interactiva puede fallar después de reiniciar si el servidor OPC se inicia con otra cuenta.

OPC UA utiliza un modelo de seguridad diferente, con puntos de conexión, certificados y políticas. Evita DCOM, pero sigue requiriendo confianza en los certificados, permisos de usuario y modelos de datos compatibles. Utiliza la interfaz que admita realmente el software seleccionado, en lugar de tratar DA y UA como etiquetas intercambiables.

Prueba deliberadamente los estados de falla y reinicio

Desconecta el cliente OPC mientras la cinta transportadora está activa. Detén el simulador del PLC. Reinicia el servidor OPC. Vuelve a abrir Factory I/O con las salidas que estaban activadas. La máquina no debe reanudar un movimiento peligroso simplemente porque reaparezcan valores obsoletos o se reconecte un cliente.

Define la respuesta ante una calidad de datos deficiente, la pérdida de comunicación y los valores de inicio. Los comandos pueden forzarse a apagado, mantenerse o gestionarse mediante una parada controlada, según el proceso. Es posible que las entradas necesiten un bit explícito de estado de comunicación para que el PLC distinga un estado falso real de datos no disponibles.

Prueba también el arranque en frío, el reinicio en caliente, la retención de contadores, la discrepancia de recetas, los sensores bloqueados, las llegadas simultáneas y el reinicio por parte del operador. Documenta el estado inicial de cada etiqueta escribible y la secuencia necesaria para entrar en modo automático.

Convierte la celda virtual en un banco de pruebas

Utiliza casos de aceptación repetibles: ningún actuador antes de los permisos de arranque; un conteo por cada producto; parada controlada al alcanzar el objetivo; tiempo de espera agotado ante un sensor bloqueado; falla por pérdida de comunicación; y recuperación predecible después de la reconexión. Las tendencias de las etiquetas y los registros de aprobación o rechazo proporcionan pruebas más sólidas que las capturas de pantalla de una escena en movimiento.

Las opciones de controladores Mitsubishi pueden consultarse en la colección de Mitsubishi Electric, mientras que el hardware de controladores más amplio se encuentra en Sistemas PLC y PAC.

OPC es solo la capa de transporte. El valor de ingeniería aparece cuando la celda virtual se convierte en un entorno de pruebas repetible para el comportamiento del PLC, la propiedad de las señales, las suposiciones de temporización, la respuesta ante fallas y la lógica de reinicio que se trasladarán a la máquina física.