Cómo solucionar una condición de carrera de doble OTE en lógica de escalera

Una condición de carrera de doble OTE ocurre cuando un programa de PLC escribe en la misma bobina de salida más de una vez en un solo escaneo. Debido a que la lógica de escalera se ejecuta de forma secuencial, el último peldaño sobrescribe los comandos anteriores. La solución es arquitectónica: consolidar el control de salida, validar el comportamiento del escaneo y verificar el resultado frente a la respuesta simulada del equipo.

Una cinta transportadora no ignora un comando de parada porque el PLC esté "confundido". Lo ignora porque el programa le indicó dos cosas diferentes en un solo escaneo, y la última instrucción prevaleció.

En una revisión reciente de 500 envíos de principiantes basados en el escenario de cinta transportadora de OLLA Lab, el 68% introdujo una escritura duplicada en el mismo bit de ejecución del motor al añadir una parada secundaria o una condición permisiva [Metodología: n=500 envíos de resolución de problemas de cintas transportadoras, tarea definida como modificar una cinta transportadora de motor único base para añadir una ruta de parada por condición anormal, el comparador fue la solución de referencia original de OTE único, ventana de tiempo del 15 de enero al 15 de marzo de 2026]. Esta métrica interna de Ampergon Vallis respalda un punto limitado: la inspección visual por sí sola a menudo pasa por alto la duplicación destructiva de salidas en ediciones de escalera de novatos. No respalda ninguna afirmación más amplia sobre las tasas de defectos en la industria.

Aquí es exactamente donde un entorno de simulación se vuelve operativamente útil. El problema no es la sintaxis. El problema es la capacidad de despliegue bajo la realidad del ciclo de escaneo.

Un error de doble OTE ocurre cuando la misma dirección o etiqueta de salida es escrita por más de una instrucción de Salida Energizada (OTE) durante un solo escaneo del PLC.

En la lógica de escalera, el PLC normalmente ejecuta un ciclo repetitivo:

1. Leer entradas
2. Ejecutar lógica
3. Actualizar salidas
4. Realizar tareas de mantenimiento y comunicaciones

Esa secuencia es determinista. El procesador no "promedia" las instrucciones de salida conflictivas ni negocia entre ellas. Las ejecuta en orden.

Si `MTR_1_Run` se energiza en el peldaño 3 y luego se desenergiza o se reenergiza de forma diferente en el peldaño 15, el último peldaño define el estado final escrito en la imagen de salida. En equipos reales, esto puede significar que un motor siga funcionando después de una entrada de atasco, o que un contactor vibre bajo una lógica conflictiva.

La regla del "último peldaño gana"

La regla del "último peldaño gana" es la consecuencia práctica de la ejecución secuencial.

Un PLC normalmente no activa la tarjeta de salida física en el instante en que encuentra una instrucción OTE en el programa. Actualiza la imagen de salida interna a medida que se ejecuta la lógica, y luego escribe el estado resultante en las salidas físicas al final del escaneo. Si varios peldaños escriben en el mismo bit, la última escritura ejecutada es la que sobrevive.

Es por esto que las bobinas duplicadas no son simplemente un estilo desordenado. Son una ambigüedad destructiva codificada como comportamiento determinista.

Por qué esto importa físicamente, no solo lógicamente

Un fallo de doble OTE no es solo un defecto de software. Puede crear consecuencias mecánicas.

En cintas transportadoras y sistemas accionados por motor, los comandos de marcha/parada conflictivos pueden producir:

• condiciones de parada ignoradas,
• vibración intermitente del contactor,
• disparos molestos,
• desgaste prematuro en arrancadores y relés,
• colisiones de productos,
• pérdida de secuencia entre equipos aguas arriba y aguas abajo.

El código puede parecer legible y aun así estar mal en funcionamiento. La puesta en marcha tiene poca tolerancia para los errores elegantes.

La cinta transportadora falló porque la condición de parada fue sobrescrita más tarde en el escaneo por un segundo peldaño que comandaba la misma salida de ejecución del motor.

Aquí está la lógica del escenario en términos simples:

- El objetivo: Detener la cinta transportadora cuando la fotocélula `PE_1` detecta un atasco. - El comportamiento previsto: Un atasco debería eliminar el comando de ejecución a `MTR_1_Run`. - El error: Un peldaño anterior desactiva `MTR_1_Run` ante un atasco, pero un peldaño posterior vuelve a activar `MTR_1_Run` usando un permisivo de "aguas arriba despejado" y una condición de "sistema en marcha". - El resultado: La parada por atasco existe en el código pero no en el estado final de salida.

Ese es el tipo de paradoja que a los operadores no les gusta: el sensor funcionó, el peldaño parecía correcto y la cinta transportadora siguió llevando el producto hacia un bloqueo.

Ejemplo del patrón destructivo

Peldaño 3: `[NOT PE_1_Jam] ------------------------------- (OTE) [MTR_1_Run]`

Peldaño 15: `[Upstream_Clear] -- [System_Run] ------------- (OTE) [MTR_1_Run]`

Si `PE_1_Jam` se vuelve verdadero, el peldaño 3 desactiva el bit de ejecución del motor. Si el peldaño 15 permanece verdadero más adelante en el mismo escaneo, `MTR_1_Run` se establece de nuevo. La cinta transportadora funciona. El atasco permanece.

Cómo se ve el fallo en funcionamiento

En una línea de cinta transportadora simulada, los síntomas visibles suelen incluir:

• el producto continúa hacia una zona ocupada,
• no hay respuesta efectiva a la fotocélula de atasco,
• el estado del comando del motor parece inconsistente con la lógica de parada prevista,
• confusión intermitente del operador porque la HMI o la vista lógica pueden mostrar una condición mientras el estado final de salida refleja otra.

Es por esto que la resolución de problemas mediante una captura de pantalla estática es una evidencia débil. Necesita visibilidad del estado a través del escaneo y del modelo de la máquina.

Las condiciones de carrera del PLC en la lógica de escalera generalmente no son "condiciones de carrera" en el sentido de subprocesos de software. Son conflictos de estado deterministas creados por el orden de escaneo, escrituras duplicadas, cambios de entrada asincrónicos entre escaneos o lógica de secuenciación mal particionada.

En este artículo, la condición de carrera es específicamente una sobrescritura por orden de escaneo.

El mecanismo es sencillo:

• el PLC lee la imagen de entrada actual,
• la lógica del peldaño se ejecuta en secuencia,
• múltiples instrucciones apuntan al mismo bit de salida,
• la última escritura define la imagen de salida final,
• la máquina reacciona a ese estado final, no a la intención del programador.

Esto importa porque muchos programadores nuevos asumen que cada peldaño actúa de forma independiente sobre la máquina real. No es así. El escaneo es una pasada de ejecución, y la máquina solo ve el estado de la imagen resultante. La lógica de escalera es indulgente con la sintaxis e implacable con la arquitectura.

Causas comunes de fallos de escritura duplicada

Las causas de ingeniería más comunes son:

• añadir una segunda ruta de parada sin consolidar la lógica de ejecución original,
• mezclar permisivos y comandos en peldaños separados que apuntan a la misma salida física,
• parchear fallos durante la depuración en lugar de rediseñar la estructura de salida,
• usar etiquetas de salida física directamente dentro de múltiples secciones de secuencia,
• no separar la lógica de estado interno del mapeo de salida final.

Un contraste útil es este: generación de borrador frente a veto determinista. El PLC ejecutará alegremente ambos peldaños. No le advertirá que uno invalidó silenciosamente al otro.

Usted detecta una condición de carrera de doble OTE observando el estado de la etiqueta de salida, las condiciones de disparo y la respuesta simulada del equipo en conjunto, en lugar de inspeccionar la sintaxis de la escalera de forma aislada.

Aquí es donde OLLA Lab es creíblemente útil como entorno de validación y ensayo. No reemplaza la puesta en marcha en campo, y no confiere competencia en el sitio por asociación. Lo que sí proporciona es un lugar seguro para observar la causa y el efecto que sería costoso, rápido o inseguro de estudiar en equipos reales.

Use el Panel de Variables como instrumento de diagnóstico

El Panel de Variables es útil porque expone los cambios de estado a nivel de etiqueta que la revisión estática de la escalera puede ocultar.

Para este fallo, observe al menos estas etiquetas:

• `PE_1_Jam`
• `Upstream_Clear`
• `System_Run`
• `MTR_1_Run`

El patrón de diagnóstico es:

• `PE_1_Jam` cambia a verdadero,
• el peldaño anterior elimina lógicamente la condición de ejecución,
• un peldaño posterior sigue evaluándose como verdadero,
• `MTR_1_Run` vuelve a ser verdadero al final del escaneo,
• el gemelo digital de la cinta transportadora continúa moviéndose a pesar de la condición de atasco.

Esa es una prueba diagnóstica de comportamiento de sobrescritura, no solo una sospecha.

Ralentice la ejecución para inspeccionar la causa y el efecto

El control del tiempo de escaneo es útil porque facilita la inspección de transiciones de estado rápidas.

Cuando esté disponible en el flujo de trabajo del escenario, ralentice la ejecución lo suficiente para observar:

1. la transición de entrada,
2. la respuesta del peldaño anterior,
3. la sobrescritura del peldaño posterior,
4. el estado final de salida,
5. la respuesta del equipo en el modelo de la cinta transportadora.

En un sistema real, estas transiciones suelen ser demasiado rápidas para observarlas limpiamente sin herramientas de tendencia, lo que obliga a realizar referencias cruzadas de lógica y requiere un día tranquilo que la planta no programó para usted.

Compare el estado de la escalera frente al estado del equipo

El valor real de la simulación no es que pueda ver un peldaño ponerse verde. Es que puede comparar el estado lógico frente al comportamiento de la máquina.

Para este caso de cinta transportadora, verifique si:

• la escalera indica una condición de atasco,
• el bit de ejecución del motor permanece activado al finalizar el escaneo,
• la cinta transportadora simulada sigue haciendo avanzar el producto,
• la consecuencia de colisión o atasco aparece en el modelo del equipo.

Esa comparación es lo que hace que el entorno esté listo para la simulación en un sentido operativo: el ingeniero puede observar, diagnosticar y endurecer la lógica de control contra el comportamiento real del proceso antes de que llegue a un proceso real.

La arquitectura correcta es permitir que un peldaño, una rutina o una capa de mapeo claramente delimitada sea propietaria del comando de salida física final.

La regla es simple: una salida física, un escritor final. Todo lo demás debería alimentar esa decisión, no competir con ella.

### Método 1: Ramificación paralela para lógica OR consolidada

La ramificación paralela es una solución limpia cuando múltiples permisivos o rutas de comando deben dirigir una decisión de salida.

En lugar de escribir `MTR_1_Run` en múltiples peldaños, combine la lógica en un solo peldaño con ramas explícitas y condiciones de parada.

Estructura de ejemplo:

`[System_Run] -- [Upstream_Clear] -- [NOT PE_1_Jam] -- [NOT EStop_Active] -- (OTE) [MTR_1_Run]`

O, donde existan múltiples solicitudes de ejecución válidas, use lógica de ramificación aguas arriba de una sola OTE final.

Este enfoque suele ser el más legible para el control de motores sencillo.

### Método 2: Enclavamiento/Desenclavamiento (OTL/OTU) con precaución

Las instrucciones de enclavamiento (latch) y desenclavamiento (unlatch) pueden ser apropiadas para estados de comando retenidos, pasos de secuencia o solicitudes del operador, pero requieren disciplina.

Úselas con cuidado porque:

• los estados retenidos pueden sobrevivir a condiciones que el programador olvidó borrar,
• el comportamiento de reinicio después de una pérdida de energía o transiciones de modo debe considerarse explícitamente,
• el comportamiento relacionado con la seguridad nunca debe depender de una lógica de enclavamiento casual.

Para las funciones de seguridad, la base de diseño rectora debe provenir de la arquitectura y las normas de seguridad aplicables, no de la conveniencia en la redacción de la escalera.

### Método 3: Etiquetado intermedio con mapeo de salida final

Las etiquetas intermedias suelen ser la solución más escalable en máquinas más grandes o patines de proceso.

El patrón es:

• calcular condiciones internas usando bits de memoria,
• separar permisivos, disparos, solicitudes y estados de secuencia,
• mapear esos estados internos a una salida física final en una rutina de salida dedicada.

Ejemplo:

`Rung 5: [System_Run] -- [Upstream_Clear] -------------------- (OTE) [Run_Request]` `Rung 6: [PE_1_Jam] ------------------------------------------ (OTE) [Jam_Trip]` `Rung 20: [Run_Request] -- [NOT Jam_Trip] -- [NOT EStop_Active] ---- (OTE) [MTR_1_Run]`

Esta arquitectura mejora la trazabilidad porque la decisión de salida final es explícita.

Debe documentar evidencia de ingeniería, no una galería de capturas de pantalla.

Si desea demostrar una habilidad real de resolución de problemas, use esta estructura compacta:

Establezca criterios de aceptación observables, tales como: "Si `PE_1_Jam = TRUE`, entonces `MTR_1_Run = FALSE` al finalizar el escaneo, y el movimiento de la cinta transportadora se detiene en el gemelo digital".

Documente la corrección arquitectónica: peldaño consolidado, diseño de etiqueta intermedia o propiedad de secuencia revisada.

Capture el principio de ingeniería, tal como: "Las salidas físicas requieren un único escritor final", o "la lógica de condiciones anormales debe validarse contra el estado final del escaneo, no solo contra la intención local del peldaño".

1. Descripción del sistema Defina la sección de la cinta transportadora, el comando del motor, el sensor de atasco, el permisivo de aguas arriba y la secuencia esperada.
2. Definición operativa del comportamiento correcto
3. Lógica de escalera y estado del equipo simulado Incluya el conjunto de peldaños relevante y el estado del equipo correspondiente antes de la corrección.
4. El caso de fallo inyectado Muestre la OTE duplicada o la ruta de escritura competitiva y la condición exacta bajo la cual sobrescribe la lógica de parada.
5. La revisión realizada
6. Lecciones aprendidas

Ese tipo de evidencia es útil en la formación, la revisión por pares y el ensayo de puesta en marcha porque muestra razonamiento, no solo posesión de software.

El modelo de ejecución central proviene de la práctica de la norma IEC 61131-3: los programas de PLC se ejecutan de forma determinista de acuerdo con el lenguaje y el modelo de tiempo de ejecución implementado por la plataforma del controlador.

El argumento de riesgo también está bien fundamentado. La literatura sobre seguridad funcional distingue constantemente entre el comportamiento de control previsto y el comportamiento verificado bajo condiciones fallidas o anormales. Esa distinción importa aquí porque las escrituras duplicadas pueden invalidar la lógica protectora prevista sin producir un error de sintaxis.

El argumento de la simulación también debe mantenerse acotado. Un gemelo digital o un modelo de máquina simulada no certifica la preparación para el campo por sí solo. Lo que sí respalda, cuando se utiliza correctamente, es un descubrimiento de fallos más temprano, un ensayo más seguro de condiciones anormales y una validación más observable del comportamiento de la secuencia antes de la puesta en marcha.

OLLA Lab encaja como un entorno de validación y ensayo basado en la web para lógica de escalera, comportamiento de E/S simulado y resolución de problemas alineada con gemelos digitales.

En este caso de uso específico, es útil para:

• construir y editar lógica de escalera en el navegador,
• ejecutar el escenario de cinta transportadora sin hardware físico,
• monitorear etiquetas en el Panel de Variables,
• comparar el estado de la escalera con el comportamiento de la máquina simulada,
• ensayar condiciones anormales como atascos, pérdida de permisivos y revisiones de rutas de parada,
• documentar la solución como un paquete de evidencia de ingeniería.

Ese es un alcance creíble.

- Leer: Entendiendo los ciclos de escaneo: Cómo OLLA Lab imita el hardware real. - Leer: Seal-In vs. Latch: Por qué los ingenieros profesionales eligen con cuidado. - Pruebe el fallo de forma segura en la práctica: Abra el Conveyor Crash Preset en OLLA Lab.

• Para un desglose completo de la estructura de programación IEC 61131-3 y los fundamentos de la escalera, visite el Ladder Logic Mastery Hub.

- IEC 61131-3: Controladores programables — Parte 3: Lenguajes de programación - Fundamentos del ciclo de escaneo del PLC (AutomationDirect) - Descripción general de la seguridad funcional IEC 61508 - Conceptos de condiciones de carrera y sincronización (Glosario NIST) - Validación de gemelos digitales para lógica de control (IFAC-PapersOnLine)