Captura de datos, recuento de producción y OEE en máquinas CNC FANUC: un escenario de aplicación
Al cambiar de turno, los contadores de las máquinas ya han variado, pero las cifras del informe siguen correspondiendo a la última anotación manual. Para saber qué productos se han mecanizado hoy y qué máquinas están funcionando en ese momento, el responsable a menudo tiene que comprobarlo en planta y después reunir los registros.
Tomemos como ejemplo un taller de mecanizado típico que utiliza máquinas CNC FANUC: si el sistema de control permite acceder a los datos necesarios, el gateway industrial inteligente de Woody puede capturar el estado de funcionamiento, el programa de mecanizado actual y la información de los contadores. Una App local en el gateway permite después organizar estas variables originales en registros de producción consultables por máquina, producto y turno.
Este planteamiento no exige unificar primero los sistemas de control de todas las máquinas ni implantar antes una plataforma en la nube. El gateway se encarga de la captura y proporciona la base de ejecución de las aplicaciones locales; la correspondencia entre programas y productos, las reglas de cálculo y las páginas del panel deben seguir configurándose o desarrollándose según las necesidades reales del taller.
Primero, leer los datos de la máquina
Antes de la conexión, el ingeniero de equipos comprueba el modelo concreto del sistema de control FANUC, las interfaces de comunicación, el controlador de comunicación adecuado, las condiciones de acceso y las variables que pueden leerse. La compatibilidad con la captura de datos FANUC no significa que todos los sistemas de control proporcionen los mismos datos.
En este escenario se utiliza una conexión Ethernet: la máquina se conecta a la red de equipos de planta y el gateway se conecta a esa red a través de Ethernet2. En la interfaz web de administración del gateway se crea el dispositivo, se selecciona el controlador de comunicación adecuado y se configuran los parámetros de comunicación y las variables que se van a capturar. Después, cada variable se contrasta con la pantalla de la máquina y con su funcionamiento real.
Para empezar, basta con centrarse en los datos de uso cotidiano: el estado de funcionamiento que expone el equipo, el nombre o número del programa actual, el contador de producción o la señal de finalización y la información de alarmas disponible. El significado de las variables de estado debe confirmarse según la lógica real de la máquina; no se puede equiparar directamente «estar en modo automático» con «estar mecanizando». El intervalo de captura también debe ajustarse a la carga de comunicación del equipo y a las necesidades de la aplicación; no se garantiza una misma frecuencia válida para todas las máquinas.
El gateway de la figura se representa con el recurso gráfico común de la serie WD2E. El modelo real, las interfaces y las condiciones de conexión deben seleccionarse según las circunstancias de planta. Este escenario solo contempla la lectura de datos del equipo; no incluye arranque o parada remotos, escritura de parámetros ni descarga de programas de mecanizado.
Del contador de la máquina a la producción por producto
Un valor de contador por sí solo no responde a la pregunta «¿Qué productos se han fabricado hoy?». El nombre del programa tampoco constituye una ficha de producto: alguien debe mantener la correspondencia entre ambos.
El personal de procesos puede mantener una tabla de productos mediante los formularios de gestión de la App local y asociar los nombres de los programas de mecanizado con la información de los productos. Una vez que el gateway captura el programa actual y el contador o la señal de finalización, la aplicación identifica el producto según las reglas acordadas, genera registros de producción con información de máquina, producto y tiempo, y los guarda en la base de datos SQLite integrada.
Lo más importante en este paso no es cuántos campos tenga la tabla, sino que los criterios de recuento se correspondan con el proceso real de mecanizado:
- Hay que distinguir los ciclos de mecanizado de la producción. Un ciclo puede corresponder a varias piezas, pero también puede ser una prueba de mecanizado o un ciclo en vacío. No debe contabilizarse como número de piezas conformes sin confirmarlo previamente.
- Al cambiar de programa, debe quedar clara la asignación de los registros. Hay que considerar la secuencia temporal del cambio de programa y de las variaciones del contador. Los registros cuya asignación no esté clara deben marcarse como pendientes de verificación; no basta con asignarles el nombre del último programa.
- Hay que gestionar los reinicios de los contadores y las lagunas de captura. La puesta a cero por el operario, el reinicio del equipo o una interrupción de la comunicación pueden afectar a los registros. Las variaciones de un valor acumulado no deben interpretarse sin comprobación como producción adicional.
- Los límites del día y del turno deben ser coherentes. Producción y procesos deben acordar primero cómo asignar los turnos que cruzan la medianoche y si se incluyen las pruebas de mecanizado, y después incorporar esos criterios a las reglas de la aplicación.
Una vez confirmadas estas condiciones, la App local puede agrupar los registros por fecha, máquina o producto y mostrar paneles, informes y curvas de tendencia dentro de la interfaz web de administración del gateway. Lua se encarga del procesamiento del backend y de la lógica de negocio; JS/CSS/HTML se utilizan para las páginas del frontend. El gateway proporciona el framework, pero la aplicación concreta debe configurarse o desarrollarse y sus resultados de cálculo deben verificarse.
El OEE no se calcula solo con una señal de funcionamiento
Con los registros de producción disponibles, se puede plantear también el OEE, o eficiencia global de los equipos. Combina disponibilidad, rendimiento y calidad para ayudar al taller a observar el uso de sus máquinas desde distintas perspectivas.
OEE = Disponibilidad × Rendimiento × Calidad
| Indicador | Criterio de cálculo | Datos necesarios |
|---|---|---|
| Disponibilidad | Tiempo de funcionamiento ÷ tiempo de producción planificado | Estado de funcionamiento confirmado, registros de estado y tiempo de producción planificado |
| Rendimiento | Tiempo ideal de mecanizado por pieza × número total de piezas ÷ tiempo de funcionamiento | Tiempo ideal de mecanizado por pieza de cada producto, número total de piezas y tiempo de funcionamiento obtenidos según los criterios acordados |
| Calidad | Número de piezas conformes ÷ número total de piezas | Número de piezas conformes y número total de piezas correspondientes al mismo ámbito de cálculo |
El estado de la máquina puede servir de base para calcular el tiempo de funcionamiento, pero producción y procesos deben definir el tiempo de producción planificado, las categorías de parada y el tiempo ideal de mecanizado por pieza. En este escenario se recomienda mostrar el OEE por separado para cada producto y su periodo de análisis correspondiente. No se puede aplicar un único tiempo de mecanizado a todos los productos, ni sumar directamente sus valores de OEE o promediarlos de forma simple para obtener un resultado de todo el turno. Si el tiempo de producción planificado, el tiempo de funcionamiento o el total de piezas es cero, las proporciones correspondientes deben marcarse como no aplicables. Si los datos están incompletos, deben señalarse como pendientes de verificación, en lugar de presentar el resultado como un OEE válido.
Los datos de calidad también necesitan una fuente independiente. El recuento de mecanizado no demuestra que las piezas sean conformes. Estos datos pueden introducirse mediante formularios de la App local o recibirse de un sistema de inspección si las condiciones de las interfaces permiten la integración. Sin datos de calidad fiables, conviene mostrar primero el tiempo de funcionamiento y la producción. No se debe fijar la calidad en su valor máximo por defecto ni presentar una estimación como OEE medido.
Cuando los datos estén completos y los criterios sean claros, se puede desarrollar en la App local la lógica de cálculo y visualización del OEE. No se trata de un informe estándar generado automáticamente por el gateway. Tampoco se puede determinar la causa raíz de una parada a partir de una sola cifra de OEE: el análisis de causas requiere además información de planta, registros de alarmas o un proceso específico de introducción de motivos de parada.
En el cambio de turno, consultar primero los registros y después comprobar en planta
Una vez terminada la aplicación, el responsable puede consultar primero el estado actual, la información de los productos y los registros del turno en el panel integrado del gateway, y después acudir a planta para verificar las anomalías. El personal de procesos mantiene la correspondencia entre programas y productos, y el personal de producción consulta resúmenes elaborados con los mismos criterios, en lugar de trabajar cada uno con anotaciones tomadas en momentos distintos.
Las páginas deben mostrar la hora de la última actualización y distinguir entre interrupciones de comunicación, datos desactualizados y paradas reales. Estos avisos y las reglas de tratamiento de anomalías deben implementarse en la aplicación. Que una máquina aparezca parada no significa que el sistema ya sepa si falta material, se está cambiando una herramienta o existe una avería; sigue siendo necesaria la información correspondiente de planta.
El procesamiento, almacenamiento y visualización locales no necesitan depender de una plataforma en la nube ni de un servidor de aplicaciones adicional. Si más adelante se necesita una consulta centralizada entre talleres o fábricas, se puede configurar por separado la publicación de datos mediante MQTT, HTTP/HTTPS y la integración con la plataforma receptora. La recepción de datos, la autenticación, la correspondencia de campos y la interfaz de negocio deben resolverse de forma independiente; no son funciones que aparezcan automáticamente al disponer de conectividad.
Qué confirmar antes de la conexión
- Comprobar el modelo concreto del CNC, la compatibilidad del controlador de comunicación, las interfaces, los permisos de acceso y las variables disponibles, y contrastar cada variable con las indicaciones de planta.
- Definir la correspondencia entre programas y productos, el significado de los contadores o señales de finalización, la asignación al cambiar de producto y el tratamiento de los registros tras reinicios de contadores e interrupciones de comunicación.
- Acordar los turnos, el tiempo de producción planificado, la definición de los estados de funcionamiento y el tiempo ideal de mecanizado por pieza de cada producto, y preparar una fuente independiente de datos de calidad.
- Planificar los formularios, la lógica de cálculo, las páginas y los avisos de anomalías de la App, y definir las responsabilidades de desarrollo y mantenimiento. La capacidad del framework no debe confundirse con una aplicación de negocio preinstalada.
- Planificar el periodo de conservación del histórico, las copias de seguridad y los permisos de acceso según los recursos de almacenamiento y la frecuencia de registro. No se garantiza almacenamiento ilimitado ni registros sin lagunas.
Los talleres de mecanizado que quieran empezar por comprender mejor su producción pueden comenzar con los registros de estado y producción de una sola máquina. Tras confirmar la captura y los criterios de recuento, pueden ampliar la solución con la asociación de productos, los resúmenes por turno y el OEE. El gateway permite aprovechar los datos de los equipos; la App local los organiza según las reglas del taller, y el personal de producción y procesos se encarga de explicar qué representan realmente esas cifras.