Cómo funciona el ciclo de escaneo de un PLC: Simulación de ejecución determinista en OLLA Lab

El ciclo de escaneo de un PLC es un bucle determinista en el que el controlador lee las entradas, ejecuta la lógica de forma secuencial, escribe las salidas y realiza tareas del sistema. OLLA Lab imita este comportamiento en un entorno de simulación basado en navegador para que los ingenieros puedan observar fallos dependientes del escaneo, probar revisiones de lógica y validar la relación causa-efecto antes de la puesta en marcha real.

Un error común es pensar que la lógica de escalera (ladder) se comporta como el software convencional que reacciona instantáneamente a los eventos. No es así. Un PLC generalmente sondea la realidad en un escaneo repetitivo, evalúa la lógica en un orden definido y actualiza las salidas una vez completada dicha evaluación. Esa distinción es la diferencia entre un código que parece correcto y un código que funciona en una máquina real.

Durante una evaluación interna reciente del escenario de clasificación de alta velocidad de OLLA Lab, el 68% de los usuarios junior no lograron capturar un pulso de sensor óptico de 10 ms cuando el tiempo de escaneo simulado se configuró en 20 ms [Metodología: n=41 usuarios; tarea = detectar y enclavar un pulso transitorio de fotocélula en un escenario de rechazo de transportador; comparador de referencia = captura exitosa de pulso a 5 ms de escaneo simulado; ventana de tiempo = 15 de enero – 10 de marzo de 2026]. Este es un punto de referencia interno de Ampergon Vallis, no una afirmación de prevalencia en la industria. Respalda un punto concreto: la temporización del escaneo a menudo se comprende mal, incluso cuando la lógica de los peldaños parece sintácticamente correcta.

Ahí es exactamente donde OLLA Lab resulta útil. Proporciona un entorno de software-in-the-loop acotado para observar la ejecución determinista, la visibilidad de E/S y los modos de fallo dependientes del escaneo antes de que alguien aprenda la lección en una máquina real, donde el coste del error es mucho mayor.

Un ciclo de escaneo estándar de un PLC es una secuencia repetitiva y determinista con cuatro fases funcionales. La implementación exacta varía según el fabricante y el modelo de tarea, pero el patrón central es estable en la ejecución cíclica convencional.

El punto clave de ingeniería es sencillo: el programa generalmente no lee una entrada física nueva en cada instrucción. Trabaja a partir de una imagen de memoria durante la ejecución y luego actualiza las salidas posteriormente.

1. Escaneo de entradas (Lectura) El controlador lee el estado actual de las entradas físicas y copia esos estados en la memoria, a menudo llamada tabla de imagen de entradas o imagen de proceso.
2. Ejecución del programa (Lógica) El controlador ejecuta el programa del usuario utilizando los estados de entrada almacenados. En la lógica de escalera, esto se evalúa normalmente de arriba a abajo y de izquierda a derecha dentro de la estructura de tarea o rutina activa.
3. Escaneo de salidas (Escritura) El controlador escribe los estados finales de salida calculados desde la memoria a los terminales de salida físicos.
4. Tareas de mantenimiento (Comunicaciones/Diagnóstico) El controlador realiza diagnósticos internos, comunicaciones, actualizaciones de temporizadores, mensajería y otras tareas del sistema.

Por qué esto es importante en la práctica

La ejecución basada en escaneo crea comportamientos predecibles pero no evidentes:

• Un pulso corto puede perderse si ocurre entre escaneos.
• Una bobina escrita dos veces en un mismo escaneo puede ser sobrescrita silenciosamente.
• Una salida que parece verdadera en un peldaño puede no energizarse físicamente nunca si un peldaño posterior la reinicia antes de la fase de actualización de salidas.
• Las suposiciones de temporización que parecen inofensivas en pantalla pueden fallar frente a la dinámica real del proceso.

Es por esto que conocer la sintaxis de escalera no es lo mismo que estar listo para la simulación. Operativamente, un ingeniero preparado para la simulación puede probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento real del proceso antes de que este llegue a un proceso en vivo.

Los lenguajes de TI de propósito general no son intrínsecamente incorrectos para el software. Son incorrectos para explicar la ejecución de un PLC si se ignora el modelo de control. El problema no es el prestigio del lenguaje; es la semántica de ejecución.

Ejecución de TI frente a ejecución de OT

| Característica | Lenguajes de TI (Python/JavaScript, en general) | Ejecución de OT / PLC (contexto IEC 61131-3) | |---|---|---| | Modelo de disparo principal | Basado en eventos, callbacks o planificadores | Sondeo cíclico y ejecución de tareas deterministas | | Relación con la memoria | La asignación dinámica es común | Etiquetas predefinidas, memoria estructurada, mapeo directo de procesos | | Interacción con hardware | Generalmente abstraída mediante controladores/API | Relación directa con imágenes de E/S, estados de campo y temporización de escaneo | | Temporización de ejecución | A menudo no determinista a nivel de aplicación | Diseñada para una ejecución de control repetible y acotada | | Modo de fallo | Latencia, condiciones de carrera, problemas de orden de callbacks | Pulsos perdidos, lógica de sobrescritura, suposiciones de imagen obsoleta | | Prioridad de ingeniería | Rendimiento, flexibilidad, interacción del usuario | Determinismo, repetibilidad, comportamiento seguro de la máquina |

La norma IEC 61131-3 define los lenguajes de programación y los conceptos de ejecución utilizados en el control industrial, incluyendo Diagrama de Escalera, Diagrama de Bloques de Funciones, Texto Estructurado y Diagrama de Funciones Secuenciales (IEC, 2013). En la práctica, el control por PLC depende del comportamiento determinista de las tareas, el manejo explícito de estados y un orden de escaneo predecible. El software web a menudo asume que el mundo puede esperar al siguiente evento. Las bombas, cilindros y transportadores generalmente no pueden.

El contraste importante

El contraste claro es este: respuesta a eventos frente a control cíclico.

Esa diferencia importa porque la automatización física no trata solo de calcular un resultado. Trata de calcular el resultado en el momento adecuado, en el orden correcto y frente a condiciones de planta cambiantes.

La ejecución secuencial de escalera significa que el controlador evalúa la lógica en un orden definido, no todo a la vez. En un escaneo convencional, el programa se resuelve peldaño a peldaño, desde la parte superior de la rutina hacia abajo, y dentro de cada peldaño de izquierda a derecha según las reglas de ejecución de la plataforma.

Consecuencias observables de la ejecución secuencial

- La resolución de problemas debe distinguir entre:

• La lógica anterior puede establecer un bit interno que la lógica posterior utiliza inmediatamente.
• La lógica posterior puede sobrescribir un resultado establecido anteriormente en el mismo escaneo.
• Pueden existir estados intermedios en la memoria durante la ejecución, aunque la salida física aún no haya cambiado.
• estado de la etiqueta en la memoria
• estado de la salida física en el terminal

Esa distinción es fácil de pasar por alto en un aula y difícil de ignorar durante la puesta en marcha.

Fundamentos IEC

La norma IEC 61131-3 proporciona el marco del lenguaje, pero la documentación del fabricante y la arquitectura del tiempo de ejecución determinan los detalles exactos de la programación de tareas y la actualización. La afirmación segura es esta: la evaluación secuencial y la ejecución cíclica son comportamientos fundamentales en los sistemas de control PLC convencionales, aunque los detalles de implementación difieran según la familia de controladores.

El síndrome de la doble bobina ocurre cuando la misma salida o bobina de memoria se escribe en más de un lugar, permitiendo que una instrucción posterior sobrescriba una anterior durante el mismo escaneo. El estado final escrito en la ejecución de la lógica es el que sobrevive hasta la etapa de actualización de salidas.

Aquí está el patrón clásico:

[Idioma: Diagrama de Escalera]

PELDAÑO 1: El comando de inicio establece Motor_Run como verdadero en la memoria. |---[ Start_PB ]-------------------------------------( Motor_Run )---|

PELDAÑO 2: Una condición posterior escribe en la misma bobina. Si este peldaño se evalúa como falso de una manera que desenergiza el mismo objetivo, el estado anterior se sobrescribe efectivamente antes de que se escriban las salidas. |---[ Some_Other_Condition ]-------------------------( Motor_Run )---|

Qué sucede realmente

- Resultado: el motor puede no energizarse nunca, aunque un peldaño anterior pareciera correcto.

• El primer peldaño escribe `Motor_Run = TRUE` en la memoria.
• Un peldaño posterior escribe en el mismo objetivo.
• La última escritura determina el estado final de la memoria al final de la ejecución.
• La actualización de la salida física ocurre después.

Esta es la ejecución determinista haciendo exactamente lo que especifica la lógica, independientemente de la intención.

Por qué este fallo es útil para la formación

Los fallos de doble bobina exponen tres ideas centrales rápidamente:

• el orden importa
• el estado de la memoria no es lo mismo que el estado del terminal
• la corrección visual del peldaño no es suficiente

En OLLA Lab, esto se vuelve observable en lugar de teórico porque los usuarios pueden ejecutar la lógica, inspeccionar variables y comparar el estado de la escalera con el comportamiento del equipo simulado.

Un pulso corto puede perderse cuando su duración es menor que la oportunidad efectiva del controlador para muestrearlo. Si una entrada se enciende y apaga entre escaneos de entrada, es posible que la CPU nunca registre el evento en la imagen de entrada.

### Ejemplo: ancho de pulso frente a tiempo de escaneo

Si:

• un pulso de fotocélula dura 10 ms, y
• el controlador muestrea las entradas cada 20 ms,

entonces el pulso puede ocurrir completamente entre escaneos y desaparecer desde la perspectiva del programa.

Este es un problema de muestreo. En el trabajo de control, a menudo aparece como "el sensor definitivamente se activó, pero el PLC nunca lo vio". Ambas afirmaciones pueden ser ciertas.

Por qué los ingenieros deberían preocuparse

Los pulsos perdidos afectan a:

• clasificación de alta velocidad
• lógica adyacente a encoders
• confirmación de rechazo
• conteo de botellas o cajas
• señales de prueba intermitentes
• alarmas activadas por flanco

La solución puede implicar tareas más rápidas, enclavamiento por hardware, estiramiento de pulsos, monoestables, contadores de alta velocidad o un diseño de secuencia revisado. La respuesta correcta depende del proceso y de la arquitectura del controlador.

OLLA Lab imita el escaneo de la CPU física proporcionando un entorno de simulación estructurado en el que la lógica de escalera se ejecuta como un bucle determinista en lugar de como reacciones sueltas a eventos del navegador. Más simplemente, está diseñado para permitir a los usuarios observar el comportamiento de control dependiente del escaneo, no simplemente dibujar peldaños.

Lo que hace OLLA Lab en términos acotados

Dentro de la plataforma, los usuarios pueden:

• construir lógica de escalera en un editor basado en web
• ejecutar lógica en modo de simulación
• alternar e inspeccionar entradas, salidas y variables
• trabajar a través de escenarios industriales realistas
• comparar el comportamiento de la escalera con vistas de equipos en 3D/WebXR/VR donde estén disponibles
• usar GeniAI, el guía de laboratorio de IA, para soporte guiado

Para el alcance de este artículo, el hecho importante del producto es más estrecho: OLLA Lab proporciona un entorno basado en software para ensayar la ejecución de lógica determinista y observar cómo la temporización del escaneo afecta el comportamiento de la máquina.

Comportamientos observables que la plataforma es adecuada para demostrar

• Comportamiento de sobrescritura de doble bobina
• Pulsos transitorios perdidos
• Seguimiento de causa-efecto a través de E/S
• Fallos de secuencia causados por suposiciones obsoletas sobre el estado
• Diferencias entre el estado de la escalera y el estado del equipo simulado

Eso lo hace útil como un entorno de ensayo de software-in-the-loop para tareas de puesta en marcha de alto riesgo. No reemplaza las pruebas de aceptación de hardware, la validación de seguridad o la puesta en marcha específica del sitio. Esas siguen perteneciendo al sistema real, con el controlador real, bajo las restricciones reales.

Por qué importa la entrega a través del navegador

Un entorno basado en navegador reduce la fricción de configuración para el aprendizaje y la revisión. Más importante aún, permite la inyección repetida de fallos de bajo riesgo sin ocupar un entrenador físico o hardware adyacente a la producción.

En este contexto, la validación de gemelo digital significa probar la lógica de escalera contra una máquina o modelo de proceso simulado y verificar si el comportamiento esperado del equipo coincide con la filosofía de control bajo condiciones normales y anormales.

Esa definición debe mantenerse fundamentada. No significa que la simulación sea un sustituto legalmente suficiente para la aceptación del sitio, la verificación SIL o la puesta en marcha de la planta.

### Operativamente, la validación de gemelo digital incluye:

• comparar estados de comando con la respuesta del equipo simulado
• verificar el orden de la secuencia y los permisivos
• comprobar el comportamiento de alarmas y disparos
• observar cambios de estado analógicos o impulsados por PID donde estén modelados
• inyectar fallos y confirmar la respuesta lógica
• revisar el programa y volver a probar

Aquí es donde OLLA Lab se vuelve operativamente útil. Permite a los ingenieros probar si una secuencia funciona en un modelo realista antes de probarla en equipos que pueden atascarse, inundarse, sobrepasar su recorrido o fallar de formas costosas.

Los ingenieros deben practicar el manejo de fallos dependientes del escaneo construyendo escenarios donde la lógica se vea forzada a fallar por razones de temporización, y luego revisando el diseño hasta que el modo de fallo sea controlado y explicable.

### Un ejercicio práctico: captura de pulsos en un escenario de transportador

Utilice un escenario de tipo transportador o clasificación y defina un evento de sensor transitorio que sea más corto que el intervalo de escaneo simulado.

#### Paso 1: Construir la lógica inicial

Cree una lógica que dependa directamente de un pulso de fotocélula para activar una acción como rechazar, contar o desviar.

#### Paso 2: Establecer las condiciones simuladas

Utilice un intervalo de escaneo que sea más largo que la duración del pulso. Luego ejecute el escenario y observe si el evento se captura de manera fiable.

#### Paso 3: Inspeccionar variables y estado del equipo

Utilice el panel de variables para comparar:

• estado de entrada
• bits de memoria interna
• comandos de salida
• respuesta del equipo simulado

#### Paso 4: Inyectar el caso de fallo

Fuerce un pulso que ocurra demasiado rápido para las suposiciones de escaneo actuales. Confirme que la lógica lo pierde.

#### Paso 5: Revisar la lógica

Las posibles revisiones incluyen:

• añadir una ruta de enclavamiento o sellado
• usar detección de flancos donde sea apropiado
• estirar el pulso en la lógica
• rediseñar la secuencia para evitar la dependencia de un transitorio estrecho
• documentar cuándo se requerirían características de hardware en un controlador real

#### Paso 6: Volver a ejecutar y verificar

Valide que la lógica revisada captura el evento bajo las condiciones definidas y no crea falsos positivos o persistencia insegura.

Una galería de capturas de pantalla demuestra que se abrió el software. No demuestra criterio de ingeniería. Si un alumno quiere demostrar una comprensión real del control, el artefacto debe mostrar razonamiento, manejo de fallos y disciplina de revisión.

Utilice esta estructura:

Establezca exactamente qué significa el comportamiento correcto. Ejemplo: "Un pulso de detección de producto de 10 ms debe ser capturado y enclavado para que la secuencia de rechazo se ejecute una vez y solo una vez".

Documente el fallo dependiente del escaneo. Ejemplo: "El pulso se perdió cuando el tiempo de escaneo excedió el ancho del pulso".

1. Descripción del sistema Defina la máquina o segmento de proceso, el objetivo de control y las E/S relevantes.
2. Definición operativa del comportamiento correcto
3. Lógica de escalera y estado del equipo simulado Muestre los peldaños, etiquetas y el comportamiento de la máquina simulada correspondiente.
4. El caso de fallo inyectado
5. La revisión realizada Explique qué cambió en la lógica y por qué.
6. Lecciones aprendidas Resuma el principio de control, como la temporización de la tabla de imagen, el comportamiento de sobrescritura o por qué la captura de pulsos requiere un diseño explícito.

Ese es el tipo de evidencia que un revisor puede interrogar. También es el tipo que tiende a sostenerse mejor en una revisión técnica que una captura de pantalla por sí sola.

La simulación del ciclo de escaneo es valiosa porque hace observable el comportamiento invisible del controlador. Sus límites importan tanto como sus capacidades.

Una declaración acotada de lo que la simulación puede y no puede hacer

La simulación puede ayudar a los ingenieros a:

• comprender la ejecución determinista
• probar la lógica de secuencia
• observar fallos relacionados con la temporización
• ensayar la resolución de problemas
• comparar el comportamiento esperado y el simulado del equipo

La simulación no puede por sí sola:

• certificar la competencia en el sitio
• reemplazar la validación específica del hardware
• establecer el cumplimiento de la seguridad funcional
• probar el comportamiento final de la temporización del bus de campo
• sustituir las FAT, SAT, pruebas de lazo o la puesta en marcha en vivo

Este límite no es una debilidad. Es parte de lo que mantiene la credibilidad de la herramienta.

La formación basada en simulación y los modelos digitales están bien establecidos en la ingeniería industrial, especialmente donde la experimentación directa en activos reales es costosa o insegura. La literatura generalmente apoya la simulación como una forma de mejorar la comprensión del comportamiento dinámico, la respuesta a fallos y la preparación de operadores o ingenieros, al tiempo que enfatiza que la fidelidad del modelo y el diseño de la tarea determinan la utilidad.

Normas relevantes y fundamentos técnicos

• IEC 61131-3 define los marcos de lenguaje de programación de PLC y los conceptos de ejecución relevantes para el comportamiento de la lógica de escalera (IEC, 2013).
• IEC 61508 establece el marco más amplio de seguridad funcional y refuerza que las declaraciones de seguridad requieren evidencia de ciclo de vida disciplinada, no solo confianza informal en la simulación (IEC, 2010).
• exida y la guía de seguridad funcional relacionada enfatizan la verificación, validación y rigor del ciclo de vida en el trabajo de automatización relacionado con la seguridad.
• La investigación en simulación industrial, gemelos digitales y entornos de formación ha demostrado valor en el ensayo de fallos, la preparación para la puesta en marcha y la comprensión humana de los sistemas dinámicos, particularmente cuando la simulación está vinculada al comportamiento observable del proceso en lugar de a la instrucción abstracta sola.

La conclusión cuidadosa es esta: la simulación es más fuerte cuando se utiliza para exponer comportamientos, probar suposiciones y mejorar el juicio previo al despliegue. Es más débil cuando se trata como un atajo para evitar la evidencia de ingeniería.

La alfabetización en ciclos de escaneo importa porque el control determinista no es intuitivo para las personas formadas en software basado en eventos o ejemplos de escalera estáticos. Un PLC no nota todo en el momento en que sucede. Muestrea, resuelve, escribe y repite.

Es por eso que OLLA Lab tiene un lugar legítimo en el flujo de trabajo. Ofrece a los ingenieros un entorno acotado para observar el orden de escaneo, inspeccionar el estado de las E/S, inyectar fallos y revisar la lógica antes de que esos mismos errores lleguen a un proceso real. No se trata de hacer que la simulación parezca impresionante. Se trata de hacer visible el fallo mientras el coste de equivocarse sigue siendo tolerable.

En términos prácticos, ese es el paso de la sintaxis a la capacidad de despliegue.

Este artículo fue preparado por el equipo de ingeniería de Ampergon Vallis Lab para apoyar la formación técnica en sistemas de control industrial.

El contenido técnico sobre el ciclo de escaneo de los PLC y la norma IEC 61131-3 ha sido verificado contra las especificaciones estándar de la industria y las metodologías de simulación de OLLA Lab.

- IEC 61131-3: Controladores programables — Parte 3 - Descripción general de la norma de seguridad funcional IEC 61508 - Perfil de Fabricación Inteligente del NIST - IEEE Access: Tecnologías habilitadoras de gemelos digitales (DOI)