Solución de problemas de alta utilización de CPU en PdlRT y apertura lenta de faceplates en SIMATIC IPC647D

En estaciones de trabajo Cliente OS de SIMATIC PCS 7 que se ejecutan en hardware IPC647D, el alto consumo de CPU por parte de Picture Runtime (PdlRT.exe) y la demora en la apertura de faceplates son causados por colas de scripts cíclicos no compilados, fugas de identificadores de la interfaz de dispositivos gráficos (GDI) o cachés de imágenes gráficas sin búfer. El diagnóstico de la causa raíz requiere analizar la ejecución activa de scripts con la utilidad de diagnóstico de WinCC apdiag.exe, reemplazar los activadores de pantalla cíclicos rápidos por eventos de cambio de tag, verificar los umbrales de objetos GDI y optimizar el almacenamiento en caché de imágenes de APL.

Índice de contenidos

Papel de PdlRT.exe en SIMATIC PCS 7 WinCC Runtime

En las estaciones de operador de SIMATIC PCS 7 (Clientes OS y estaciones monopuesto), PdlRT.exe (Picture Runtime) es el motor de renderizado gráfico principal de WinCC:
* Decodifica y renderiza pantallas de lenguaje de descripción de procesos (.pdl), ejecuta C-scripts y VBScripts locales incrustados en objetos gráficos, actualiza propiedades dinámicas (colores, gráficos de barras, niveles) e instancia faceplates de APL.
* En una instalación equilibrada, PdlRT.exe mantiene un consumo de CPU moderado (< 15% en procesadores IPC647D multinúcleo) con tiempos de respuesta de apertura de faceplates inferiores a 1 segundo.
* Cuando PdlRT.exe monopoliza los núcleos de CPU (con picos del 50% o 100% de un hilo asignado), los comandos del operador se congelan, las visualizaciones de tendencias se retrasan y los faceplates tardan entre 5 y 10 segundos en abrirse.

Procedimientos de diagnóstico utilizando apdiag.exe y Process Explorer

Para determinar qué está estancando a PdlRT.exe, utilice la utilidad de diagnóstico nativa de Siemens:
1. Abra el cuadro de diálogo Ejecutar de Windows (Win + R), escriba:
C:/Program Files (x86)/Siemens/WinCC/bin/apdiag.exe y presione Intro.
2. En la consola de APDIAG:
* Seleccione Diagnostics -> Script Queue: inspeccione la profundidad de la cola activa de acciones C y VBS. En un sistema saludable, el recuento de la cola debe fluctuar cerca de 0. Si las colas superan las 50 acciones, las ejecuciones de scripts se están acumulando.
* Seleccione Diagnostics -> First Action: muestra el script específico que actualmente está bloqueando el hilo de ejecución del runtime.
* Seleccione Output Window: habilita el registro en tiempo real de errores de compilación de scripts, fallos de división por cero y llamadas a tags indefinidas.
3. Abra el Administrador de tareas de Windows -> Detalles:
* Agregue la columna Objetos GDI (GDI Objects).
* Monitoree PdlRT.exe. Si los objetos GDI aumentan continuamente hacia el límite del montón de escritorio de Windows (10,000 identificadores), hay una fuga de memoria gráfica activa.

Saturación de la cola de scripts: Acciones cíclicas frente a activadores por cambio de tag

El defecto de ingeniería más frecuente que causa la saturación de PdlRT.exe son los activadores de scripts no optimizados:
* La trampa del activador cíclico: Colocar un VBScript o una acción C en la propiedad de un objeto (por ejemplo, cambio de color o visibilidad) con un activador cíclico rápido (por ejemplo, 250 ms o 500 ms) obliga al motor a recalcular el script continuamente incluso cuando el valor de proceso subyacente no ha cambiado.
* Cuando una pantalla gráfica contiene decenas de scripts cíclicos, la cola de ejecución se satura, retrasando todas las acciones de usuario interactivas (como la apertura de faceplates).
* Remediación: Reemplace todos los activadores de scripts cíclicos por activadores A cambio (Upon Change) vinculados al tag de proceso específico que los impulsa, o reemplace los scripts personalizados por Diálogos dinámicos (Dynamic Dialogs) nativos de WinCC que se evalúan directamente en código C++ compilado sin la sobrecarga del motor de scripts.

Agotamiento de identificadores GDI y aceleración por hardware gráfico

En estaciones de trabajo IPC647D multipantalla con adaptadores gráficos de múltiples pantallas:
* Controles ActiveX / .NET personalizados: Los controles de terceros mal programados o los elementos OCX personalizados frecuentemente asignan identificadores GDI de Windows al abrir una imagen sin liberarlos al cerrarla.
* Una vez que los identificadores GDI superan los 8,000–9,000, el renderizado gráfico de Windows se degrada gravemente antes de bloquear PdlRT.exe.
* Aceleración por hardware: Asegúrese de que el controlador gráfico instalado coincida con el paquete de hardware IPC certificado de Siemens; desactive los efectos de escritorio de software innecesarios en Propiedades del sistema de Windows -> Configuración de rendimiento.

Optimización del almacenamiento en caché de faceplates APL en estaciones Cliente OS

Para acelerar las velocidades de apertura de faceplates en plantas de proceso con APL:
1. En el Explorador de WinCC en el servidor/cliente OS, abra el Editor de proyectos OS (OS Project Editor).
2. Seleccione la pestaña Datos básicos (Basic Data).
3. Verifique que la configuración de Caché de imágenes (Picture Cache) esté habilitada. El almacenamiento en caché precarga las imágenes de plantilla estándar de APL (@pg_*.pdl) en la memoria RAM local, eliminando la latencia de lectura del disco durante los eventos de clic en tiempo de ejecución.
4. Verifique que la estación cliente cuente con una unidad SSD local rápida y que la asignación del archivo de paginación de Windows esté configurada con un tamaño administrado por el sistema.

Verificación

Inicie la ventana de salida de APDIAG (Output Window) y active la apertura de un faceplate complejo de motor o válvula.
Confirme que el faceplate se renderice en menos de 1.0 segundo sin acumulación en la cola de scripts.
En el Administrador de tareas, monitoree el uso de CPU de PdlRT.exe: confirme que el uso de CPU vuelve a la línea base (< 10%) inmediatamente después de que se abre el faceplate.
Navegue por 20 pantallas de proceso secuencialmente: verifique que los objetos GDI permanezcan estables por debajo de 2,000 identificadores sin crecimiento incremental.

Limitaciones y precauciones operativas

Modificar los activadores de scripts en Graphics Designer requiere guardar el archivo PDL y descargar los cambios a los clientes OS.
Nunca cierre PdlRT.exe a la fuerza a través del Administrador de tareas en una estación de producción activa sin una secuencia limpia de reset_wincc.vbs, ya que esto puede corromper los archivos de caché del runtime del cliente local.
No deshabilite las actualizaciones de seguridad de Windows en los sistemas IPC647D; verifique la compatibilidad utilizando la lista de Siemens security_patches_iec.xls antes de la implementación.

Preguntas frecuentes del ingeniero

¿Qué utilidad diagnostica los cuellos de botella en la ejecución de C-Scripts y VBScripts de WinCC?
La utilidad de diagnóstico apdiag.exe ubicada en C:/Program Files (x86)/Siemens/WinCC/bin/.
¿Cuál es el límite arquitectónico de Windows para los identificadores GDI por proceso?
De forma predeterminada, Windows limita un solo proceso a 10,000 identificadores GDI; acercarse a este límite causa un retraso gráfico severo o bloqueos.
¿Por qué se prefieren los diálogos dinámicos sobre los C-scripts o VBScripts en Graphics Designer?
Los diálogos dinámicos se compilan directamente en código C++ nativo, ejecutándose significativamente más rápido y sin ocupar espacios en la cola de scripts.
¿Qué causa que los faceplates se abran lentamente en un cliente OS mientras se abren rápido en el servidor OS?
Latencia de red, cachés de imágenes sin búfer en el cliente o retrasos en la carga de paquetes del servidor a través del bus de terminales.
¿Cómo habilito el almacenamiento en caché de imágenes de faceplates en PCS 7 OS?
Configure los parámetros de caché de imágenes en el Editor de proyectos OS de WinCC bajo las propiedades de Datos básicos / Runtime.
¿Qué columna del Administrador de tareas indica fugas de memoria de objetos gráficos?
La columna Objetos GDI en la vista de Detalles del Administrador de tareas rastrea la asignación de recursos gráficos.
¿Se puede resolver la alta utilización de CPU en la CPU 5 o en un solo núcleo mediante la programación del procesador?
Configurar la programación del procesador para Servicios en segundo plano ayuda a los servidores OS, mientras que los clientes OS se benefician de la optimización para Programas.
¿La instalación de parches de Windows no aprobados afecta el rendimiento de PdlRT?
Sí, los parches acumulativos no probados pueden interrumpir DCOM, el renderizado GDI o los subsistemas .NET; consulte siempre security_patches_iec.xls.
¿Cómo muestra apdiag.exe qué script se está ejecutando actualmente?
Seleccionar Diagnostics -> First Action en APDIAG muestra el nombre y el número de línea del script de bloqueo activo.
¿Cuál es la profundidad normal de la cola de scripts en un cliente WinCC saludable?
En un sistema saludable, la cola de scripts activos debe fluctuar entre 0 y 5 acciones.

Referencias técnicas

Manual del sistema de información SIMATIC HMI WinCC V7.4 / V7.5
Manual de operación del sistema de control de procesos SIMATIC PCS 7 OS
Entrada de Siemens Industry Online Support: Diagnóstico del rendimiento de WinCC Runtime (Entrada ID 299025)
Instrucciones de funcionamiento de SIMATIC IPC647D y Guía de configuración de hardware

Etiquetas relacionadas

PCS 7, WinCC, PdlRT, IPC647D, Optimización de rendimiento, Faceplates, apdiag, Identificadores GDI, Scripts, Diagnóstico