¿Cómo responder a la pregunta de entrevista sobre TON vs. TOF en lógica de transportadores?

Un temporizador con retardo a la conexión (TON) se utiliza en la lógica de atascos de transportadores para confirmar que una condición de bloqueo permanece verdadera el tiempo suficiente para considerarse una falla, mientras que un temporizador con retardo a la desconexión (TOF) se utiliza en paradas en cascada para mantener el equipo aguas abajo funcionando brevemente después de que cae una señal aguas arriba. En los sistemas de transportadores, intercambiarlos crea un comportamiento incorrecto de la máquina.

Un error común en las entrevistas es explicar TON y TOF como definiciones abstractas de temporizadores sin conectarlas nunca con el comportamiento de la máquina. Esa respuesta es incompleta. En la lógica de transportadores, la verdadera distinción es física: TON verifica la persistencia antes de actuar; TOF preserva el movimiento después de que una señal desaparece.

En el conjunto de prácticas de transportadores de alta velocidad OLLA Lab de Ampergon Vallis, los usuarios junior que sustituyeron TOF por TON en una tarea de verificación de atascos basada en fotocélulas no lograron producir una alarma de atasco válida en 11 de 11 intentos de primer paso. Metodología: n=11 usuarios; tarea=construir detección de atascos para una fotocélula bloqueada en un preset de transportador; comparador de referencia=lógica de verificación correcta basada en TON; ventana de tiempo=observaciones internas de laboratorio recopiladas durante sesiones guiadas en el primer trimestre de 2026. Esta métrica respalda un punto limitado: el uso indebido de temporizadores en el primer intento es común en este escenario. No respalda ninguna afirmación más amplia sobre resultados de contratación, preparación de la fuerza laboral o tasas de error en toda la industria.

Aprobar esta pregunta de entrevista requiere más que recordar acrónimos. Requiere demostrar que puede traducir una caja en movimiento, una fotocélula parpadeante y un ciclo de escaneo de PLC en lógica determinista. La sintaxis es barata. La capacidad de despliegue no lo es.

La diferencia fundamental es el flanco y la transición de estado que cada temporizador retrasa.

Bajo la semántica de temporizadores IEC 61131-3, un TON retrasa que la salida se vuelva verdadera después de que la entrada se vuelve verdadera, mientras que un TOF retrasa que la salida se vuelva falsa después de que la entrada se vuelve falsa. Eso suena simple porque lo es. El problema comienza cuando las personas aplican la simplicidad incorrecta a una máquina en movimiento.

TON vs. TOF de un vistazo

| Instrucción | Transición de entrada de interés | Qué se retrasa | Uso típico en transportadores | |---|---|---|---| | TON | Falso a Verdadero | La salida se enciende / se vuelve verdadera | Verificación de atascos, rebote de sensor, comprobaciones de persistencia de falla | | TOF | Verdadero a Falso | La salida se apaga / se vuelve falsa | Temporización de funcionamiento (run-out), despeje en cascada, comportamiento de parada retardada |

Cómo se comporta el estado del temporizador

En implementaciones prácticas de PLC, los ingenieros suelen inspeccionar estos estados relacionados con el temporizador:

- EN (Enable): La instrucción está habilitada por las condiciones del peldaño. - TT (Timer Timing): El temporizador está acumulando activamente hacia su valor preestablecido. - DN (Done): El temporizador ha alcanzado su condición preestablecida.

Para un TON:

• Cuando el peldaño se vuelve verdadero, el temporizador comienza a acumular.
• Mientras está acumulando, TT suele ser verdadero.
• Cuando el tiempo acumulado alcanza el valor preestablecido, DN se vuelve verdadero.
• Si el peldaño se vuelve falso antes de alcanzar el valor preestablecido, el valor acumulado se reinicia en el comportamiento estándar no retentivo.

Para un TOF:

• Cuando el peldaño es verdadero, la condición de salida se establece inmediatamente.
• Cuando el peldaño se vuelve falso, el temporizador comienza su intervalo de retardo a la desconexión.
• Durante ese intervalo, la condición de salida se mantiene verdadera hasta que el valor preestablecido expira.

El contraste claro es este: TON pregunta: "¿Esta condición ha permanecido verdadera el tiempo suficiente para confiar en ella?". TOF pregunta: "¿Debería este estado verdadero persistir después de que desaparezca el comando?". Uno verifica la persistencia. El otro proporciona tiempo de funcionamiento.

Un circuito de detección de atascos en un transportador debe usar un TON cuando la condición de falla se define como un sensor que permanece bloqueado continuamente más allá de un tiempo de tránsito aceptable.

Esa es la razón de ingeniería fundamental. Una caja que pasa debe interrumpir el haz brevemente. Una caja atascada debe bloquearlo el tiempo suficiente para contar como una falla. El temporizador no está ahí para parecer sofisticado; está ahí para separar el tránsito normal de la persistencia anormal.

Definición operativa de "correcto" para la lógica de atascos

Una rutina de detección de atascos es correcta cuando hace todo lo siguiente:

• alarma solo después de que la fotocélula permanece bloqueada más tiempo que la ventana de tránsito permitida,
• ignora el paso normal del producto,
• se reinicia limpiamente cuando el bloqueo desaparece,
• expone el estado del temporizador con suficiente claridad para diagnosticar alarmas molestas,
• y no requiere el abuso del equipo físico para verificar la lógica.

Eso es parte de estar listo para la simulación (Simulation-Ready) en un sentido útil: un ingeniero puede probar, observar, diagnosticar y endurecer la lógica contra el comportamiento real del proceso antes de que llegue a un transportador en vivo.

Construcción paso a paso en lógica de escalera (Ladder)

#### 1. Mapear la entrada de la fotocélula a un contacto

Use la entrada discreta de la fotocélula de detección de atascos como un XIC si su convención de etiquetas hace que un haz bloqueado se evalúe como verdadero.

- Etiqueta de ejemplo: `PE_01_BLOCKED` - Contacto: `XIC(PE_01_BLOCKED)`

La polaridad exacta de la instrucción depende de cómo esté cableado el sensor y cómo se normalice la entrada en el software. Las entrevistas a menudo ocultan ese detalle a propósito.

#### 2. Enrutar el contacto hacia un TON

Accione un temporizador de retardo a la conexión no retentivo desde la condición de bloqueo.

- Ejemplo: `TON(Timer_Jam, PRE:=3000 ms)`

Esto significa que el haz debe permanecer bloqueado durante 3 segundos continuamente antes de que se alcance la condición de finalización del temporizador.

#### 3. Establecer el valor preestablecido según el comportamiento del proceso, no por suposición

El valor preestablecido debe ser ligeramente más largo que el tiempo de bloqueo normal aceptable más largo para esa zona del transportador.

Ese valor depende de:

• la velocidad de la banda,
• la longitud del producto,
• la ubicación del sensor,
• el comportamiento de acumulación,
• y la variación esperada del proceso.

Un valor preestablecido de temporizador sacado de la nada no es ingeniería. Es decoración con efectos secundarios.

#### 4. Usar el bit de finalización (Done) para activar la respuesta de falla

Use el estado de finalización del temporizador para establecer una alarma, detener una zona o iniciar una secuencia de falla controlada.

Ejemplo de lógica de escalera:

XIC(PE_01_BLOCKED) TON(Timer_Jam, 3000)

XIC(Timer_Jam.DN) OTL(Fault_Jam)

También puede usar el bit de finalización para desbloquear un comando de funcionamiento del motor, inhibir la liberación aguas arriba o activar un banner de falla en la HMI, dependiendo de la arquitectura del transportador.

Por qué el TON es correcto aquí

El TON es correcto porque un atasco se define por la duración continua del bloqueo, no por la desaparición de una señal.

Si la fotocélula parpadea debido a la geometría del cartón, la vibración o los efectos del borde del haz, un TON estándar se reinicia cuando la entrada cae. Ese comportamiento es útil. Actúa como un filtro de persistencia digital. Un TOF no resuelve ese problema; resuelve uno diferente.

Se debe usar un TOF para paradas en cascada de transportadores cuando el equipo aguas abajo debe continuar funcionando brevemente después de que cae un comando de funcionamiento aguas arriba, para que el producto pueda despejar la zona de transferencia.

Este es un problema clásico de tiempo de funcionamiento (run-out). Si el transportador aguas arriba se detiene y el transportador aguas abajo se detiene inmediatamente también, los cartones pueden hacer puente en el espacio entre zonas. Al reiniciar, ese puente se convierte en una colisión, una desviación o un derrame. Los transportadores son muy buenos convirtiendo errores de temporización en trabajo de mantenimiento.

El objetivo de control en una parada en cascada

El transportador aguas abajo debería:

• seguir funcionando durante un intervalo definido después de que la alimentación aguas arriba se detiene,
• despejar cualquier producto ya comprometido con la transferencia,
• luego detenerse solo después de que la zona esté lo suficientemente vacía para hacerlo de manera segura.

Eso es desenergización retardada. Es el hogar natural de un TOF.

Patrón típico de TOF

Si `Upstream_Run` cae a falso, el comando del motor aguas abajo permanece verdadero durante el valor preestablecido del TOF.

Ejemplo de concepto de escalera:

XIC(Upstream_Run) TOF(Downstream_Runout, 3000)

XIC(Downstream_Runout.DN) OTE(Conveyor_Downstream_Run)

Los detalles de implementación varían según la familia de PLC y el modelo de instrucción, pero la intención de control sigue siendo la misma: mantener el movimiento el tiempo suficiente para despejar el producto después de que desaparece el comando de inicio.

Por qué el TOF es incorrecto para la verificación de atascos

El TOF es incorrecto para la verificación de atascos porque extiende un estado verdadero después de que la entrada cae. La verificación de atascos necesita el comportamiento opuesto: debe confirmar que la condición bloqueada permaneció verdadera continuamente el tiempo suficiente para contar como anormal.

Una respuesta útil en una entrevista es este contraste:

- Detección de atascos: verificar la persistencia de una condición bloqueada con TON - Parada en cascada: preservar el movimiento aguas abajo después de la pérdida del comando con TOF

Esa distinción es memorable porque las consecuencias en la máquina son diferentes. Uno evita fallas molestas. El otro evita choques de productos.

Las señales de fotocélula con rebote hacen que el caso a favor del TON sea más fuerte en la detección de atascos, no más débil.

Una señal de fotocélula real no siempre es un flanco limpio de libro de texto. La geometría extraña del cartón, las solapas rotas, las superficies reflectantes, la vibración, la deriva de la alineación del sensor y la temporización del escaneo pueden crear transiciones intermitentes. Al PLC no le importan sus excusas mecánicas; solo ve bits cambiando.

Qué significa "rebote" en este contexto

En aplicaciones de transportadores, "rebote" o "parpadeo" puede significar:

• un haz que se rompe y se despeja repetidamente a medida que pasa un producto irregular,
• vibración en el borde de ataque o de salida de un cartón,
• detección inestable debido a la alineación o contaminación,
• o una interrupción corta que no debería tratarse como un atasco real.

Por qué el TON se comporta como un filtro práctico

Un TON estándar no retentivo solo llega a completarse (done) si la condición bloqueada permanece verdadera continuamente durante todo el valor preestablecido.

Si la señal cae:

• el tiempo acumulado se reinicia,
• el temporizador debe comenzar de nuevo,
• y el evento molesto no madura hasta convertirse en una falla.

Es por eso que los ingenieros usan TON para rebote y verificación de fallas. No es filtrado en el sentido de procesamiento de señales analógicas, pero funcionalmente rechaza perturbaciones de corta duración al requerir persistencia.

Por qué el TOF hace la promesa incorrecta

Un TOF no pregunta si la condición bloqueada fue continuamente verdadera el tiempo suficiente para contar como un atasco. Pregunta si un estado verdadero debe permanecer afirmado después de que desaparece la condición de habilitación.

Eso es útil para ventiladores, sopladores, ciclos de purga y tiempo de funcionamiento de transportadores. No es útil para decidir si un bloqueo de fotocélula fue real y sostenido. Acrónimos similares han engañado a personas más capaces.

OLLA Lab es útil aquí porque proporciona un entorno de validación de riesgo contenido donde el acumulador del temporizador, la lógica preestablecida y la respuesta de la máquina pueden observarse frente a E/S simuladas y el comportamiento del equipo.

Ese posicionamiento importa. OLLA Lab no es evidencia de competencia en el sitio, certificación, calificación SIL o preparación para poner en marcha una línea en vivo solo. Es un lugar para ensayar el razonamiento de alto riesgo que las plantas en vivo no pueden donar a bajo costo a los principiantes.

Qué puede observar en el laboratorio

En OLLA Lab, un estudiante puede:

• construir lógica de escalera en el editor basado en navegador,
• ejecutar y detener la simulación sin hardware físico,
• alternar y monitorear entradas y salidas discretas,
• inspeccionar variables relacionadas con el temporizador y estados de etiquetas,
• comparar el estado de la escalera con el comportamiento simulado del transportador,
• y revisar la lógica después de observar una falla.

Aquí es donde la plataforma se vuelve operativamente útil. Usted deja de discutir a partir de definiciones y comienza a discutir a partir del comportamiento.

Cómo ensayar el escenario de la entrevista

Use el preset de transportador o de clasificación para probar ambos casos:

• Cree una etiqueta de fotocélula bloqueada.
• Accione un TON desde ese estado bloqueado.
• Establezca un valor preestablecido más largo que el tránsito normal del producto.
• Use el bit de finalización para activar una falla o secuencia de parada.
• Observe si los bloqueos cortos reinician el temporizador como se espera.

#### Parada en cascada con TOF

• Cree un comando de funcionamiento aguas arriba.
• Use ese comando para accionar un TOF para el tiempo de funcionamiento aguas abajo.
• Vincule el comando del motor aguas abajo al estado retenido del temporizador.
• Observe si el producto despeja la zona de transferencia antes de que la banda se detenga.

Qué significa "validación de gemelo digital" aquí

En este artículo, validación de gemelo digital significa verificar que la lógica de escalera produzca el comportamiento del equipo previsto en un modelo de máquina simulado realista antes de la implementación.

Para este ejemplo de transportador, eso significa observar si:

• una fotocélula bloqueada produce una falla solo después de un bloqueo sostenido,
• un sensor parpadeante evita disparos molestos,
• y un transportador aguas abajo continúa el tiempo suficiente para despejar el producto durante una parada en cascada.

Esa definición es intencionalmente simple.

Usted simula una fotocélula con rebote inyectando deliberadamente un comportamiento de entrada discreta inestable y luego observando si la lógica de atasco sigue comportándose correctamente.

El punto no es hacer que la simulación se vea dramática. El punto es obligar al temporizador a probar su lógica bajo condiciones anormales pero plausibles.

Flujo de trabajo práctico en OLLA Lab

Use el Panel de Variables y los controles de simulación para crear cambios de entrada repetidos en la etiqueta de la fotocélula.

Una secuencia de prueba útil es:

• establecer la entrada de fotocélula bloqueada como verdadera,
• pulsarla a falso brevemente a intervalos irregulares,
• repetir esto durante un período más corto que el valor preestablecido de atasco,
• luego mantenerla verdadera continuamente más allá del valor preestablecido.

Qué debería ver con un diseño de TON correcto

Con un TON aplicado correctamente:

• el acumulador avanza mientras la entrada bloqueada permanece verdadera,
• las transiciones breves a falso reinician la acumulación,
• el bit de finalización permanece falso durante el parpadeo,
• y la falla solo aparece una vez que el bloqueo permanece continuo más allá del valor preestablecido.

Esa es la respuesta que quieren los entrevistadores, independientemente de si la expresan claramente o no.

Qué debería ver con un diseño de TOF incorrecto

Con un TOF sustituido en la misma ruta lógica:

• el comportamiento del temporizador ya no verifica el bloqueo sostenido,
• la semántica de salida refleja un apagado retardado en lugar de una confirmación de falla retardada,
• y el comportamiento de alarma resultante no coincide con la definición física de atasco.

En un transportador simulado, el error se vuelve visible rápidamente. En un transportador en vivo, se vuelve visible primero para las operaciones.

Debe explicar los campos del temporizador en términos de comportamiento observable de la máquina, no solo nombres de etiquetas.

Una respuesta compacta y sólida suena así:

- PRE (Preset): el umbral de tiempo requerido para una decisión. - ACC (Accumulator): el tiempo transcurrido contado actualmente hacia ese umbral. - EN (Enable): la instrucción del temporizador está siendo accionada por condiciones de peldaño verdaderas. - TT (Timer Timing): el temporizador está contando activamente y aún no ha completado. - DN (Done): el temporizador ha alcanzado su condición preestablecida.

Luego conecte esos campos con el transportador:

• En la detección de atascos, `ACC` aumenta mientras la fotocélula permanece bloqueada.
• Si el bloqueo se despeja demasiado pronto, `ACC` se reinicia en un TON estándar.
• Si `ACC` alcanza `PRE`, `DN` se vuelve verdadero y la alarma de atasco es válida.

Esa respuesta muestra pensamiento de ciclo de escaneo. También muestra que entiende por qué existe el temporizador.

El artefacto de portafolio más sólido es un paquete de decisiones de ingeniería compacto, no un montón de capturas de pantalla de lógica de escalera con flechas y optimismo.

Si desea demostrar habilidad de manera creíble, documente el ejercicio en esta estructura:

1) Descripción del sistema

Indique el contexto de la máquina claramente.

- Ejemplo: transferencia de transportador de dos zonas con una fotocélula para verificación de atascos y un requisito de tiempo de funcionamiento aguas abajo.

2) Definición operativa de "correcto"

Defina qué debe hacer la lógica exitosa.

• Alarma de atasco solo después de un bloqueo continuo superior a 3 segundos.
• Sin alarma durante el paso normal de cartones.
• El transportador aguas abajo funciona 3 segundos después de la parada aguas arriba para despejar el producto.

3) Lógica de escalera y estado del equipo simulado

Muestre la lógica y la respuesta de la máquina juntas.

• Fragmento de escalera usando TON para verificación de atascos.
• Fragmento de escalera usando TOF para tiempo de funcionamiento aguas abajo.
• Estado del transportador simulado que muestra el movimiento del producto y el despeje de la zona.

4) El caso de falla inyectada

Pruebe deliberadamente una condición anormal.

• Entrada de fotocélula parpadeante.
• Parada aguas abajo inmediata sin tiempo de funcionamiento.
• Producto haciendo puente en el punto de transferencia.

5) La revisión realizada

Documente el cambio de lógica y por qué se realizó.

• Se reemplazó la lógica de atasco basada en TOF incorrecta por TON.
• Se ajustó el valor preestablecido según el envolvente de tiempo de tránsito observado.
• Se agregó un comportamiento de enclavamiento o reinicio de falla más claro.

6) Lecciones aprendidas

Indique qué demostró el ejercicio.

• TON verifica la persistencia.
• TOF preserva el movimiento después de la pérdida del comando.
• La lógica de temporización del transportador debe derivarse del comportamiento de la máquina, no de la similitud mnemotécnica.

Este tipo de artefacto es útil porque muestra razonamiento, inyección de fallas, revisión y validación. Eso está más cerca del trabajo de ingeniería que cualquier captura de pantalla pulida.

Las definiciones de los temporizadores en sí mismas se basan en IEC 61131-3, que estandariza los conceptos de lenguaje de programación PLC y el comportamiento de los bloques de funciones. Esa es la autoridad principal para la distinción TON/TOF.

El caso más amplio para la validación basada en simulación y gemelos digitales está respaldado, de forma limitada, por literatura de ingeniería que muestra que la puesta en marcha virtual, las pruebas basadas en simulación y la validación basada en modelos pueden reducir el riesgo de integración en etapas tardías y mejorar el descubrimiento de fallas antes de la implementación en vivo. El beneficio exacto depende en gran medida de la fidelidad del modelo, el alcance de la tarea y la disciplina organizacional. Una simulación es tan honesta como las suposiciones que contiene.

Para el razonamiento adyacente a la seguridad, también es importante mantener los límites claros:

• Una simulación de entrenamiento no es equivalente a la validación de seguridad funcional.
• Practicar la lógica de temporizadores en un gemelo digital no es determinación SIL o prueba de cumplimiento.
• IEC 61508 y los marcos de seguridad relacionados rigen las expectativas del ciclo de vida de seguridad a un nivel de rigor mucho más alto que un laboratorio de entrenamiento general.

Esa distinción protege tanto la credibilidad como al lector.

- Descripción general del estándar de programa IEC 61131-3 (IEC) - Ciclo de vida de seguridad funcional IEC 61508 (IEC) - Recursos del estándar de control por lotes ISA-88 (ISA) - Manual de perspectivas ocupacionales (Oficina de Estadísticas Laborales de EE. UU.) - Revisión de gemelos digitales para sistemas de producción basados en CPS (DOI) - Recursos técnicos de seguridad funcional (exida)