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

Dans un ordre fixe : lire d'abord la vue des alarmes sur l'IHM — quelle alarme est présente, depuis quand, et laquelle est arrivée en premier ? La première alarme est généralement la cause, tout ce qui suit une conséquence. Si aucune alarme n'est présente, le tampon de diagnostic et les LED tranchent si le logiciel est concerné. Ensuite, une référence croisée sur le bit d'alarme mène dans le bloc qui le génère, et de là on remonte le chemin du signal 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 plus vite par l'alarme : si l'IHM affiche un défaut de module ou de périphérie, le cas est clair. Si aucune alarme n'est présente, le tampon de diagnostic de la CPU donne la réponse — il consigne les défaillances de modules, les erreurs de périphérie et les causes de STOP, horodatées, à quoi s'ajoutent les LED de la CPU et de la périphérie. 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.

Comment trouver un défaut sporadique qui n'apparaît que parfois ?

Par l'archive des alarmes et une trace déclenchée sur l'alarme. L'archive montre la fréquence et les heures — dix alarmes identiques en une matinée constituent un autre problème qu'un défaut apparu pour la première fois. On enregistre ensuite tous les signaux participant à l'alarme et l'on déclenche la trace sur cette alarme précise : l'enregistrement démarre au moment de l'alarme et montre les millisecondes qui précèdent. C'est ainsi que deviennent visibles les capteurs qui scintillent, les contacts qui rebondissent et les fronts au mauvais moment, invisibles dans une table de visualisation.

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 la vue des alarmes (quelle alarme est présente, laquelle est arrivée en premier), vérifier le tampon de diagnostic et les LED si aucune alarme n'est présente, formuler le symptôme précisément, demander la dernière modification et la vérifier par comparaison en ligne / hors ligne, remonter du bit d'alarme jusqu'au bloc, construire une table de visualisation pour la zone suspecte, enregistrer une trace pour les effets trop rapides ou trop rares — et consigner le constat avant de libérer l'installation.

Dépannage des programmes API : la cause en 5 étapes

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 – sur le pupitre et dans TIA Portal
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 → alarme sur l'IHM → bloc concerné → chemin du signal → cause

Le premier regard ne va pas dans TIA Portal, mais sur le pupitre opérateur.

2.1.Étape 1 : la vue des alarmes, pas le code

Quand une installation s'arrête, elle a en général quelque chose à dire. La vue des alarmes sur le pupitre – sur un panel WinCC Unified comme sur un Comfort Panel – montre quelle alarme est présente, depuis quand et dans quel ordre les alarmes sont arrivées. Rien ne réduit plus vite l'espace de recherche : l'alarme nomme l'équipement et la fonction et, dans un concept d'alarmes bien tenu, elle indique en clair quelle autorisation manque.

Ce qui compte, c'est l'ordre des alarmes, pas la première ligne. L'alarme arrivée en premier est généralement la cause, tout ce qui suit une alarme consécutive – un arrêt d'urgence entraîne toute une chaîne derrière lui, et celui qui examine d'abord la dernière alarme travaille sur le symptôme.

Le deuxième regard va dans l'archive des alarmes. On y voit non seulement quelle panne est survenue, mais combien de fois et à quelle heure – et donc la réponse à la question qui décide de la suite : cas isolé ou état permanent ? Dix alarmes identiques en une matinée, acquittées chaque fois et l'installation relancée, décrivent un autre problème qu'un défaut qui survient pour la première fois, même si le texte de l'alarme est identique.

Et si rien n'est présent ? C'est déjà un constat en soi. Soit il n'existe pas d'alarme pour ce cas – elle manque alors au concept d'alarmes et va sur la liste des suites à donner –, soit l'installation n'est pas arrêtée par un défaut mais par un verrouillage qui agit exactement comme prévu : autorisation manquante, mauvais mode de marche, contact de porte de protection ouvert.

2.2.Étape 2 : si aucune alarme n'est présente – tampon de diagnostic et LED

C'est seulement ici que le tampon de diagnostic de la CPU devient intéressant, et alors très vite : 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, chaque minute supplémentaire dans le code est perdue.

Pour une classe de défauts, il est même l'outil de premier choix : les problèmes de communication. Un participant PROFINET qui décroche, un faux contact dans le câble, un appareil qui apparaît et disparaît cycliquement – ces événements arrivent horodatés dans le tampon de diagnostic, alors que dans le programme on ne voit que des valeurs qui se figent. La même règle vaut pour le matériel. À l'inverse : un problème purement logique ne s'y trouve pas – pour cela, l'alarme sur l'IHM est le point d'entrée.

Il en va de même pour les LED de la CPU et de la périphérie. Une LED SF rouge sur un ET 200 clôt le débat sur la logique du programme en deux secondes.

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 assez tôt, on peut chercher des heures un défaut qui n'est pas dans le programme.

2.3.Étape 3 : de l'alarme au bloc concerné

L'alarme est le point d'entrée dans le code : où ce bit d'alarme est-il mis à 1 ? Une référence croisée sur la variable d'alarme mène directement dans le bloc qui génère le défaut – à condition que le programme soit proprement structuré et que les alarmes soient générées à un endroit défini par partie d'installation.

Formulez en parallèle 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, message de défaut « retour entraînement manquant » après 5 secondes ». De cette formulation, le bloc découle presque de lui-même. Si tout est câblé dans OB1, la partie laborieuse commence ici.

2.4.Étape 4 : 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.

Chemin du signal du capteur à l'actionneur : l'entrée I0.3 est présente, la sortie Q0.5 manque — la table de visualisation circonscrit le défaut au bloc programme, la zone de recherche passe de six stations à une

2.5.Étape 5 : ce qui est trop rapide pour la table de visualisation – la trace

Certains effets ne se saisissent pas dans le cycle : un signal présent pendant 20 millisecondes, un front qui tombe au mauvais moment, une temporisation qui n'arrive qu'occasionnellement au bout. C'est à cela que sert la fonction Trace. Elle enregistre les variables choisies en synchronisme avec le cycle et montre l'évolution au lieu de la valeur instantanée.

Le geste décisif : placer le déclenchement sur l'alarme elle-même. L'enregistrement démarre alors exactement au moment où l'alarme arrive et l'on voit les millisecondes qui précèdent – au lieu d'attendre que le défaut se produise pendant qu'on regarde. On enregistre tout ce qui participe à l'alarme : les capteurs déclencheurs, les verrouillages, les temporisations.

Extrait d'une intervention

Une installation s'arrêtait sans cesse ; l'équipe maintenait la production en acquittant – dix fois en une matinée, le même message de défaut – puis a fait appel à un renfort. La fréquence et les heures d'apparition de l'alarme figuraient dans l'archive des alarmes. La référence croisée sur le bit d'alarme a mené dans le réseau où l'alarme est générée ; deux barrières optiques étaient suspectes. Avec une trace déclenchée sur cette alarme précise, l'évolution était sans ambiguïté : l'une des deux barrières scintillait. Dans de tels cas, la condition d'alarme mérite un second regard : une alarme qui réagit déjà à ce genre de rebond produit exactement cette image d'acquittements en série sans que personne ne voie la cause. Capteur et logique d'alarme s'examinent donc mieux ensemble.

3.Les outils : sur le pupitre et dans TIA Portal

Outil	À quoi il sert	Usage typique
Vue des alarmes sur l'IHM	Quelle alarme est présente, depuis quand, dans quel ordre ?	Le premier regard. La première alarme est généralement la cause, le reste est consécutif
Table de visualisation	Lire les valeurs en direct sans perturber le process	L'outil standard dans le code. Rassembler les signaux du bloc suspect et les suivre
Références croisées	Où une variable est-elle écrite, où lue ?	Du bit d'alarme vers le bloc qui le génère ; premier recours contre les doubles affectations
Trace	Enregistrer l'évolution des signaux en synchronisme avec le cycle, avec déclenchement	Pour tout ce qui est trop rapide ou trop rare pour la table de visualisation
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	Quand aucune alarme n'est présente sur l'IHM ou quand cela sent le module défaillant
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 la vue des alarmes. Quelle alarme est présente, depuis quand, et laquelle est arrivée en premier ?
Si aucune alarme n'est présente : tampon de diagnostic et LED. Tranche en quelques secondes si le logiciel est même concerné.
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.
Remonter depuis le bit d'alarme par les références croisées jusqu'au bloc, puis construire une table de visualisation pour la zone suspecte – plutôt que de cliquer à travers les réseaux.
Enregistrer une trace si l'effet est trop rapide ou trop rare pour la table de visualisation.
Consigner le constat avant de libérer l'installation – sinon toute la recherche recommencera.

Le point 7 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 :

D'abord la vue des alarmes – l'installation dit en général elle-même ce qui lui manque ; la première alarme est la cause, tout ce qui suit une conséquence.
Aucune alarme est aussi un constat – le tampon de diagnostic et les LED tranchent alors en quelques secondes si le logiciel est concerné ; et ensuite se pose la question de savoir pourquoi il n'existe pas d'alarme pour ce cas.
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.
L'outil selon la classe de défaut – les problèmes de logique par les alarmes sur l'IHM, les défauts de communication et de matériel par le tampon de diagnostic, les effets sporadiques par une trace déclenchée sur l'alarme.

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