Comment optimiser le temps de balayage et résoudre les défauts « Watchdog Exceeded » de l’IC695CPU310

Comprendre la cause fondamentale du défaut de dépassement du temporisateur de surveillance du RX3i

Un défaut « Watchdog Timer Exceeded » sur le PACSystems RX3i IC695CPU310 de GE Fanuc ne signifie pas automatiquement que votre processeur manque de puissance de calcul. Vous ne devez jamais traiter cette erreur en augmentant simplement le réglage du temporisateur de surveillance logiciel. La cause principale est un pic inattendu du temps d’exécution d’un seul cycle de balayage du programme de l’automate. Des conditions de boucle anormales, des appels de fonctions récursifs excessifs ou des opérations intensives sur la mémoire provoquent généralement ces retards d’exécution.

Selon les directives de référence des processeurs GE Fanuc, le temporisateur de surveillance logiciel détecte les retards anormaux dans l’achèvement du balayage. Sa plage configurable s’étend de 10 ms à 2550 ms, réglable par incréments de 10 ms. Les ingénieurs de terrain doivent toujours localiser le goulot d’étranglement du programme qui augmente le temps de balayage maximal, plutôt que de masquer les défauts logiques sous-jacents avec des délais d’expiration prolongés.

Distinguer les défaillances du temporisateur de surveillance logiciel et matériel

Les ingénieurs doivent identifier le mécanisme matériel ou logiciel exact à l’origine du défaut avant de modifier le code.

• Défaillances du temporisateur de surveillance logiciel : elles se produisent lorsqu’un seul cycle de balayage dépasse le seuil programmé du temporisateur. Les déclencheurs habituels comprennent les boucles FOR ou WHILE volumineuses, les blocs fonctionnels récursifs, les opérations non limitées sur les tableaux, le traitement intensif des chaînes de caractères, les communications Ethernet concentrées ou les écritures directes en mémoire non volatile.
• Défaillances du temporisateur de surveillance matériel : elles correspondent au déclenchement d’un mécanisme interne de sécurité du processeur. Contrairement aux erreurs logicielles, les défauts du temporisateur matériel nécessitent souvent un cycle complet de mise hors tension puis sous tension pour être effacés sur les anciennes plateformes de processeurs comme l’IC695CPU310.

Lorsqu’un arrêt inattendu se produit, accédez à la table des défauts de PAC Machine Edition (PME). Examinez la description du défaut, le code du défaut, l’horodatage et le nombre d’occurrences. Ne procédez à l’optimisation de la logique que si le journal de diagnostic indique explicitement l’expiration du temporisateur de surveillance logiciel.

Analyser la dynamique du balayage : balayage moyen et balayage maximal en pire scénario

De nombreux ingénieurs en automatisation se concentrent uniquement sur le temps moyen d’exécution du programme, ce qui crée un angle mort dangereux. Un système affichant un temps de balayage moyen de 18 ms peut facilement atteindre 240 ms lors de déclenchements conditionnels précis. Si la limite de votre temporisateur de surveillance est fixée à 200 ms, l’automate déclenchera immédiatement un défaut d’arrêt.

Une logique conditionnelle lourde provoque généralement ces arrêts aléatoires. Des opérations telles que les calculs quotidiens de rapports, l’archivage des données historiques ou les copies massives en mémoire s’exécutent pendant un seul cycle de balayage, ce qui augmente le temps d’exécution maximal.

Méthodes pratiques pour réduire le temps de balayage du contrôleur IC695CPU310

L’optimisation des cycles de balayage permet de maintenir la réactivité des boucles de commande dans les installations d’emballage à grande vitesse, de traitement de l’eau et de fabrication en continu. Appliquez les techniques d’ingénierie suivantes pour réduire le temps de balayage maximal :

• ⚙️ Mettre en œuvre le découpage temporel des grandes boucles : n’exécutez jamais de grandes boucles FOR ou WHILE au cours d’un seul cycle de balayage. Répartissez le traitement des tableaux en blocs plus petits sur plusieurs balayages consécutifs à l’aide d’index de machine à états.
• ⚙️ Vérifier les appels récursifs et les blocs fonctionnels : contrôlez l’arborescence des appels de blocs dans PAC Machine Edition. Éliminez les appels récursifs indirects dans lesquels la fonction A déclenche la fonction B, qui rappelle accidentellement la fonction A dans certaines branches logiques.
• ⚙️ Passer d’une gestion continue des données à une gestion pilotée par les événements : évitez de copier ou de mettre à l’échelle des milliers de registres analogiques à chaque balayage. Exécutez les formules mathématiques lourdes et le tri des tableaux uniquement lorsque des indicateurs de changement de données sont activés.
• ⚙️ Répartir les tâches de communication Ethernet et série : échelonnez les communications actives telles que Modbus, SRTP ou EGD sur plusieurs cycles à l’aide d’une stratégie d’interrogation à tour de rôle, au lieu d’interroger tous les nœuds externes simultanément.
• ⚙️ Limiter les écritures en mémoire flash non volatile : les appels logiques directs qui écrivent des données opérationnelles en mémoire non volatile mobilisent considérablement le processeur. Déclenchez les écritures flash périodiquement ou à la fin d’un lot, plutôt qu’à chaque balayage logique.

Procédure de dépannage sur le terrain, étape par étape

Suivez cette séquence d’ingénierie méthodique pour éliminer les pics de temps de balayage en toute sécurité :

1. Identifier l’origine du défaut : vérifiez la table des défauts de PME pour confirmer le déclenchement du temporisateur de surveillance logiciel.
2. Relever les mesures de référence : notez le temps de balayage moyen du processeur, le temps de balayage maximal en pire scénario et le réglage actuel du délai d’expiration du temporisateur de surveillance.
3. Repérer les goulots d’étranglement du code : recherchez les boucles non limitées, les transferts continus de tableaux, les communications concentrées et les écritures en mémoire flash.
4. Refactoriser la logique : appliquez des machines à états, des algorithmes à découpage temporel et des blocs logiques pilotés par les événements afin de répartir la charge de traitement.
5. Réévaluer les performances : surveillez les temps de balayage maximaux sur plusieurs équipes de production, dans les conditions de charge maximale.
6. Ajuster la marge du temporisateur de surveillance : réglez la limite finale du temporisateur logiciel légèrement au-dessus du nouveau temps de balayage maximal établi afin de conserver une marge de sécurité fiable.

Scénario d’application : optimisation d’un système de convoyage sur une ligne d’embouteillage

Dans une usine d’embouteillage de boissons à grande vitesse équipée d’un contrôleur IC695CPU310, la ligne de production subissait des défauts d’arrêt intermittents de l’automate tous les quelques jours lors des changements d’équipe.

La cause fondamentale : lors des transitions d’équipe, une sous-routine de logique à contacts active exécutait une boucle non limitée qui triait, mettait à jour et copiait 4 000 registres de suivi des produits dans un tableau d’archivage au cours d’un seul balayage. Le temps de balayage maximal est ainsi passé de 22 ms en temps normal à 265 ms, dépassant le seuil de 200 ms du temporisateur de surveillance logiciel.

La solution : notre équipe d’ingénierie a restructuré l’algorithme de tri en une machine à états à découpage temporel qui traitait 200 registres par cycle de balayage sur 20 balayages consécutifs. Cette modification a réduit le temps de balayage maximal de 265 ms à 38 ms, éliminant complètement le problème de déclenchement du temporisateur de surveillance sans modifier les composants matériels.

Foire aux questions (FAQ)

Q1 : Notre CPU310 déclenche régulièrement des défauts « Watchdog Timer Exceeded ». Cela signifie-t-il que la vitesse de notre processeur est trop faible et qu’il faut le remplacer ?
Réponse : Pas nécessairement. Le remplacement du processeur doit être votre dernière option. La plupart des erreurs du temporisateur de surveillance proviennent d’une logique de programme mal structurée, d’opérations de boucle non limitées ou de pics soudains de communication. Vous pouvez éliminer les pics de balayage en refactorisant les calculs lourds sous forme de machines à états à découpage temporel réparties sur plusieurs cycles logiques. Envisagez une mise à niveau matérielle uniquement si le temps de balayage moyen de référence reste proche de la capacité du processeur après la refactorisation du code.

Q2 : Pouvons-nous régler sans risque le temporisateur de surveillance logiciel sur sa valeur maximale de 2550 ms pour éviter les déclenchements ?
Réponse : Bien que le menu de configuration du processeur permette effectivement une valeur maximale de 2550 ms, cette pratique est déconseillée d’un point de vue technique. Prolonger la limite à ce point masque des erreurs logiques critiques, telles que les boucles infinies ou les appels récursifs bloqués. Dans une automatisation de processus critique, un processeur bloqué qui continue de fonctionner pendant 2,5 secondes avant de se déclencher peut entraîner de graves risques opérationnels et de sécurité. Maintenez la limite du temporisateur de surveillance légèrement au-dessus de votre temps de balayage maximal réel, avec une marge de sécurité raisonnable.

Q3 : D’après l’expérience de terrain, quelle est la meilleure façon de déterminer quel bloc provoque un pic du temps de balayage ?
Réponse : Utilisez les outils de diagnostic intégrés à PAC Machine Edition, associés à des temporisateurs d’exécution personnalisés. Insérez des lectures d’horodatage système avant et après les blocs fonctionnels suspects afin d’enregistrer les durées d’exécution maximales dans des registres de suivi. Comparez ces relevés avec les journaux d’état de la machine pour découvrir quels événements de production — tels que les changements de lot, la génération de rapports ou l’interrogation de l’IHM — déclenchent la charge de balayage maximale.

Réflexions de l’auteur et avis d’expert

« Au cours de nos années d’assistance sur des équipements d’automatisation industrielle chez Ubest Automation Limited, nous voyons souvent des équipes de terrain tenter de résoudre les défauts du temporisateur de surveillance de l’automate en augmentant arbitrairement les réglages du temporisateur ou en achetant du matériel neuf. Sur des plateformes comme le PACSystems RX3i, les pics de temps de balayage sont presque toujours liés à une gestion inefficace des données ou à des communications non limitées. Une approche disciplinée donnant la priorité aux logiciels permet de réduire considérablement les temps d’arrêt et de prolonger la durée de vie du matériel de commande existant. »
— Équipe d’ingénierie d’Ubest Automation Limited

Vous recherchez du matériel GE Fanuc fiable et une assistance spécialisée ?

Que vous dépanniez des systèmes existants ou recherchiez des pièces de rechange pour l’automatisation industrielle, Ubest Automation Limited fournit des composants d’automates testés et d’origine, des modules DCS et des solutions de commande industrielle.

Découvrez les composants GE Fanuc et PACSystems d’origine sur Ubest Automation Limited.