Comment implémenter une logique d'anti-rebond API avec des temporisateurs TON dans OLLA Lab

Pour corriger les rebonds de contacts mécaniques dans la logique à contacts (Ladder), les ingénieurs utilisent souvent une instruction de temporisation au travail (TON) comme filtre logiciel d'anti-rebond. En réglant la temporisation légèrement au-delà de la durée physique du rebond — généralement entre 20 et 50 ms — l'API peut ignorer les changements d'état transitoires et ne réagir qu'à une entrée stable.

Les entrées mécaniques ne commutent pas proprement, même lorsque le schéma Ladder semble correct. Un fin de course, un bouton-poussoir ou un contact de relais peut physiquement rebondir pendant environ 10 à 50 ms avant de se stabiliser, et un API scannant toutes les 1 à 10 ms peut interpréter cette unique action comme plusieurs transitions distinctes.

Métrique Ampergon Vallis : Lors d'un test de contrainte de 1 000 cycles en mode simulation dans OLLA Lab, une entrée de fin de course mécanique brute a produit une moyenne de 3,4 faux changements d'état par actionnement dans des conditions de rebond injecté ; l'application d'un filtre TON de 50 ms a éliminé ces fausses transitions dans la séquence simulée sans retard de séquence observable au niveau de la machine. Méthodologie : n=1 000 cycles d'actionnement d'entrée dans un scénario de laboratoire d'anti-rebond, comparateur de référence = entrée booléenne brute non filtrée, fenêtre temporelle = une session de test le 24/03/2026. Cela confirme la valeur de l'anti-rebond basé sur TON dans un flux de travail de simulation contrôlé. Cela ne prétend pas à une performance universelle sur le terrain pour tous les matériels, temps de cycle ou technologies de capteurs.

Cette distinction est importante. La syntaxe n'est pas synonyme de déployabilité, et les entrées bruyantes sont généralement là où cette confusion devient coûteuse.

Le rebond de contact mécanique est un effet physique, pas une erreur de programmation. Lorsque les contacts métalliques à l'intérieur d'un commutateur ou d'un relais changent d'état, ils vibrent souvent brièvement avant d'atteindre une condition stable d'ouverture ou de fermeture. Dans un circuit de commande 24 VDC, cela produit une série rapide de transitions momentanées ON/OFF plutôt qu'un front propre.

Le problème pratique survient lorsque l'API est plus rapide que le matériel. Si le dispositif d'entrée rebondit pendant 30 ms et que le contrôleur scanne toutes les 5 ms, le programme peut lire cette pression unique comme de multiples changements d'état. L'API ne fonctionne pas mal ; il fait exactement ce qu'on lui demande, simplement plus vite que la mécanique ne peut se comporter proprement.

Cela est particulièrement critique dans la logique qui réagit aux fronts ou compte des événements, notamment :

• le comptage de boîtes sur des convoyeurs
• l'avancement des étapes d'une machine à états
• les déclencheurs d'alternance maître/esclave
• le verrouillage de défauts
• la logique des boutons-poussoirs marche/arrêt
• les retours de position des fins de course

Un contact bruyant peut créer :

• des faux comptages
• un avancement prématuré de séquence
• des commandes en double
• des conditions de course entre les barreaux (rungs)
• des alarmes intempestives
• des échecs de mise en service intermittents

Pourquoi le cycle de scan rend-il le rebond visible ?

Le cycle de scan crée le conflit entre le temps de stabilisation physique et l'interprétation logique. Dans un scan API standard, le contrôleur lit les entrées, exécute la logique, met à jour les sorties et recommence. Si l'image des entrées capture plusieurs transitions de rebond sur des scans successifs, le programme peut les traiter comme des changements légitimes.

C'est pourquoi l'anti-rebond n'est pas un simple nettoyage cosmétique. C'est une mesure de contrôle temporel qui renforce la logique contre un comportement électromécanique connu avant que ce comportement n'atteigne le reste du programme.

Une instruction TON filtre le rebond en exigeant que l'entrée reste continuellement à TRUE pendant une durée définie avant que la sortie ne devienne TRUE. Si l'entrée chute avant l'expiration de la temporisation, le temporisateur se réinitialise et la sortie ne s'active jamais.

C'est le mécanisme fondamental. Une entrée qui rebondit interrompt à plusieurs reprises le temporisateur, de sorte que le temps écoulé n'atteint jamais le seuil. Seul un signal stable survit assez longtemps pour passer.

En termes IEC 61131-3, le TON se comporte comme une porte logique logicielle déterministe :

- entrée instable : le temporisateur démarre, se réinitialise, redémarre, ne se qualifie jamais - entrée stable : le temporisateur tourne continuellement jusqu'à la valeur prédéfinie - état qualifié : le bit de sortie devient TRUE et peut être utilisé par la logique aval

Une précision utile ici : l'anti-rebond n'est pas la même chose que l'ajout de délais partout. Un bon anti-rebond ajoute un petit délai de qualification borné uniquement là où la physique de l'entrée l'exige.

Paramètres standard IEC 61131-3 TON

Pour la logique d'anti-rebond, les paramètres TON doivent être compris opérationnellement :

- IN (Entrée) : le signal brut du capteur ou du commutateur entrant dans le temporisateur Exemple : `Raw_Sensor_Input`

- PT (Temps prédéfini) : la durée minimale continue à TRUE requise pour accepter le signal Exemple : `T#50ms`

- Q (Sortie) : le booléen stable et anti-rebond utilisé par le reste du programme Exemple : `Sensor_01_Debounced`

- ET (Temps écoulé) : le temps accumulé tant que `IN` reste TRUE ; il se réinitialise immédiatement si `IN` passe à FALSE avant d'atteindre `PT`

Pour l'anti-rebond logiciel, `ET` est l'indicateur clé. S'il revient sans cesse à zéro lors d'une transition bruyante, le filtre fait son travail.

Quelle temporisation utiliser pour l'anti-rebond ?

La temporisation doit dépasser la durée prévue du rebond tout en restant assez courte pour ne pas nuire à la réponse de la machine. Pour de nombreux contacts mécaniques, une plage de départ pratique est de 20 à 50 ms, ajustée ensuite en fonction du comportement du dispositif, du temps de cycle et de la sensibilité du processus.

Utilisez une temporisation plus courte lorsque :

• le dispositif est relativement propre
• la machine nécessite une réponse rapide
• l'entrée n'est pas critique pour la sécurité et est facile à observer

Utilisez une temporisation plus longue lorsque :

• le contact est mécaniquement rugueux ou usé
• l'environnement est électriquement bruyant
• les fausses transitions créent des défauts de séquence ou des erreurs de comptage
• le processus peut tolérer une qualification légèrement plus lente

Le bon chiffre ne se devine pas. Il s'observe, se teste et se justifie.

La structure standard est simple : placez l'entrée brute sur un barreau qui pilote un TON, puis utilisez la sortie `Q` du temporisateur comme seule version acceptée de ce signal ailleurs dans le programme.

Cette séparation est importante. L'entrée brute appartient à la frontière. Le bit anti-rebond appartient à la séquence.

Barreau 1 : Le temporisateur d'anti-rebond `|---[ Raw_Sensor_Input ]---------------------[ TON: Debounce_Timer, PT: 50ms ]---|`

Barreau 2 : La logique d'action utilisant le signal propre `|---[ Debounce_Timer.Q ]---------------------( Motor_Start_Sequence )------------|`

C'est le modèle d'anti-rebond minimal viable.

Pourquoi la logique aval doit-elle utiliser le bit anti-rebond plutôt que l'entrée brute ?

La logique aval ne doit utiliser que le bit anti-rebond, car une utilisation mixte annule l'effet du filtre. Si un barreau utilise `Raw_Sensor_Input` et un autre `Debounce_Timer.Q`, le programme contient alors deux interprétations concurrentes du même dispositif.

Cela crée une incohérence évitable :

• une partie de la séquence réagit instantanément
• une autre attend la qualification
• l'ordre des événements devient dépendant du scan
• le dépannage devient moins clair

Un modèle plus propre est :

• l'entrée brute entre dans un barreau de filtrage
• le résultat filtré est nommé clairement
• toute la logique de séquence référence le tag filtré

Un modèle de preuve technique compact pour la validation de l'anti-rebond

Si vous souhaitez démontrer votre jugement de contrôle, documentez le travail d'anti-rebond comme une preuve technique plutôt que par des captures d'écran. Utilisez cette structure :

Exemple : cellule photoélectrique de convoyeur ou fin de course mécanique pilotant un comptage ou une transition de séquence.

Exemple : un actionnement physique produit un événement logique et aucune transition en double.

C'est ce que "prêt pour la simulation" devrait signifier en pratique : vous pouvez prouver, observer, diagnostiquer et durcir la logique de contrôle contre un comportement réaliste avant qu'elle n'atteigne un processus réel.

1. Description du système
2. Définition opérationnelle du comportement correct
3. Logique à contacts et état simulé de l'équipement Montrez l'entrée brute, le barreau TON, la sortie anti-rebond et l'état de la machine affecté par cette sortie.
4. Le cas de défaut injecté Introduisez un rebond ou une commutation rapide sur l'entrée brute.
5. La révision effectuée Ajoutez ou ajustez la temporisation TON, puis dirigez la logique de séquence vers le bit filtré.
6. Leçons apprises Indiquez ce qui a changé, pourquoi cela a fonctionné et quel risque de processus a été éliminé.

Vous testez la logique d'anti-rebond en toute sécurité en injectant un comportement d'entrée instable, en observant la réponse du temporisateur et en confirmant que seul le bit filtré est autorisé à piloter la séquence. OLLA Lab est utile ici car il fournit un éditeur Ladder basé sur navigateur, un mode simulation et une visibilité des variables sans nécessiter de matériel réel.

En termes opérationnels, la plateforme agit comme un environnement de validation borné. Elle vous permet de comparer ce que fait l'entrée, ce que fait le temporisateur et ce que la logique machine est autorisée à croire.

Flux de travail de test d'anti-rebond étape par étape dans OLLA Lab

1. Créez ou ouvrez un projet Ladder Construisez une séquence simple avec une entrée booléenne brute et une action de sortie.
2. Ajoutez le barreau d'anti-rebond TON Utilisez l'entrée brute comme `IN`, assignez une temporisation telle que `T#50ms` et créez un tag filtré clair à partir de `Q`.
3. Dirigez la logique d'action via la sortie filtrée Ne laissez pas l'entrée brute piloter l'action machine directement.
4. Exécutez le mode simulation Démarrez la logique et ouvrez le panneau des variables.
5. Basculez l'entrée brute rapidement Simulez le rebond en activant et désactivant l'entrée en succession rapide.
6. Surveillez `ET` en temps réel Confirmez que le temps écoulé commence à s'accumuler, puis se réinitialise lorsque l'entrée chute avant d'atteindre `PT`.
7. Confirmez que `Q` reste FALSE pendant le bruit La sortie anti-rebond ne doit pas passer à TRUE tant que l'entrée ne reste pas stable pendant toute la durée de la temporisation.
8. Maintenez l'entrée TRUE assez longtemps pour la qualifier Vérifiez que `Q` passe à TRUE uniquement après que le temporisateur a atteint la valeur prédéfinie.
9. Observez l'état de la machine en aval Confirmez que la sortie ou la transition de séquence se produit une seule fois, et non plusieurs fois.

C'est là qu'OLLA Lab devient opérationnellement utile. Vous ne dessinez pas seulement un barreau ; vous validez le barreau par rapport à un modèle de comportement et vérifiez si la logique survit à un modèle de défaut réaliste.

Que surveiller dans le panneau des variables ?

Le panneau des variables doit être utilisé pour corréler le comportement de l'entrée brute, l'état du temporisateur et la réponse de la séquence. Pour un test d'anti-rebond, surveillez au moins :

• l'entrée booléenne brute
• la valeur `ET` du TON
• la sortie `Q` du TON
• la sortie aval ou le bit d'état
• tout compteur ou bit de transition d'étape vulnérable au double déclenchement

L'observation clé est simple : si l'entrée brute "bavarde" mais que `Q` reste stable jusqu'à ce que le signal soit qualifié, la logique d'anti-rebond fonctionne comme prévu.

Qu'est-ce que cela prouve, et qu'est-ce que cela ne prouve pas ?

Un test d'anti-rebond basé sur la simulation prouve que la structure Ladder et la logique de temporisation se comportent correctement dans les conditions injectées. Il aide à valider la relation de cause à effet, le comportement de réinitialisation du temporisateur et la robustesse de la séquence avant l'implication du matériel.

Il ne prouve pas :

• la qualité du câblage sur site
• l'état réel du capteur
• la performance CEM
• l'intégrité de la sécurité
• la préparation finale à la mise en service sur site par lui-même

Cette limite est importante. La simulation est l'endroit où vous éliminez les erreurs logiques à moindre coût. Le travail sur site est là où les problèmes réels restants apparaissent.

L'anti-rebond logiciel est approprié lorsque le problème est une entrée discrète qui change d'état trop bruyamment pour le cycle de scan et que l'application peut tolérer un petit délai de qualification. Il est particulièrement pratique pour les contacts mécaniques standard dans la logique de séquence non liée à la sécurité.

Utilisez l'anti-rebond logiciel lorsque :

• le dispositif d'entrée est mécanique
• les fausses transitions sont intermittentes mais reproductibles
• vous avez besoin d'un comportement temporel transparent dans le programme API
• vous voulez que le filtre soit visible, ajustable et testable

Envisagez un filtrage matériel ou une détection alternative lorsque :

• la source de bruit est électrique plutôt que mécanique
• le chemin du signal est mal câblé ou mal blindé
• l'application nécessite une détection de front très rapide
• le contrôleur ou le module d'E/S fournit déjà un filtrage d'entrée configurable
• la fonction est liée à la sécurité et nécessite une conception dans le cadre de sécurité approprié

Un TON n'est pas un remède universel. C'est une solution standard pour une classe spécifique de problèmes.

L'erreur la plus courante est de filtrer trop tard. Si le signal brut est autorisé à incrémenter un compteur, faire avancer un séquenceur ou verrouiller un défaut avant le bloc d'anti-rebond, le dommage est déjà fait.

D'autres erreurs courantes incluent :

• utiliser l'entrée brute dans certains barreaux et le bit filtré dans d'autres
• choisir une temporisation sans observer le comportement réel
• régler la temporisation si haut que la réponse de la machine devient lente
• appliquer l'anti-rebond à chaque entrée sans discernement
• confondre le rebond de contact avec le bruit analogique, les défauts de câblage ou les bugs d'ordre de scan

Une règle pratique est simple : filtrez à la frontière, nommez le bit filtré clairement et utilisez-le de manière cohérente.

Une correction d'anti-rebond doit être documentée comme une révision logique bornée liée à un mode de défaut observé. Une bonne documentation rend le raisonnement vérifiable par un autre ingénieur, technicien ou intégrateur.

Incluez :

• le tag du dispositif affecté et sa fonction physique
• le symptôme observé
• le contexte du temps de cycle si pertinent
• la temporisation choisie et pourquoi
• la structure Ladder révisée
• la méthode de test utilisée
• le critère d'acceptation
• le résultat après révision

Par exemple :

- Dispositif : `LS_101_InfeedStop` - Symptôme observé : avance d'étape en double lors d'un actionnement mécanique unique - Révision : ajout d'un anti-rebond TON, `PT = T#40ms` - Critère d'acceptation : un actionnement produit une transition de séquence - Validation : commutation rapide simulée dans OLLA Lab, observation des réinitialisations de `ET` et d'un seul `Q` qualifié

C'est le niveau de preuve qui survit au transfert de dossier.

Le rebond mécanique est un fait matériel, mais le faux déclenchement est un choix de conception logique. Un barreau d'anti-rebond basé sur TON est la méthode logicielle standard pour exiger qu'un signal reste stable avant que l'API ne l'accepte, et dans de nombreuses applications, une temporisation de 20 à 50 ms est une plage de départ solide.

Le point le plus important n'est pas seulement comment placer le temporisateur. C'est comment valider le comportement. Un ingénieur préparé à la mise en service peut montrer le signal brut, le comportement du filtre, l'effet en aval, le défaut injecté et la révision qui l'a éliminé. C'est la différence entre connaître la syntaxe Ladder et être prêt à faire confiance à la logique près d'un processus réel.

Lien vers le haut : L'anti-rebond logiciel est une compétence fondamentale de notre cursus de maîtrise de la logique à contacts (Ladder Logic Mastery).

Liens transversaux : - Comprendre les cycles de scan : Comment OLLA Lab imite le matériel réel - Repérez l'erreur n°1 : La condition de course qui a fait planter le convoyeur

Lien vers le bas : Testez vous-même cette séquence temporelle dans le préréglage de démarrage rapide de la logique d'anti-rebond dans OLLA Lab.

- Haut (Pillar Hub) : Explorer les conseils du pilier - Transversal : Article associé 1 - Transversal : Article associé 2 - Bas (Commercial/CTA) : Construisez votre prochain projet dans OLLA Lab

- IEC 61131-3 (Automates programmables, Partie 3) - NFPA 79 Norme électrique pour les machines industrielles - Guide technique Omron : Bases du rebond des contacts de relais et de commutateurs - Ressources sur la technologie des commutateurs Cherry MX