Como implementar lógica de debounce em CLP com temporizadores TON no OLLA Lab

Para corrigir o bounce (vibração) de contatos mecânicos na lógica ladder, engenheiros frequentemente utilizam uma instrução Timer On-Delay (TON) como um filtro de debounce via software. Ao definir o tempo predefinido (preset) ligeiramente maior que a duração do bounce físico — tipicamente de 20 a 50 ms — o CLP pode ignorar mudanças de estado transitórias e atuar apenas em um sinal estável.

Entradas mecânicas não comutam de forma limpa, mesmo quando a ladder parece limpa. Uma chave fim de curso, botão ou contato de relé pode vibrar fisicamente por cerca de 10 a 50 ms antes de estabilizar, e um CLP com tempo de varredura (scan) de 1 a 10 ms pode interpretar esse único acionamento como várias transições separadas.

Métrica Ampergon Vallis: Durante um teste de estresse de 1.000 ciclos no modo de simulação do OLLA Lab, uma entrada de chave fim de curso mecânica bruta produziu uma média de 3,4 falsas mudanças de estado por acionamento sob condições de bounce injetado; a aplicação de um filtro TON de 50 ms removeu essas falsas transições na sequência simulada sem atraso observável no nível da máquina. Metodologia: n=1.000 ciclos de acionamento de entrada em um cenário de laboratório de debounce, comparador de linha de base = entrada booleana bruta não filtrada, janela de tempo = uma sessão de teste em 24/03/2026. Isso sustenta o valor do debounce baseado em TON em um fluxo de trabalho de simulação controlado. Não se alega desempenho de campo universal em todos os hardwares, tempos de varredura ou tecnologias de sensores.

Essa distinção é importante. Sintaxe não é o mesmo que capacidade de implementação, e entradas ruidosas são onde essa confusão geralmente se torna cara.

O bounce de contato mecânico é um efeito físico, não um erro de programação. Quando contatos metálicos dentro de uma chave ou relé mudam de estado, eles frequentemente vibram brevemente antes de atingir uma condição estável de aberto ou fechado. Em um circuito de controle de 24 VCC, isso produz uma série rápida de transições momentâneas LIGA/DESLIGA em vez de uma borda limpa.

O problema prático aparece quando o CLP é mais rápido que o hardware. Se o dispositivo de entrada vibra por 30 ms e o controlador faz a varredura a cada 5 ms, o programa pode ler esse único pressionamento como múltiplas mudanças de estado. O CLP não está com defeito; ele está fazendo exatamente o que lhe foi pedido, apenas mais rápido do que a mecânica consegue se comportar de forma limpa.

Isso é mais importante em lógicas que reagem a bordas ou contam eventos, incluindo:

• contagem de caixas em esteiras
• avanço de etapas em máquinas de estado
• gatilhos de alternância principal/reserva (lead/lag)
• travamento de falhas
• lógica de botões de partida/parada
• feedbacks de prova de posição de chaves fim de curso

Um contato ruidoso pode criar:

• contagens falsas
• avanço prematuro de sequência
• comandos duplicados
• condições de corrida (race conditions) entre degraus (rungs)
• alarmes incômodos
• falhas intermitentes de comissionamento

Por que o ciclo de varredura torna o bounce visível?

O ciclo de varredura cria o conflito entre o tempo de estabilização física e a interpretação lógica. Em uma varredura padrão de CLP, o controlador lê as entradas, executa a lógica, atualiza as saídas e repete. Se a imagem da entrada capturar várias transições de bounce em varreduras sucessivas, o programa pode tratá-las como mudanças legítimas.

É por isso que o debounce não é uma limpeza cosmética. É uma medida de controle de tempo que endurece a lógica contra comportamentos eletromecânicos conhecidos antes que esse comportamento chegue ao restante do programa.

Uma instrução TON filtra o bounce exigindo que a entrada permaneça continuamente VERDADEIRA por um tempo definido antes que a saída se torne VERDADEIRA. Se a entrada cair antes que o tempo predefinido expire, o temporizador reinicia e a saída nunca liga.

Esse é o mecanismo central. Uma entrada com bounce interrompe repetidamente o temporizador, de modo que o tempo decorrido nunca atinge o limite. Apenas um sinal estável sobrevive tempo suficiente para passar.

Em termos da norma IEC 61131-3, o TON se comporta como um portão de software determinístico:

- entrada instável: o temporizador inicia, reinicia, inicia novamente, nunca qualifica - entrada estável: o temporizador roda continuamente até o preset - estado qualificado: o bit de saída torna-se VERDADEIRO e pode ser usado pela lógica subsequente

Uma correção útil aqui: debounce não é o mesmo que adicionar atraso em tudo. Um bom debounce adiciona um pequeno atraso de qualificação limitado apenas onde a física da entrada exige.

Parâmetros padrão IEC 61131-3 TON

Para lógica de debounce, os parâmetros TON devem ser entendidos operacionalmente:

- IN (Entrada): o sinal bruto do sensor ou chave entrando no temporizador Exemplo: `Raw_Sensor_Input`

- PT (Tempo Predefinido): a duração mínima contínua em VERDADEIRO necessária para aceitar o sinal Exemplo: `T#50ms`

- Q (Saída): o booleano estável e com debounce usado pelo restante do programa Exemplo: `Sensor_01_Debounced`

- ET (Tempo Decorrido): o tempo acumulado enquanto `IN` permanece VERDADEIRO; ele reinicia imediatamente se `IN` for para FALSO antes de atingir `PT`

Para debounce de software, `ET` é o indicador. Se ele continua voltando a zero durante uma transição ruidosa, o filtro está fazendo seu trabalho.

Qual tempo predefinido você deve usar para debounce?

O tempo predefinido deve exceder a duração esperada do bounce, mas permanecer curto o suficiente para não prejudicar a resposta da máquina. Para muitos contatos mecânicos, uma faixa inicial prática é de 20 a 50 ms, ajustada com base no comportamento do dispositivo, tempo de varredura e sensibilidade do processo.

Use um preset mais curto quando:

• o dispositivo for relativamente limpo
• a máquina exigir resposta rápida
• a entrada não for crítica para a segurança e for fácil de observar

Use um preset mais longo quando:

• o contato for mecanicamente áspero ou desgastado
• o ambiente for eletricamente ruidoso
• falsas transições criarem falhas de sequência ou erros de contagem
• o processo puder tolerar uma qualificação ligeiramente mais lenta

O número correto não é adivinhado. Ele é observado, testado e justificado.

A estrutura padrão é simples: coloque a entrada bruta em um degrau (rung) que aciona um TON, então use a saída `Q` do temporizador como a única versão aceita desse sinal em outros lugares do programa.

Essa separação é importante. A entrada bruta pertence à borda (boundary). O bit com debounce pertence à sequência.

Rung 1: O temporizador de debounce `|---[ Raw_Sensor_Input ]---------------------[ TON: Debounce_Timer, PT: 50ms ]---|`

Rung 2: A lógica de ação usando o sinal limpo `|---[ Debounce_Timer.Q ]---------------------( Motor_Start_Sequence )------------|`

Este é o padrão de debounce mínimo viável.

Por que a lógica subsequente deve usar o bit com debounce em vez da entrada bruta?

A lógica subsequente deve usar apenas o bit com debounce porque o uso misto derrota o filtro. Se um degrau usa `Raw_Sensor_Input` e outro usa `Debounce_Timer.Q`, o programa agora contém duas interpretações concorrentes do mesmo dispositivo.

Isso cria uma inconsistência evitável:

• uma parte da sequência reage instantaneamente
• outra espera pela qualificação
• a ordem dos eventos torna-se dependente da varredura
• a solução de problemas torna-se menos clara

Um padrão mais limpo é:

• a entrada bruta entra em um degrau de filtro
• o resultado filtrado é nomeado claramente
• toda a lógica de sequência referencia a tag filtrada

Um padrão de evidência de engenharia compacto para validação de debounce

Se você deseja demonstrar julgamento de controle, documente o trabalho de debounce como evidência de engenharia em vez de capturas de tela. Use esta estrutura:

Exemplo: fotocélula de esteira ou chave fim de curso mecânica acionando uma contagem ou transição de sequência.

Exemplo: um acionamento físico produz um evento lógico e nenhuma transição duplicada.

É isso que "pronto para simulação" deve significar na prática: você pode provar, observar, diagnosticar e endurecer a lógica de controle contra comportamentos realistas antes que ela chegue a um processo real.

1. Descrição do Sistema
2. Definição operacional do comportamento correto
3. Lógica ladder e estado do equipamento simulado Mostre a entrada bruta, o degrau do TON, a saída com debounce e o estado da máquina afetado por essa saída.
4. O caso de falha injetada Introduza bounce ou alternância rápida na entrada bruta.
5. A revisão feita Adicione ou ajuste o preset do TON, então direcione a lógica de sequência para o bit filtrado.
6. Lições aprendidas Declare o que mudou, por que funcionou e qual risco de processo foi removido.

Você testa a lógica de debounce com segurança injetando comportamento de entrada instável, observando a resposta do temporizador e confirmando que apenas o bit filtrado tem permissão para conduzir a sequência. O OLLA Lab é útil aqui porque fornece um editor ladder baseado em navegador, modo de simulação e visibilidade de variáveis sem exigir hardware real.

Em termos operacionais, a plataforma atua como um ambiente de validação delimitado. Ela permite que você compare o que a entrada está fazendo, o que o temporizador está fazendo e o que a lógica da máquina tem permissão para acreditar.

Fluxo de trabalho de teste de debounce passo a passo no OLLA Lab

1. Crie ou abra um projeto ladder Construa uma sequência simples com uma entrada booleana bruta e uma ação de saída.
2. Adicione o degrau de debounce TON Use a entrada bruta como `IN`, atribua um preset como `T#50ms` e crie uma tag filtrada clara a partir de `Q`.
3. Direcione a lógica de ação através da saída filtrada Não deixe a entrada bruta conduzir a ação da máquina diretamente.
4. Execute o modo de simulação Inicie a lógica e abra o Painel de Variáveis.
5. Alterne a entrada bruta rapidamente Simule o bounce ligando e desligando a entrada em rápida sucessão.
6. Observe o `ET` em tempo real Confirme que o tempo decorrido começa a acumular e, em seguida, reinicia quando a entrada cai antes de atingir `PT`.
7. Confirme que `Q` permanece FALSO durante o ruído A saída com debounce não deve se tornar VERDADEIRA até que a entrada permaneça estável durante todo o tempo predefinido.
8. Mantenha a entrada VERDADEIRA tempo suficiente para qualificar Verifique se `Q` se torna VERDADEIRO apenas após o temporizador atingir o preset.
9. Observe o estado da máquina subsequente Confirme que a saída ou transição de sequência ocorre uma vez, não várias vezes.

É aqui que o OLLA Lab se torna operacionalmente útil. Você não está apenas desenhando um degrau; você está validando o degrau contra um modelo de comportamento e verificando se a lógica sobrevive a um padrão de falha realista.

O que você deve observar no Painel de Variáveis?

O Painel de Variáveis deve ser usado para correlacionar o comportamento da entrada bruta, o estado do temporizador e a resposta da sequência. Para um teste de debounce, monitore pelo menos:

• a entrada booleana bruta
• o valor `ET` do TON
• a saída `Q` do TON
• a saída subsequente ou bit de estado
• qualquer contador ou bit de transição de etapa que seria vulnerável a disparos duplos

A observação chave é direta: se a entrada bruta oscila, mas `Q` permanece estável até que o sinal se qualifique, a lógica de debounce está funcionando como pretendido.

O que isso prova e o que não prova?

Um teste de debounce baseado em simulação prova que a estrutura ladder e a lógica de tempo se comportam corretamente sob as condições injetadas. Ele ajuda a validar causa e efeito, comportamento de reinicialização do temporizador e robustez da sequência antes que o hardware esteja envolvido.

Ele não prova:

• qualidade da fiação de campo
• integridade real do sensor
• desempenho de EMC
• integridade de segurança
• prontidão final de comissionamento no local por si só

Esse limite é importante. A simulação é onde você remove erros lógicos de forma barata. O trabalho no local é onde os problemas reais restantes aparecem.

O debounce de software é apropriado quando o problema é uma entrada discreta que muda de estado de forma muito ruidosa para o ciclo de varredura e a aplicação pode tolerar um pequeno atraso de qualificação. É especialmente prático para contatos mecânicos padrão em lógica de sequência não relacionada à segurança.

Use debounce de software quando:

• o dispositivo de entrada for mecânico
• as falsas transições forem intermitentes, mas reproduzíveis
• você precisar de um comportamento de temporização transparente no programa do CLP
• você quiser que o filtro seja visível, ajustável e testável

Considere filtragem de hardware ou sensoriamento alternativo quando:

• a fonte de ruído for elétrica em vez de mecânica
• o caminho do sinal estiver mal cabeado ou mal blindado
• a aplicação exigir detecção de borda muito rápida
• o controlador ou módulo de E/S já fornecer filtragem de entrada configurável
• a função for relacionada à segurança e exigir projeto dentro da estrutura de segurança apropriada

Um TON não é uma cura universal. É uma correção padrão para uma classe específica de problema.

O erro mais comum é filtrar tarde demais. Se o sinal bruto tiver permissão para incrementar um contador, avançar um sequenciador ou travar uma falha antes do bloco de debounce, o dano já está feito.

Outros erros comuns incluem:

• usar a entrada bruta em alguns degraus e o bit filtrado em outros
• escolher um tempo predefinido sem observar o comportamento real
• definir o preset tão alto que a resposta da máquina se torna lenta
• aplicar debounce a cada entrada indiscriminadamente
• confundir bounce de contato com ruído analógico, falhas de fiação ou bugs de ordem de varredura

Uma regra prática é simples: filtre na borda, nomeie o bit filtrado claramente e use-o consistentemente.

Uma correção de debounce deve ser documentada como uma revisão lógica delimitada vinculada a um modo de falha observado. Uma boa documentação torna o raciocínio revisável por outro engenheiro, técnico ou integrador.

Inclua:

• a tag do dispositivo afetado e a função física
• o sintoma observado
• o contexto do tempo de varredura, se relevante
• o preset do temporizador escolhido e por quê
• a estrutura ladder revisada
• o método de teste usado
• o critério de aceitação
• o resultado após a revisão

Por exemplo:

- Dispositivo: `LS_101_InfeedStop` - Sintoma observado: avanço de etapa duplicado durante acionamento mecânico único - Revisão: adicionado debounce TON, `PT = T#40ms` - Critério de aceitação: um acionamento produz uma transição de sequência - Validação: alternância rápida simulada no OLLA Lab, observada reinicialização de `ET` e `Q` qualificado único

Esse é o nível de evidência que sobrevive à transferência de responsabilidade.

O bounce mecânico é um fato de hardware, mas o disparo falso é uma escolha de design lógico. Um degrau de debounce baseado em TON é o método de software padrão para exigir que um sinal permaneça estável antes que o CLP o aceite, e em muitas aplicações um preset de 20 a 50 ms é uma faixa inicial sólida.

O ponto maior não é apenas como colocar o temporizador. É como validar o comportamento. Um engenheiro que está preparado para o comissionamento pode mostrar o sinal bruto, o comportamento do filtro, o efeito subsequente, a falha injetada e a revisão que a removeu. Essa é a diferença entre conhecer a sintaxe ladder e estar pronto para confiar na lógica perto de um processo real.

Link up: O debounce de software é uma habilidade fundamental em nosso currículo de Domínio de Lógica Ladder.

Links across: - Entendendo os Ciclos de Varredura: Como o OLLA Lab imita o hardware real - Encontre o Erro #1: A condição de corrida que travou a esteira

Link down: Teste esta sequência de temporização você mesmo no Preset de Início Rápido de Lógica de Debounce no OLLA Lab.

- Up (Pillar Hub): Explore a orientação do pilar - Across: Artigo relacionado 1 - Across: Artigo relacionado 2 - Down (Comercial/CTA): Construa seu próximo projeto no OLLA Lab

- IEC 61131-3 (Controladores Programáveis, Parte 3) - NFPA 79 Norma Elétrica para Máquinas Industriais - Guia Técnico Omron: Noções básicas de bounce de contatos de relés e chaves - Recursos de tecnologia de chaves Cherry MX