Lógica de PLC de alarma de primera falla: reto de experto

¿Qué falla ocurrió primero de verdad? Qué debe hacer tu código

Hay tres defectos escondidos en un borrador que compila. Los operadores ven un código de falla distinto después de reconocer, y los movimientos cortos de la válvula a veces disparan la alarma. Varias causas pueden llegar en un mismo escaneo. Repara juntos la temporización, la captura de la causa y el reconocimiento.

Arranque y caudal

Un flanco nuevo de Start enclava ValveCmd con Permit, sin Stop y sin Alarm. PumpOn es TRUE solo con ValveCmd AND ValveOpen. Stop o la pérdida de Permit quitan las dos órdenes al instante; para volver hace falta una nueva pulsación de Start.

Tres causas

TripCode 0 = sin falla; 1 = Fault; 2 = Level >= 95%; 3 = ValveCmd sin ValveOpen de forma continua durante 500 ms. Llama a Delay en cada escaneo; su primera llamada verdadera empieza en cero. La siguiente llamada a los 500 ms dispara. Se acepta un escaneo antes o después, porque el sitio de la llamada a Delay la mueve un escaneo. Un recorrido interrumpido reinicia el retardo.

Primera causa y prioridad

Si aparece más de una causa en el mismo escaneo, gana Fault, luego el Level alto y luego el tiempo agotado de la válvula. Después de capturarla, conserva TripCode aunque aparezca otra causa. Alarm = TripCode <> 0. Las dos órdenes de proceso deben estar en OFF en el escaneo del disparo.

Horn y Ack

Una captura nueva hace sonar Horn. Un flanco ascendente de Ack silencia solo Horn. Mantener Ack pulsado durante un rearme válido no puede silenciar la siguiente falla nueva. Suéltalo y vuelve a pulsarlo.

Reset

Reset borra TripCode, Alarm y Horn solo con Start soltado, Fault en FALSE, Level < 95% y ValveStuck en FALSE. La válvula sigue cerrada y hace falta un Start nuevo. Reset con una causa activa no puede borrarla.

Reinicia la simulación y selecciona ValveStuck antes de pulsar Ejecutar y Start. Mira cómo ValveCmd y ValveOpen discrepan mientras la válvula sigue cerrada. Prueba y repite el límite exacto del tiempo agotado. Usa Entradas para mantener Ack pulsado mientras borras y vuelves a provocar una falla; un evento nuevo debe seguir haciendo sonar Horn.

¿Qué falla ocurrió primero de verdad? Entradas y salidas

Tu programa lee 9 entradas y escribe 5 salidas. Los nombres son los mismos en el editor de cada fabricante.

En SCL de Siemens, escribe las variables propias de un bloque con # delante, como hace TIA Portal: #Start. Rockwell y TwinCAT usa el nombre solo: Start.

Qué prueban las comprobaciones

1. T1TripCode captura la primera causa y no cambia antes de un Reset válido.
2. T2La realimentación de apertura tiene 500 ms; una orden interrumpida empieza una espera nueva.
3. T3Un Ack mantenido no puede silenciar un evento posterior. Alarm, Horn, PumpOn y ValveCmd se comprueban en cada escaneo.

Las comprobaciones ejecutan 7 pruebas en la máquina, escaneo a escaneo: Una planta sana no puede rearmarse mientras Start sigue pulsado; La primera causa sobrevive a fallas posteriores; prioridad definida si coinciden; El límite de nivel alto y un Ack mantenido no pueden silenciar el siguiente evento; La realimentación justo antes del límite evita que se agote el tiempo; Un tiempo de espera de 500 ms dispara, se enclava y rechaza un reinicio inseguro; Un recorrido interrumpido empieza un tiempo límite nuevo; Devolver el permiso nunca rearranca un Start mantenido.

Dónde encontrarías esto

El tanque de una cervecería deja de llenarse después de una alarma. El ingeniero necesita saber qué falla llegó primero, antes de que las fallas posteriores la entierren.

Si las fallas posteriores sobrescriben el código de la primera falla, el ingeniero va al equipo equivocado. Usar Ack para borrar la alarma podría rearrancar un equipo que sigue averiado.

¿Lo resolviste o te atascaste? Coméntalo en el Vestuario.