IA en Automatización Industrial

Guía del artículo

Cómo implementar lógica de rebote (debounce) en PLC con temporizadores TON en OLLA Lab

Aprenda cómo los temporizadores TON pueden filtrar el rebote de entradas mecánicas ruidosas en la lógica de escalera (ladder) de un PLC, cómo elegir un valor preestablecido práctico y cómo validar el comportamiento estable de la señal de forma segura en OLLA Lab.

Respuesta directa

Para solucionar el rebote de contactos mecánicos en la lógica de escalera, los ingenieros suelen utilizar una instrucción de temporizador con retardo a la conexión (TON) como filtro de rebote por software. Al establecer el tiempo preestablecido ligeramente por encima de la duración del rebote físico —típicamente de 20 a 50 ms—, el PLC puede ignorar los cambios de estado transitorios y actuar solo ante una entrada estable.

Lo que responde este artículo

Resumen del artículo

Para solucionar el rebote de contactos mecánicos en la lógica de escalera, los ingenieros suelen utilizar una instrucción de temporizador con retardo a la conexión (TON) como filtro de rebote por software. Al establecer el tiempo preestablecido ligeramente por encima de la duración del rebote físico —típicamente de 20 a 50 ms—, el PLC puede ignorar los cambios de estado transitorios y actuar solo ante una entrada estable.

Las entradas mecánicas no conmutan de forma limpia, incluso cuando la lógica de escalera parece correcta. Un interruptor de límite, un pulsador o un contacto de relé pueden rebotar físicamente durante aproximadamente 10 a 50 ms antes de estabilizarse, y un PLC que escanea cada 1 a 10 ms puede interpretar esa única actuación como varias transiciones separadas.

Métrica de Ampergon Vallis: Durante una prueba de esfuerzo de 1,000 ciclos en el modo de simulación de OLLA Lab, una entrada de interruptor de límite de tipo mecánico produjo un promedio de 3.4 cambios de estado falsos por actuación bajo condiciones de rebote inyectado; la aplicación de un filtro TON de 50 ms eliminó esas transiciones falsas en la secuencia simulada sin un retardo de secuencia observable a nivel de máquina. Metodología: n=1,000 ciclos de actuación de entrada en un escenario de laboratorio de rebote, comparador base = entrada booleana cruda sin filtrar, ventana de tiempo = una sesión de prueba el 24/03/2026. Esto respalda el valor del rebote basado en TON en un flujo de trabajo de simulación controlado. No pretende garantizar un rendimiento universal en campo para todo tipo de hardware, tiempos de escaneo o tecnologías de sensores.

Esa distinción es importante. La sintaxis no es lo mismo que la capacidad de despliegue, y las entradas ruidosas son donde esa confusión suele volverse costosa.

¿Qué causa el rebote de contactos mecánicos en sensores industriales?

El rebote de contactos mecánicos es un efecto físico, no un error de programación. Cuando los contactos metálicos dentro de un interruptor o relé cambian de estado, a menudo vibran brevemente antes de alcanzar una condición estable de abierto o cerrado. En un circuito de control de 24 VCC, esto produce una serie rápida de transiciones momentáneas ON/OFF en lugar de un flanco limpio.

El problema práctico aparece cuando el PLC es más rápido que el hardware. Si el dispositivo de entrada rebota durante 30 ms y el controlador escanea cada 5 ms, el programa puede leer esa única pulsación como múltiples cambios de estado. El PLC no está funcionando mal; está haciendo exactamente lo que se le pidió, solo que más rápido de lo que la mecánica puede comportarse limpiamente.

Esto es más importante en la lógica que reacciona a flancos o cuenta eventos, incluyendo:

  • conteo de cajas en transportadores
  • avance de pasos en máquinas de estado
  • disparadores de alternancia principal/secundario (lead/lag)
  • enclavamiento de fallas
  • lógica de pulsadores de arranque/parada
  • retroalimentaciones de prueba de posición de interruptores de límite

Un contacto ruidoso puede crear:

  • conteos falsos
  • avance prematuro de secuencias
  • comandos duplicados
  • condiciones de carrera entre peldaños (rungs)
  • alarmas molestas
  • fallas intermitentes en la puesta en marcha

¿Por qué el ciclo de escaneo hace visible el rebote?

El ciclo de escaneo crea el conflicto entre el tiempo de estabilización física y la interpretación lógica. En un escaneo de PLC estándar, el controlador lee las entradas, ejecuta la lógica, actualiza las salidas y repite. Si la imagen de entrada captura varias transiciones de rebote a través de escaneos sucesivos, el programa puede tratarlas como cambios legítimos.

Es por esto que el rebote (debounce) no es una limpieza cosmética. Es una medida de control de tiempo que endurece la lógica contra el comportamiento electromecánico conocido antes de que ese comportamiento llegue al resto del programa.

¿Cómo filtra una instrucción TON las señales de entrada ruidosas?

Una instrucción TON filtra el rebote al requerir que la entrada permanezca continuamente TRUE durante un tiempo definido antes de que la salida se vuelva TRUE. Si la entrada cae antes de que expire el tiempo preestablecido, el temporizador se reinicia y la salida nunca se activa.

Ese es el mecanismo central. Una entrada que rebota interrumpe repetidamente el temporizador, por lo que el tiempo transcurrido nunca alcanza el umbral. Solo una señal estable sobrevive lo suficiente como para pasar.

En términos de la norma IEC 61131-3, el TON se comporta como una puerta de software determinista:

- entrada inestable: el temporizador comienza, se reinicia, comienza de nuevo, nunca califica - entrada estable: el temporizador corre continuamente hasta el valor preestablecido - estado calificado: el bit de salida se vuelve TRUE y puede ser utilizado por la lógica posterior

Una corrección útil aquí: el rebote no es lo mismo que añadir retardo en todas partes. Un buen rebote añade un pequeño retardo de calificación acotado solo donde la física de la entrada lo requiere.

Parámetros estándar IEC 61131-3 TON

Para la lógica de rebote, los parámetros TON deben entenderse operacionalmente:

- IN (Entrada): la señal cruda del sensor o interruptor que entra al temporizador Ejemplo: `Raw_Sensor_Input`

- PT (Tiempo Preestablecido): la duración mínima de TRUE continuo requerida para aceptar la señal Ejemplo: `T#50ms`

- Q (Salida): el booleano estable y filtrado utilizado por el resto del programa Ejemplo: `Sensor_01_Debounced`

- ET (Tiempo Transcurrido): el tiempo acumulado mientras `IN` permanece TRUE; se reinicia inmediatamente si `IN` pasa a FALSE antes de alcanzar `PT`

Para el rebote por software, `ET` es el indicador clave. Si sigue colapsando a cero durante una transición ruidosa, el filtro está haciendo su trabajo.

¿Qué tiempo preestablecido debería usar para el rebote?

El tiempo preestablecido debe exceder la duración esperada del rebote, pero permanecer lo suficientemente corto como para no afectar la respuesta de la máquina. Para muchos contactos mecánicos, un rango inicial práctico es de 20 a 50 ms, ajustado luego según el comportamiento del dispositivo, el tiempo de escaneo y la sensibilidad del proceso.

Use un tiempo preestablecido más corto cuando:

  • el dispositivo es relativamente limpio
  • la máquina requiere una respuesta rápida
  • la entrada no es crítica para la seguridad y es fácil de observar

Use un tiempo preestablecido más largo cuando:

  • el contacto es mecánicamente rugoso o está desgastado
  • el entorno es eléctricamente ruidoso
  • las transiciones falsas crean fallas de secuencia o errores de conteo
  • el proceso puede tolerar una calificación ligeramente más lenta

El número correcto no se adivina. Se observa, se prueba y se justifica.

¿Cuál es la estructura de lógica de escalera estándar para un rebote por software?

La estructura estándar es simple: coloque la entrada cruda en un peldaño que active un TON, luego use la salida `Q` del temporizador como la única versión aceptada de esa señal en el resto del programa.

Esa separación es importante. La entrada cruda pertenece al límite. El bit filtrado pertenece a la secuencia.

Peldaño 1: El temporizador de rebote `|---[ Raw_Sensor_Input ]---------------------[ TON: Debounce_Timer, PT: 50ms ]---|`

Peldaño 2: La lógica de acción usando la señal limpia `|---[ Debounce_Timer.Q ]---------------------( Motor_Start_Sequence )------------|`

Este es el patrón de rebote mínimo viable.

¿Por qué la lógica posterior debería usar el bit filtrado en lugar de la entrada cruda?

La lógica posterior debe usar solo el bit filtrado porque el uso mixto anula el filtro. Si un peldaño usa `Raw_Sensor_Input` y otro usa `Debounce_Timer.Q`, el programa ahora contiene dos interpretaciones en competencia del mismo dispositivo.

Eso crea una inconsistencia evitable:

  • una parte de la secuencia reacciona instantáneamente
  • otra espera la calificación
  • el orden de los eventos se vuelve dependiente del escaneo
  • la resolución de problemas se vuelve menos clara

Un patrón más limpio es:

  • la entrada cruda entra en un peldaño de filtro
  • el resultado filtrado se nombra claramente
  • toda la lógica de secuencia hace referencia a la etiqueta filtrada

Un patrón de evidencia de ingeniería compacto para la validación de rebote

Si desea demostrar criterio de control, documente el trabajo de rebote como evidencia de ingeniería en lugar de capturas de pantalla. Use esta estructura:

Ejemplo: fotocélula de transportador o interruptor de límite mecánico que activa un conteo o transición de secuencia.

Ejemplo: una actuación física produce un evento lógico y ninguna transición duplicada.

Eso es lo que debería significar "listo para simulación" en la práctica: usted puede probar, observar, diagnosticar y endurecer la lógica de control contra un comportamiento realista antes de que llegue a un proceso real.

  1. Descripción del sistema
  2. Definición operativa del comportamiento correcto
  3. Lógica de escalera y estado del equipo simulado Muestre la entrada cruda, el peldaño TON, la salida filtrada y el estado de la máquina afectado por esa salida.
  4. El caso de falla inyectada Introduzca rebote o conmutación rápida en la entrada cruda.
  5. La revisión realizada Añada o ajuste el valor preestablecido del TON, luego dirija la lógica de secuencia al bit filtrado.
  6. Lecciones aprendidas Indique qué cambió, por qué funcionó y qué riesgo de proceso eliminó.

¿Cómo se prueba la lógica de rebote de forma segura en OLLA Lab?

Usted prueba la lógica de rebote de forma segura inyectando un comportamiento de entrada inestable, observando la respuesta del temporizador y confirmando que solo el bit filtrado tiene permitido dirigir la secuencia. OLLA Lab es útil aquí porque proporciona un editor de escalera basado en navegador, modo de simulación y visibilidad de variables sin requerir hardware real.

En términos operativos, la plataforma actúa como un entorno de validación acotado. Le permite comparar lo que está haciendo la entrada, lo que está haciendo el temporizador y lo que se le permite creer a la lógica de la máquina.

Flujo de trabajo de prueba de rebote paso a paso en OLLA Lab

  1. Cree o abra un proyecto de escalera Construya una secuencia simple con una entrada booleana cruda y una acción de salida.
  2. Añada el peldaño de rebote TON Use la entrada cruda como `IN`, asigne un valor preestablecido como `T#50ms` y cree una etiqueta filtrada clara desde `Q`.
  3. Dirija la lógica de acción a través de la salida filtrada No permita que la entrada cruda dirija la acción de la máquina directamente.
  4. Ejecute el modo de simulación Inicie la lógica y abra el Panel de Variables.
  5. Conmute la entrada cruda rápidamente Simule el rebote cambiando la entrada de encendido a apagado en rápida sucesión.
  6. Observe `ET` en tiempo real Confirme que el tiempo transcurrido comienza a acumularse, luego se reinicia cuando la entrada cae antes de alcanzar `PT`.
  7. Confirme que `Q` permanece FALSE durante el ruido La salida filtrada no debería volverse TRUE hasta que la entrada permanezca estable durante toda la duración del tiempo preestablecido.
  8. Mantenga la entrada TRUE el tiempo suficiente para calificar Verifique que `Q` se vuelva TRUE solo después de que el temporizador alcance el valor preestablecido.
  9. Observe el estado de la máquina posterior Confirme que la salida o la transición de secuencia ocurre una vez, no varias veces.

Aquí es donde OLLA Lab se vuelve operativamente útil. Usted no solo está dibujando un peldaño; está validando el peldaño contra un modelo de comportamiento y verificando si la lógica sobrevive a un patrón de falla realista.

¿Qué debería observar en el Panel de Variables?

El Panel de Variables debe usarse para correlacionar el comportamiento de la entrada cruda, el estado del temporizador y la respuesta de la secuencia. Para una prueba de rebote, monitoree al menos:

  • la entrada booleana cruda
  • el valor `ET` del TON
  • la salida `Q` del TON
  • la salida posterior o bit de estado
  • cualquier contador o bit de transición de paso que sería vulnerable a un doble disparo

La observación clave es directa: si la entrada cruda vibra pero `Q` permanece estable hasta que la señal califica, la lógica de rebote está funcionando según lo previsto.

¿Qué prueba esto y qué no prueba?

Una prueba de rebote basada en simulación demuestra que la estructura de escalera y la lógica de temporización se comportan correctamente bajo las condiciones inyectadas. Ayuda a validar la causa y efecto, el comportamiento de reinicio del temporizador y la robustez de la secuencia antes de que el hardware esté involucrado.

No prueba:

  • la calidad del cableado de campo
  • la salud real del sensor
  • el rendimiento de EMC
  • la integridad de seguridad
  • la preparación final para la puesta en marcha en sitio por sí misma

Ese límite importa. La simulación es donde usted elimina errores lógicos de forma económica. El trabajo en sitio es donde aparecen los problemas restantes del mundo real.

¿Cuándo debería usar rebote por software en lugar de filtrado por hardware?

El rebote por software es apropiado cuando el problema es una entrada discreta que cambia de estado de forma demasiado ruidosa para el ciclo de escaneo y la aplicación puede tolerar un pequeño retardo de calificación. Es especialmente práctico para contactos mecánicos estándar en lógica de secuencia que no es de seguridad.

Use rebote por software cuando:

  • el dispositivo de entrada es mecánico
  • las transiciones falsas son intermitentes pero reproducibles
  • usted necesita un comportamiento de temporización transparente en el programa del PLC
  • usted desea que el filtro sea visible, ajustable y comprobable

Considere el filtrado por hardware o la detección alternativa cuando:

  • la fuente de ruido es eléctrica en lugar de mecánica
  • la ruta de la señal está mal cableada o mal blindada
  • la aplicación requiere una detección de flancos muy rápida
  • el controlador o módulo de E/S ya proporciona filtrado de entrada configurable
  • la función está relacionada con la seguridad y requiere un diseño dentro del marco de seguridad apropiado

Un TON no es una cura universal. Es una solución estándar para una clase específica de problema.

¿Cuáles son los errores de rebote más comunes en la lógica de escalera?

El error más común es filtrar demasiado tarde. Si se permite que la señal cruda incremente un contador, avance un secuenciador o enclave una falla antes del bloque de rebote, el daño ya está hecho.

Otros errores comunes incluyen:

  • usar la entrada cruda en algunos peldaños y el bit filtrado en otros
  • elegir un tiempo preestablecido sin observar el comportamiento real
  • establecer el tiempo preestablecido tan alto que la respuesta de la máquina se vuelve lenta
  • aplicar rebote a cada entrada indiscriminadamente
  • confundir el rebote de contacto con ruido analógico, fallas de cableado o errores de orden de escaneo

Una regla práctica es simple: filtre en el límite, nombre el bit filtrado claramente y úselo consistentemente.

¿Cómo deberían los ingenieros documentar una solución de rebote para la revisión de puesta en marcha?

Una solución de rebote debe documentarse como una revisión de lógica acotada vinculada a un modo de falla observado. Una buena documentación hace que el razonamiento sea revisable por otro ingeniero, técnico o integrador.

Incluya:

  • la etiqueta del dispositivo afectado y su función física
  • el síntoma observado
  • el contexto del tiempo de escaneo si es relevante
  • el tiempo preestablecido del temporizador elegido y por qué
  • la estructura de escalera revisada
  • el método de prueba utilizado
  • el criterio de aceptación
  • el resultado después de la revisión

Por ejemplo:

- Dispositivo: `LS_101_InfeedStop` - Síntoma observado: avance de paso duplicado durante una actuación mecánica única - Revisión: se añadió rebote TON, `PT = T#40ms` - Criterio de aceptación: una actuación produce una transición de secuencia - Validación: se simuló conmutación rápida en OLLA Lab, se observó el reinicio de `ET` y una única `Q` calificada

Ese es el nivel de evidencia que sobrevive a la entrega.

Conclusión

El rebote mecánico es un hecho del hardware, pero el disparo falso es una elección de diseño lógico. Un peldaño de rebote basado en TON es el método de software estándar para requerir que una señal permanezca estable antes de que el PLC la acepte, y en muchas aplicaciones un valor preestablecido de 20 a 50 ms es un rango de inicio sólido.

El punto más importante no es solo cómo colocar el temporizador. Es cómo validar el comportamiento. Un ingeniero que está preparado para la puesta en marcha puede mostrar la señal cruda, el comportamiento del filtro, el efecto posterior, la falla inyectada y la revisión que la eliminó. Esa es la diferencia entre conocer la sintaxis de escalera y estar listo para confiar en la lógica cerca de un proceso en vivo.

Lectura relacionada y próximos pasos

Enlace: El rebote por software es una habilidad fundamental en nuestro plan de estudios de Maestría en Lógica de Escalera.

Enlaces transversales: - Entendiendo los ciclos de escaneo: Cómo OLLA Lab imita el hardware real - Detecte el error #1: La condición de carrera que bloqueó el transportador

Enlace: Pruebe esta secuencia de temporización usted mismo en el preajuste de inicio rápido de lógica de rebote en OLLA Lab.

Continúe aprendiendo

- Arriba (Centro de pilares): Explore la guía de pilares - Transversal: Artículo relacionado 1 - Transversal: Artículo relacionado 2 - Abajo (Comercial/CTA): Construya su próximo proyecto en OLLA Lab

References

Transparencia editorial

Esta entrada del blog fue escrita por un ser humano, con toda la estructura central, el contenido y las ideas originales creadas por el autor. Sin embargo, esta publicación incluye texto refinado con la asistencia de ChatGPT y Gemini. La IA se utilizó exclusivamente para corregir gramática y sintaxis, y para traducir el texto original en inglés al español, francés, estonio, chino, ruso, portugués, alemán e italiano. El contenido final fue revisado, editado y validado críticamente por el autor, quien mantiene la responsabilidad total de su precisión.

Sobre el autor:PhD. Jose NERI, Lead Engineer at Ampergon Vallis

Verificación: Validez técnica confirmada el 2026-03-23 por el equipo de QA del laboratorio de Ampergon Vallis.

Listo para la implementación

Usa flujos de trabajo respaldados por simulación para convertir estos conocimientos en resultados medibles para la planta.

© 2026 Ampergon Vallis. All rights reserved.
|