Comment procéder au dépannage d'un programme API ?

Dans un ordre fixe : lire le tampon de diagnostic de la CPU pour écarter le matériel ; formuler le symptôme précisément ; identifier le bloc concerné ; remonter le chemin du signal depuis la sortie qui ne commute pas vers ses conditions. Chaque étape réduit l'espace de recherche — contrairement à une hypothèse réfutée, qui ne laisse rien.

Comment distinguer un défaut matériel d'un défaut logiciel ?

Le tampon de diagnostic de la CPU est la voie la plus rapide : il consigne les défaillances de modules, les erreurs de périphérie et les causes de STOP, horodatées. S'y ajoute la règle empirique selon laquelle les défauts reproductibles sont généralement logiciels et les défauts sporadiques généralement matériels ou liés au timing — la logique est déterministe.

Quels outils TIA Portal aident au dépannage ?

Les tables de visualisation pour lire les valeurs en direct sans perturber le process, les références croisées pour trouver tous les endroits où une variable est écrite et lue, la structure d'appel pour vérifier qu'un bloc est bien appelé cycliquement, le tampon de diagnostic pour les événements matériels, la comparaison en ligne / hors ligne pour les modifications non documentées, et PLCSIM pour reproduire sans risque.

Qu'est-ce qu'une double affectation et comment la trouver ?

Il y a double affectation lorsque la même variable est écrite dans deux blocs. Dans le déroulement cyclique, la dernière affectation traitée l'emporte : une sortie clignote ou reste à une valeur malgré une logique apparemment correcte. On la trouve par les références croisées : toute variable écrite à plus d'un endroit est suspecte.

Pourquoi mon action se déclenche-t-elle en continu au lieu d'une seule fois ?

C'est l'erreur de front classique. Soit le front montant (R_TRIG) manque et la condition redevient vraie à chaque cycle, soit un mémento de front est évalué à plusieurs endroits — la première évaluation consomme le front et la seconde n'en voit jamais. Une table de visualisation sur le mémento et ses références croisées tranchent.

Que faire quand l'installation est à l'arrêt et que la production attend ?

Un ordre fixe plutôt que l'intuition : lire le tampon de diagnostic, formuler le symptôme précisément, demander la dernière modification et la vérifier par comparaison en ligne / hors ligne, construire une table de visualisation pour la zone suspecte, remonter depuis la sortie — et consigner le constat avant de libérer l'installation.

Dépannage des programmes API : cerner méthodiquement au lieu de deviner

L'essentiel en bref

Travailler méthodiquement, c'est ne pas chercher les défauts – c'est les cerner. Ce guide présente l'ordre qui tient sous pression, les outils de TIA Portal et les classes de défauts qui couvrent la majorité des cas.

L'ordre qui tient sous pression – du symptôme à la cause
Les outils de TIA Portal – et à quoi chacun sert
Cinq classes de défauts – qui couvrent l'essentiel

1.Pourquoi l'essai-erreur est la voie la plus coûteuse

Une installation est à l'arrêt. La production attend, le téléphone sonne, et TIA Portal affiche un programme qui tournait encore hier. Le réflexe, dans cette situation, est presque toujours le même : aller regarder là où l'on soupçonne le défaut.

C'est précisément la voie la plus coûteuse. Non parce que les hypothèses seraient fausses par nature – mais parce qu'une hypothèse réfutée ne laisse rien derrière elle. On n'en sait pas plus qu'avant et on a perdu vingt minutes. Après la cinquième, une heure est passée et la pression a monté.

Le cernage méthodique fonctionne à l'inverse : chaque étape réduit de moitié l'espace de recherche, que l'hypothèse ait tenu ou non. Un résultat négatif reste un résultat.

2.L'ordre qui tient sous pression

Tout dépannage efficace suit la même chaîne :

Symptôme → matériel ou logiciel ? → bloc concerné → chemin du signal → cause

La première étape est celle que l'on saute le plus souvent – et c'est celle qui coûte le plus cher.

2.1.Étape 1 : écarter le matériel avant de regarder le code

Le tampon de diagnostic de la CPU est le premier regard lors de tout défaut, pas le dernier. Il consigne les défaillances de modules, les erreurs de périphérie, les causes de STOP et les erreurs de temps de cycle, horodatées. S'il indique une défaillance de module, chercher dans le code est du temps perdu.

En complément : les LED de la CPU et de la périphérie disent en quelques secondes ce que le code ne révélera pas en plusieurs minutes. Une LED SF rouge sur un ET 200 clôt le débat sur la logique du programme.

Le gouffre à temps classique

Un capteur défectueux, une borne desserrée ou un module hors service produisent dans le programme exactement le même symptôme qu'une erreur de logique : une condition ne devient jamais vraie. Sans faire cette distinction en premier, on peut chercher des heures un défaut qui n'est pas dans le programme.

2.2.Étape 2 : trouver le bloc concerné

Formulez le symptôme le plus concrètement possible : non pas « l'installation ne marche pas », mais « le convoyeur 3 ne démarre pas après l'ordre de marche, le message de défaut apparaît après 5 secondes ».

De cette formulation, le bloc découle presque de lui-même – à condition que le programme soit proprement structuré. Si chaque partie d'installation est encapsulée dans un bloc fonctionnel au nom parlant, vous savez immédiatement où chercher. Si tout est câblé dans OB1, la partie laborieuse commence ici.

2.3.Étape 3 : remonter le chemin du signal

Prenez la sortie qui ne commute pas et remontez vers ses conditions. Quel verrouillage empêche sa mise à 1 ? Laquelle des conditions partielles est fausse ? Et pourquoi ?

Cette remontée est le cœur de la méthode. Elle aboutit toujours à l'un de trois points : une condition d'entrée qui n'arrive jamais (matériel ou logique amont), un verrouillage qui agit (généralement à dessein), ou une affectation écrasée ailleurs.

3.Les outils de TIA Portal

Outil	À quoi il sert	Usage typique
Table de visualisation	Lire les valeurs en direct sans perturber le process	L'outil standard. Rassembler les signaux du bloc suspect et les suivre
Références croisées	Où une variable est-elle écrite, où lue ?	Premier recours contre les doubles affectations et les blocs orphelins
Structure d'appel	Le bloc est-il seulement appelé cycliquement ?	Quand un bloc « ne fait rien » alors que la logique est correcte
Tampon de diagnostic	Événements matériels horodatés	Toujours en premier. Tranche matériel / logiciel en quelques secondes
Comparaison en ligne / hors ligne	La CPU s'écarte-t-elle de l'état documenté ?	Révèle les modifications non documentées « de l'équipe de nuit »
PLCSIM	Reproduire la logique sans l'installation	Pour les défauts reproductibles et pour tester des variantes sans risque

3.1.Le forçage : l'outil dont on n'a presque jamais besoin

Le forçage écrase les entrées et sorties physiques et reste actif jusqu'à annulation explicite – y compris après un redémarrage de la CPU. Sur une installation en service avec des axes en mouvement, c'est un risque de sécurité, pas un outil de diagnostic.

Pour la simple observation, la table de visualisation suffit. Si vous devez réellement imposer une valeur, faites-le de façon ciblée, documentée et avec un collègue qui surveille l'installation – et annulez-le avant de partir. Un forçage oublié est une bombe à retardement qui explose au prochain démarrage, quand plus personne ne se souvient qu'il a été posé.

4.Cinq classes de défauts qui couvrent la majorité

4.1.1. Doubles affectations

La même variable est écrite dans deux blocs. Dans le déroulement cyclique, la dernière affectation traitée « gagne » – la sortie clignote ou reste obstinément à une valeur alors que la logique visible dit autre chose.

Détection : références croisées. Toute variable écrite à plus d'un endroit est suspecte.

4.2.2. Erreurs de détection de front

Une action se déclenche en continu au lieu d'une seule fois, ou pas du tout. La cause est le plus souvent un front montant manquant (R_TRIG) ou un mémento de front utilisé à plusieurs endroits – la première évaluation consomme le front, la seconde n'en voit jamais.

Détection : table de visualisation sur le mémento de front, plus ses références croisées.

4.3.3. Problèmes de temporisation et de cycle

Une temporisation dont la condition de départ est réinitialisée dans le même cycle n'arrive jamais à échéance. À l'inverse, des temps de cycle trop longs déclenchent l'OB d'erreur de temps (OB80) – visible dans le tampon de diagnostic.

Détection : vérifier le temps de cycle dans le diagnostic CPU, suivre l'entrée de la temporisation en table de visualisation.

4.4.4. Confusion de blocs de données

Avec des blocs fonctionnels instanciés plusieurs fois, le mauvais DB d'instance est transmis. La logique est juste, mais l'entraînement 2 réagit aux valeurs de l'entraînement 1.

Détection : examiner la structure d'appel – quel bloc reçoit quel DB ?

4.5.5. Du matériel déguisé en logiciel

Un détecteur qui vibre, une rupture de câble dans une chaîne porte-câbles, un module à défaillance sporadique. Le symptôme est visible dans le programme, la cause non.

Détection : le caractère sporadique est le signal d'alerte. Un défaut non reproductible se situe rarement dans la logique – la logique est déterministe.

Règle empirique

Les défauts reproductibles sont généralement logiciels. Les défauts sporadiques sont généralement matériels ou liés au timing. Cette seule distinction fait gagner plus de temps que n'importe quel outil.

5.Quand l'installation est à l'arrêt : l'ordre sous pression

Quand la production attend, un ordre fixe aide davantage que l'intuition :

Lire le tampon de diagnostic. 30 secondes, tranche matériel / logiciel.
Formuler le symptôme précisément. Qu'est-ce qui ne se produit pas exactement, depuis quand, dans quelles conditions ?
Demander la dernière modification. « Ça marchait hier » est l'information la plus précieuse – la comparaison en ligne / hors ligne montre si quelqu'un a touché à quelque chose.
Construire une table de visualisation pour la zone suspecte plutôt que de cliquer à travers les réseaux.
Remonter depuis la sortie vers les conditions.
Consigner le constat avant de libérer l'installation – sinon toute la recherche recommencera.

Le point 6 est presque toujours abandonné sous pression, et c'est le seul qui évite que la même recherche reparte de zéro dans trois mois.

6.Un code propre est une infrastructure de diagnostic

La plupart des points ci-dessus présupposent quelque chose : une structure de blocs claire, des noms parlants, une symbolique commentée. Ce n'est ni une fin en soi ni une question d'esthétique.

Un programme où chaque partie d'installation est encapsulée et nommée transforme des heures de devinettes en minutes de cernage ciblé. Un bloc commenté vous dit d'un coup d'œil ce qu'il est censé faire – et donc où il s'en écarte. Un bloc rempli de M0.0 et DB1.DBX0.0 ne dit rien, et le dépannage repart de zéro.

7.Conclusion

Le dépannage est une méthode, pas un talent. Trois éléments portent l'essentiel :

Écarter d'abord le matériel – le tampon de diagnostic répond en 30 secondes à la question de savoir si chercher dans le code a un sens.
Remonter depuis le symptôme plutôt que d'avancer depuis une hypothèse – chaque étape réduit l'espace de recherche, même si l'hypothèse était fausse.
Reproductible ou sporadique ? – cette distinction sépare les problèmes logiciels des problèmes matériels et de timing avant même d'ouvrir le premier réseau.

Assistance en cas de défaut

Quand une installation est à l'arrêt et que la cause ne se laisse pas cerner – ou quand le programme est si peu structuré que chaque recherche repart de zéro : j'interviens en analyse de défauts, re-documentation et refonte structurelle. Depuis le Luxembourg, régulièrement sur site en Sarre et dans la région de Trèves. Parlons-en.

8.Pour aller plus loin

Programmation API : 8 bonnes pratiques pour un code propre – la structure qui rend le dépannage efficace
Documentation API : ce qu'elle doit contenir et ce qui compte à la remise – pourquoi la liste d'alarmes est décisive en cas de défaut
Les 5 langages de programmation API selon la CEI 61131-3 – quel langage se débogue le plus facilement