¿Por qué falla el botón de bloqueo/desbloqueo de alarmas mostrando una "X" en bloques personalizados de PCS 7?

Para solucionar un botón de bloqueo/desbloqueo de alarmas que no funciona y muestra un estado "X" en los bloques personalizados de PCS 7, verifique la configuración del bloque ALARM_8P en el editor SCL y asegúrese de que los valores asociados (valores de acompañamiento) no utilicen variables temporales.

¿Por qué falla el botón de bloqueo/desbloqueo de alarmas mostrando una "X" en bloques personalizados de PCS 7?

Categoría: PCS 7 / Migración | Tecnología: Siemens PCS 7, WinCC Runtime, Editor SCL, ALARM_8P, EventState | Tipo de Artículo: Guía de Solución de Problemas | Código: C135

También útil: PCS 7 Faceplates | WinCC Alarm Logging | SCL Block Compilation | EventState Variable Mapping

¿Cómo reparar el icono de alarma que muestra una "X" y un botón de desbloqueo que se vuelve a bloquear automáticamente en bloques personalizados de PCS 7 durante una migración?
Para solucionar un botón de bloqueo/desbloqueo de alarmas que no funciona y muestra un estado "X" en los bloques personalizados de PCS 7, verifique la configuración del bloque ALARM_8P en el editor SCL y asegúrese de que los valores asociados (valores de acompañamiento) no utilicen variables temporales.

Tabla de Contenidos

Primeras comprobaciones antes de modificar el código SCL

Confirmar el comportamiento por tipo de bloque: Verifique si el problema está estrictamente aislado en el bloque de medición personalizado (Meas_Mon) o si afecta también a los bloques nativos de Siemens (como Dig_Mon). Si los bloques estándar funcionan bien, el sistema operativo de WinCC y Simatic Shell están saludables.
Revisar el archivo de registro de compilación de mapas de bits (OS Compile): Compruebe si el proceso de compilación del OS transfirió correctamente la estructura jerárquica de alarmas desde el CFC hacia la base de datos de WinCC.
Crear un respaldo de la librería del proyecto: Genere una copia de seguridad de la librería maestra y del código fuente SCL antes de realizar cualquier cambio o recompilación en las estructuras internas del bloque.

Cuándo se presenta este problema en el Faceplate

Este problema se manifiesta de forma crítica durante las fases intermedias de una actualización de versión de sistema (por ejemplo, al migrar un proyecto heredado desde versiones antiguas hacia PCS 7 V7.1 SP3 como paso previo para alcanzar PCS 7 V9.1).

En el entorno de ejecución (Runtime), el operador nota que el icono de alarma en el faceplate del bloque personalizado muestra una "X" blanca fija en lugar de los símbolos operativos estándar (A para Alarma, W para Advertencia, etc.). El mismo símbolo de "X" se propaga hacia el botón de área en la barra de navegación superior y hacia el icono del bloque (block icon) en la pantalla de proceso .pdl. Al intentar pulsar el botón de "Desbloquear mensajes" en el faceplate, el botón se conmuta e inmediatamente regresa por sí solo al estado de bloqueado, impidiendo la activación de las alarmas.

Contexto técnico: La relación entre EventState, MSG_STAT y ALARM_8P

En la arquitectura de Siemens PCS 7, la visualización de los estados de alarma en los faceplates y la barra de áreas depende de una variable estructurada de 32 bits llamada EventState. El software WinCC Runtime lee este parámetro cíclicamente para determinar qué prioridad de alarma mostrar en los gráficos.

Cuando el sistema muestra una "X" blanca, no significa necesariamente que el botón de bloqueo esté dañado; WinCC está notificando que no está recibiendo información del estado de los mensajes. Esta desconexión ocurre habitualmente porque la rutina interna del bloque de función personalizado (desarrollado en SCL) invoca al bloque de sistema ALARM_8P de manera incorrecta.

Si los valores asociados (message-associated values o valores de acompañamiento como SD_1, SD_2) que se envían al servidor de alarmas apuntan a variables declaradas en la sección temporal (VAR_TEMP) del código SCL, los punteros de memoria se destruyen al finalizar el ciclo de ejecución del PLC. Al perderse la consistencia de los datos, la función ALARM_8P reporta una falla interna en su parámetro de estado MSG_STAT, provocando que el firmware del PLC deje de actualizar el EventState y forzando a WinCC a mostrar el estado indefinido ("X").

Ruta de diagnóstico y análisis del código fuente

Para identificar con precisión la causa raíz del fallo estructural en las alarmas, aplique los siguientes pasos de aislamiento:

Localizar el código fuente: Identifique el archivo de texto SCL correspondiente al bloque de medición personalizado dentro de la carpeta de fuentes (Sources) del proyecto en SIMATIC Manager.
Inspección de variables asignadas: Busque la llamada a la función del sistema SFB35 (ALARM_8P) dentro del código y verifique a qué variables están mapeados los parámetros SD_X.
Monitoreo de MSG_STAT online: Si el sistema lo permite, abra el plano CFC online y observe el valor de la salida de estado del bloque de alarmas. Un código de retorno diferente de 0 o 11 confirma un error de parametrización en el PLC.

Procedimiento de configuración: Corrección de variables en el bloque SCL

Nota de producción: Realice las modificaciones del código SCL y la posterior recompilación exclusivamente en la librería maestra del proyecto offline. Esta operación modificará la interfaz del bloque, por lo que requerirá una parada controlada de la CPU para cargar los bloques modificados y realizar un OS Compile completo antes de ir a Runtime.

Paso 1: Modificar la declaración de variables en el editor SCL

Abra el editor SCL haciendo doble clic en el archivo fuente del bloque de medición personalizado.
Busque la sección de asignación de variables temporales identificada bajo la etiqueta VAR_TEMP.
Si localiza las variables asignadas a los valores de acompañamiento del ALARM_8P (por ejemplo, variables utilizadas para transferir valores analógicos medidos o límites a las alarmas) en esta sección, selecciónelas y córtelas.
Desplácese hacia la sección de variables estáticas identificada bajo la etiqueta VAR. Pegue las variables ahí para asegurar que retengan su dirección física en el bloque de datos de instancia (DB) de forma permanente durante cada ciclo de scan.

Structured Text

// EJEMPLO DE CORRECCIÓN EN EL CÓDIGO FUENTE SCL
BLOCK FB300
TITLE = 'Customized Meas_Mon Block'
VERSION : '0.1'

VAR
    // Mover aquí los valores de acompañamiento para asegurar persistencia
    ExtVal_1 : REAL;
    ExtVal_2 : REAL;
    Alarm_Instance : ALARM_8P;
END_VAR

VAR_TEMP
    // No declarar variables de acompañamiento aquí
    Temp_Status : WORD;
END_VAR

BEGIN
    // Llamada corregida a ALARM_8P utilizando variables estáticas
    Alarm_Instance(EN_UO := TRUE,
                   SIG_1 := AuxBit_HighHigh,
                   SD_1  := ExtVal_1, // OK: Apunta a memoria estática del DB
                   STATUS => Temp_Status);
END_BLOCK;

Paso 2: Recompilar e incorporar los tipos de bloque actualizados

En el editor SCL, haga clic en el menú File -> Compile (o presione Ctrl + B) para generar el nuevo bloque compilado.
Cierre el editor y diríjase a su proyecto en SIMATIC Manager.
Vaya a la carpeta de planos del proyecto maestro y seleccione Options -> Charts -> Update Block Types para sincronizar todas las instancias existentes del bloque personalizado en los planos CFC con la nueva interfaz corregida.
Abra cualquier plano CFC y ejecute una compilación completa del programa seleccionando la opción Generate Module Driver.
Ejecute una compilación completa de la estación de operador (OS Compile) desde SIMATIC Manager para actualizar la base de datos de WinCC Alarm Logging con las firmas estructurales reparadas.
Inicie el Runtime del OS y verifique que el icono "X" haya desaparecido, mostrando ahora el estado dinámico correcto y permitiendo el uso normal del botón de desbloqueo.

Errores comunes en bloques personalizados de PCS 7

Uso de variables temporales para datos de acompañamiento: Mapear datos dinámicos como valores de proceso analógicos en los parámetros SD_1 a SD_10 de un bloque ALARM_8P utilizando la memoria temporal VAR_TEMP del SCL.
Omitir el OS Compile tras actualizar tipos de bloque: Modificar la estructura del bloque en el PLC pero no compilar la estación de operador (OS). Esto genera una desalineación de IDs de mensajes entre el PLC y WinCC, provocando el rechazo de los comandos de desbloqueo.
Límites de números de mensajes excedidos en la estructura del bloque: Configurar llamadas a bloques de alarma sin inicializar correctamente los bits de activación, dejando canales del ALARM_8P flotantes o indefinidos en el arranque de la CPU.

Lista de verificación de migración de alarmas

¿Están todas las variables conectadas a los parámetros SD_X de la función ALARM_8P definidas en la sección VAR estática del código SCL? ☐ Sí ☐ No ☐ Requiere revisión

¿Se ejecutó la herramienta "Update Block Types" en SIMATIC Manager para actualizar todas las instancias del bloque personalizado? ☐ Sí ☐ No ☐ Requiere revisión

¿Se realizó un OS Compile completo después de la compilación de los planos CFC con generación de drivers? ☐ Sí ☐ No ☐ Requiere revisión

¿El valor del parámetro MSG_STAT online se encuentra en estado saludable (0 o 11) durante el Runtime? ☐ Sí ☐ No ☐ Requiere revisión

FAQ

¿Por qué el botón de desbloqueo del faceplate funciona bien con el bloque Dig_Mon de Siemens pero falla con mi Meas_Mon personalizado? Los bloques nativos de Siemens (como Dig_Mon) están estrictamente diseñados bajo las pautas de desarrollo de la Advanced Process Library (APL), asegurando que todas las interacciones con ALARM_8P utilicen memoria estática persistente del DB de instancia. Su bloque Meas_Mon personalizado presenta la falla porque incluye un error de arquitectura en el código SCL que rompe el enlace de datos de los mensajes, un problema que los bloques estándar de la librería base no poseen.

¿Se puede solucionar el problema de la "X" en Runtime borrando los archivos de intercambio o reiniciando el servidor WinCC? No. La "X" blanca y el rechazo del comando de desbloqueo se deben a una inconsistencia de datos estructural real reportada por el firmware del PLC hacia la base de datos de WinCC Alarm Logging. Reiniciar el servidor o limpiar carpetas temporales de Runtime no modificará el comportamiento del código compilado en el PLC; la única solución definitiva es corregir las variables en el editor SCL y recompilar el proyecto como se detalla en el procedimiento.