Definición controlada de alarmas y códigos de evento en equipos de impresión 3D

Introducción: una misma alarma, tres respuestas según el turno

Una máquina de fusión de lecho de polvo metálico muestra repetidamente durante el turno nocturno el aviso «oxígeno elevado»: el equipo A continúa imprimiendo por experiencia, el equipo B detiene la máquina y vuelve a purgar el gas, y el equipo C simplemente la restablece. Los tres registros describen el mismo fenómeno, pero ninguno responde a «qué código de evento corresponde a este aviso, cuál es el umbral de activación, si se permite continuar la impresión o si debe realizarse una nueva verificación tras el restablecimiento». Al asumir proyectos de ciclo de vida completo, desde los planos de diseño hasta la entrega física, lantu3D ha observado que los talleres generalmente no carecen de sensores ni de listas de inspección; les falta una tabla de códigos controlada que traduzca los eventos brutos generados por el controlador de la máquina en acciones determinables. Este artículo no trata sobre «cómo reparar el equipo», sino sobre una capa más upstream: cómo numerar, clasificar y vincular a acciones de enclavamiento las alarmas y los códigos de evento, cómo controlar su supresión y restablecimiento, y cómo congelarlos con las versiones de firmware, para que un mismo evento reciba el mismo tratamiento en cualquier turno.

I. Delimitar primero el alcance: los códigos de alarma, los síntomas de fallo y los eventos de calidad no son una misma tabla

Primero deben separarse tres conceptos que se confunden con facilidad. Un código de alarma es un identificador estructurado emitido por bits o palabras por el sistema de control del equipo; su semántica la define la tabla de códigos y debe ser única, estable y legible por máquina. Un síntoma de fallo es la descripción observada por el operador, como «hay bandas en la extensión de polvo»; pertenece al lenguaje natural y varios síntomas pueden apuntar al mismo código. Un evento de calidad es una determinación posterior sobre el impacto en la pieza, como «este build queda aislado pendiente de inspección»; pertenece al nivel de liberación. Los puntos de medición en tres niveles y el registro de formas de onda para calidad de energía, el mapeo entre modos de fallo, indicadores de monitorización y umbrales para mantenimiento predictivo, y los tres estados normal/anormal/requiere reverificación en las inspecciones de equipo, abordados en publicaciones especializadas, son todos casos de consumir cierto tipo de evento para tomar otra decisión; no definen «de dónde procede el código, cómo se divide el dominio de códigos o qué hacer con los registros antiguos cuando cambia un código». La pregunta para delimitar esta capa es: ¿el documento explica cómo calcular una conclusión tras recibir una señal, o cómo se llama esa señal en su origen, a qué nivel pertenece y qué acciones puede activar? Solo aquello que se concreta en «un código, una tabla de clasificación, una regla de enclavamiento y un registro de congelación de versión» pertenece a la capa de ingeniería de tablas de códigos.

II. División del dominio de códigos: asignar a cada evento una identidad que nunca se reutilice

Se recomienda una codificación de longitud fija en cinco segmentos: E-<familia de equipo 2 dígitos>-<subsistema 2 dígitos>-<número secuencial 3 dígitos>-<nivel 1 dígito>; por ejemplo, LP-GS-0217-3 indica el evento número 217 del subsistema de extensión de polvo/gas, con gravedad de nivel 3. Las familias de equipo se dividen por plataforma de proceso (LP: lecho de polvo láser; BJ: inyección de aglutinante; PJ: fotopolimerización; DE: deposición de energía dirigida), y los subsistemas por dominio funcional (GS: circuito de gas y contenido de oxígeno; RC: extensión de polvo y rasqueta; LS: láser y trayectoria óptica; TH: precalentamiento de la placa base; MT: movimiento y servos; PW: alimentación eléctrica y servicios auxiliares; CT: control y comunicaciones). Para cada código, la tabla debe fijar al menos ocho campos: código único, descripción estándar en chino e inglés, expresión de condición de activación, nivel predeterminado, acción de enclavamiento predeterminada, condiciones operativas en las que puede aparecer, primera versión de firmware en la que entra en vigor y puesto responsable de la respuesta. Una vez asignado, un número secuencial nunca debe reutilizarse; un evento retirado solo se marca como deprecated y conserva su mapeo histórico. Está prohibido asignar un número antiguo a un nuevo significado, pues un registro de calidad de hace tres años podría interpretarse posteriormente como un evento completamente distinto.

III. Clasificación y enclavamiento: matriz de acciones de cuatro estados, desde «aviso» hasta «parada de seguridad»

Se recomiendan cuatro niveles de gravedad, vinculando cada nivel a una única acción predeterminada para evitar la discrecionalidad en planta: S1, aviso (solo se registra en el log de eventos, sin interrumpir la fabricación; por ejemplo, recordatorio de sustitución por presión diferencial del filtro cercana al límite); S2, advertencia (se mantiene la fabricación, pero se reduce la velocidad o se marca el proceso; por ejemplo, cuando el oxígeno en cámara alcanza 800-1000 ppm, se prolonga automáticamente la purga entre capas y se marca esa capa); S3, retención del proceso (se pausa la extensión de polvo y se mantienen el número de capa actual y la atmósfera inerte; por ejemplo, oxígeno >1000 ppm durante ≥2 s, o desviación de la potencia láser medida respecto a la consigna de ±8% durante más de 3 capas); antes de reanudar, debe verificarse el estado de fusión de las 3 capas anteriores y las 3 posteriores al número de capa afectado; S4, parada de seguridad (se corta la salida láser, se mantiene la circulación de gas y el build queda directamente aislado; por ejemplo, interrupción del gas protector, activación del enclavamiento de puerta o actuación del circuito de parada de emergencia). Para S4 se prohíben siempre el restablecimiento automático y la supresión. La matriz de acciones debe redactarse en seis columnas: «nivel → interrupción sí/no → conservación de atmósfera sí/no → aislamiento del build sí/no → reverificación de primera pieza requerida sí/no → puesto a notificar», y publicarse tras la aprobación conjunta de proceso, equipos y calidad.

IV. Antirrebote, condiciones de activación e instantáneas de evidencia: hacer reproducible cada evento

La condición de activación no puede limitarse a «oxígeno alto»; debe expresarse de manera reproducible como: magnitud comparada / operador de comparación / umbral / duración / banda de histéresis / condición de habilitación. Por ejemplo, para el contenido de oxígeno se aplica un umbral de 1000 ppm, duración de 2 s y banda de histéresis del 5% (solo se despeja al caer por debajo de 950 ppm), habilitado únicamente durante fabricación y precalentamiento, sin evaluación en espera ni mantenimiento. Para la desviación de potencia láser se aplica ±8%, durante 3 capas consecutivas, con antirrebote a un periodo de muestreo de 100 ms: se confirma tras cumplirse en 3 ciclos consecutivos, mientras que picos instantáneos de <50 ms se registran como transitorios sin escalar el nivel. Cada evento confirmado genera una instantánea de evidencia con diez campos fijos recomendados: código de evento, marca de tiempo (sincronizada con el reloj del equipo, deriva ≤1 s), número de capa actual, potencia láser real, posición del eje de extensión de polvo, contenido de oxígeno y punto de rocío, hash del paquete de parámetros, versión de tabla de códigos, versión de firmware e identificador del operador. También deben conservarse las formas de onda de las variables clave de los 200 ms previos y 1 s posterior al evento. Sin esta instantánea, no puede determinarse posteriormente el límite de impacto del evento, y las conclusiones de liberación para S3/S4 carecen de fundamento.

V. Supresión, restablecimiento y bypass temporal: encerrar las excepciones en una jaula de autorizaciones

En planta existen necesidades legítimas de supresión, como durante la calibración de un analizador de oxígeno, pero deben restringirse mediante controles de ingeniería: la supresión solo se permite para S1-S3 y queda permanentemente prohibida para S4; la solicitud debe indicar el código, el motivo, las medidas alternativas de supervisión y su periodo de vigencia; se recomienda una vigencia ≤8 horas o ≤1 build, lo que ocurra primero, con vencimiento automático; la ejecución requiere autorización dual de equipos y calidad. Durante la supresión, todos los eventos deben seguir registrándose; únicamente se añaden suppressed=true y el número de autorización, sin descartar nunca los eventos de forma silenciosa. El restablecimiento tampoco consiste simplemente en pulsar un botón: antes de restablecer un S3/S4, deben registrarse el código de causa raíz, correspondiente a una entrada del diccionario de fallos, y el responsable de la acción. Tras el restablecimiento se realiza una validación con una muestra estándar de primera pieza, y se revisan falta de fusión y porosidad en las 3 capas anteriores y posteriores a la capa del evento; el aislamiento del build solo puede levantarse cuando existan los cuatro registros completos. Se recomienda incluir en el tablero mensual «tasa de supresión ≤1% de builds», «proporción de eventos no clasificados ≤2%», «más de 5 repeticiones de la misma causa raíz en 1 hora genera automáticamente una orden de causa raíz» e «integridad evento-instantánea ≥99%».

VI. Congelación de versiones y cambios: a dónde van los códigos antiguos tras actualizar el firmware

La tabla de códigos es un documento controlado, no una hoja de cálculo que se modifica libremente. Cada publicación debe generar un número de versión, hash SHA-256, fecha de entrada en vigor, lista de números de serie de equipos aplicables y versión mínima de firmware; además, debe vincularse mediante una clave triple con la versión del paquete de parámetros y el número de build, e incorporarse a la cadena de evidencias de entrega. La adición o revisión de un código debe seguir una solicitud de cambio: análisis de impacto (qué registros históricos, tarjetas de trabajo y lógicas de enclavamiento resultan afectados) → revisión tripartita → mapeo entre códigos nuevos y antiguos → transición en la fecha de entrada en vigor → retirada de las tarjetas de trabajo antiguas. Antes y después de actualizar el firmware debe realizarse una comparación de consistencia de la tabla de códigos: verificar elemento por elemento que el número, nivel y descripción realmente emitidos por el controlador coinciden con la versión controlada vigente; si no coinciden, debe bloquearse la liberación del equipo para producción. Se recomienda conservar las tablas de códigos históricas y los registros de eventos durante al menos la vida útil del producto más 3 años, archivados en modo de solo lectura.

VII. Lista de verificación de implantación y errores comunes

La implantación puede avanzarse en 30 días: semana 1, exportar la lista completa de eventos del controlador, recodificarla según el formato de cinco segmentos y crear el registro maestro del dominio de códigos; semana 2, completar la matriz de acciones de cuatro niveles y las expresiones de condiciones de activación, añadiendo antirrebote y bandas de histéresis; semana 3, conectar automáticamente los diez campos de la instantánea de evento con el hash del paquete de parámetros y el número de capa; semana 4, realizar un ejercicio de trazabilidad inversa de 30 minutos: seleccionar al azar un evento S3 de hace tres meses y exigir la reconstrucción de la versión de tabla de códigos, condición de activación, instantánea y conclusión de liberación vigentes entonces; el objetivo de éxito es ≥95%. Existen cuatro errores frecuentes: redactar códigos de alarma como descripciones en lenguaje natural, imposibilitando su lectura automática; definir solo umbrales, sin duración ni condiciones de habilitación, generando una avalancha de falsas alarmas en mantenimiento; dejar de registrar directamente los eventos durante una supresión, rompiendo posteriormente la cadena de evidencias; y continuar usando la tabla antigua tras actualizar el firmware, mezclando significados nuevos y antiguos.

Conclusión

La definición controlada de alarmas y códigos de evento de los equipos es la ingeniería fundamental que traduce «lo que dice la máquina» en «lo que debe hacer el taller». No sustituye el cálculo energético, la gestión de calidad de energía, el mantenimiento predictivo ni la gestión de lotes de inspección, sino que proporciona a estos métodos un diccionario de entrada estable, reproducible y trazable. Para una plataforma que cubre toda la cadena desde el diseño y el proceso hasta la fabricación y la entrega física, solo asegurando que cada código sea único, cada nivel tenga una acción única, cada excepción deje rastro y cada versión pueda congelarse, un aviso del turno nocturno podrá convertirse en un hecho de ingeniería que produzca la misma conclusión en cualquier turno.