Structure des programmes TP FANUC : quand utiliser CALL, quand utiliser JMP LBL et quand passer au BG Logic

Vous avez hérité d’un programme TP qui comptait 80 lignes à l’origine et qui en compte maintenant 600. Le robot fait son travail, mais l’ajout d’une seule nouvelle séquence de préhenseur brise le comportement à trois autres endroits, et le journal d’alarmes se remplit d’INTP-105 et de PROG-040. La solution n’est pas « plus de JMP LBL », mais un autre choix de structure de contrôle. Chez Probot Systèmes, nous restructurons constamment des programmes TP de ce genre lors des mises en service, et les trois mêmes règles s’appliquent aux cellules R-30iB, R-30iB Plus, CRX et LR Mate.

Cet article s’adresse aux techniciens et intégrateurs qui écrivent ou maintiennent des programmes TP devenus trop gros pour un seul script linéaire. Si vous déboguez une alarme liée spécifiquement à la propriété du contrôle du mouvement, l’article sur PROG-040 couvre ce mécanisme en détail.

Ce que cette erreur signifie vraiment

Il n’existe aucun code d’alarme FANUC unique qui signifie « votre programme TP est mal structuré ». Vous obtenez plutôt des symptômes en aval : INTP-105 lorsqu’une demande d’exécution échoue, PROG-040 lorsque deux tâches se disputent le contrôle du mouvement, et un comportement à l’exécution qui ne correspond pas au programme tel qu’il est écrit parce qu’un JMP LBL a sauté hors d’un bloc IF et a contourné le code de nettoyage.

Selon le manuel des codes d’erreur FANUC au sujet d’INTP-105 : « Échec de la demande d’exécution. Cause : le programme ne peut pas être démarré. Solution : consultez le code de cause de l’erreur. Utilisez MENU pour afficher l’écran du journal des alarmes. » C’est le contrôleur qui vous dit que la demande d’exécution a été refusée pour une raison que vous devez découvrir en lisant l’alarme suivante. Pour PROG-040, le manuel est plus explicite : « Le contrôle du mouvement pour le groupe spécifié a déjà été réservé par un autre programme. Solution : vérifiez les autres programmes en cours d’exécution pour déterminer lequel détient le contrôle du mouvement. »

La traduction en termes d’atelier : le TP possède de très bonnes structures de contrôle (CALL, IF/ELSE, SELECT, FOR/ENDFOR sur les versions plus récentes, plus Background Logic et Condition Monitor). Lorsque le code est forcé à passer par des JMP LBL parce que personne ne l’a décomposé en sous-programmes, vous vous retrouvez avec des bogues que le langage a été conçu pour prévenir.

Causes les plus fréquentes, par ordre de probabilité

1. JMP LBL qui traverse un bloc structuré. Sauter hors d’un bloc IF vers une étiquette située après le ENDIF laisse la pile dans un état que le TP n’attendait pas. Les micrologiciels récents le tolèrent, les anciennes révisions non, et dans les deux cas le programme est difficile à lire.
2. CALL sans chemin de retour propre. Un sous-programme qui « se termine » en enchaînant sur un autre programme ou en atteignant la fin du fichier au lieu de faire un retour. L’éditeur TP ne vous avertit pas (fil Reddit de référence sur la structure du code TP).
3. Parallélisme réalisé avec des CALL qui se chevauchent. Essayer d’exécuter le mouvement et la logique d’E/S « en même temps » en les appelant depuis des programmes différents. Vous obtenez PROG-040 dès que l’un d’eux a besoin du groupe de mouvement.
4. Un énorme script séquentiel. 600 lignes de mouvement avec le préhenseur, les déclenchements de vision et l’échange de signaux avec le convoyeur, tout en ligne. Chaque modification met en péril tous les autres comportements (fil Robot Crash sur la décomposition en sous-programmes).
5. Macros qui appellent de longues séquences de mouvement. Les macros sont conçues pour les boutons de panneau HMI (exécution unique, rapide). Lorsqu’une macro lance une séquence de mouvement de 60 secondes, vous obtenez des comportements étranges du fil d’exécution de l’interface et des pauses inattendues.

Comment diagnostiquer en moins de 10 minutes

Étape 1. Imprimez ou faites une capture d’écran de l’arbre d’appels. Ouvrez MAIN et dressez la liste de chaque CALL et de chaque cible de JMP LBL. Si cela ne tient pas sur une seule page, le programme doit être divisé.

Étape 2. Repérez INTP-105 dans le journal des alarmes et lisez le code de cause qui suit. Si la cause est PROG-040, vous avez un problème de propriété du mouvement (voir cet article). Si la cause est autre chose, elle vous indique exactement quelle ligne a échoué.

Étape 3. Vérifiez le masque de groupe (group mask) de chaque programme. MENU > SELECT > DETAIL. Les programmes qui ne touchent qu’aux E/S doivent avoir le masque de groupe *,*,*,*,* (aucun mouvement). Les programmes qui commandent le mouvement doivent avoir leur groupe de mouvement défini explicitement.

Étape 4. Cherchez les JMP LBL à l’intérieur des blocs IF/ENDIF, SELECT/ENDSELECT ou FOR/ENDFOR. Ce sont les cas propices aux bogues. La sortie prévue est un ELSE ou une interruption explicite, pas un saut vers l’extérieur.

Étape 5. Confirmez la configuration du BG Logic si quelque chose doit s’exécuter en parallèle. MENU > SETUP > BG Logic. La liste des tâches qui s’y trouve est ce que le contrôleur exécutera en parallèle avec le programme principal (Reddit sur le BG Logic pour le comportement en parallèle).

Comment corriger le problème

Pour un JMP LBL qui saute hors d’un bloc :

Remplacez-le par du TP structuré. Les modèles qui fonctionnent :

• Choix parmi plusieurs options : SELECT/ENDSELECT avec des cas explicites.
• Branchement à deux voies : IF cond THEN / ELSE / ENDIF.
• Sortie anticipée d’un sous-programme appelé par CALL : instruction END explicite au point de sortie.

JMP LBL convient à l’intérieur d’une courte section séquentielle. Il ne convient pas au contrôle du flux à l’échelle de tout le programme.

Pour un CALL sans RETURN :

Chaque sous-programme appelé devrait se terminer par END (qui revient au programme appelant). Atteindre la fin du fichier a le même effet sur les micrologiciels modernes, mais l’explicite vaut mieux que l’implicite. On a déjà vu d’anciens micrologiciels sauter le programme appelant prévu et exécuter quelque chose sans rapport lorsque le END est absent.

Pour le parallélisme (mouvement et E/S) :

Déplacez les E/S dans le Background Logic. Le BG Logic s’exécute indépendamment du fil de mouvement et n’a pas besoin du contrôle du mouvement. C’est le bon outil pour la surveillance des convoyeurs, l’activation des indicateurs d’alarme, la surveillance des boutons de panneau et la gestion des échanges de signaux avec l’automate. Un fil de robot-forum sur le même modèle documente exactement le cas d’une personne qui a essayé le BG Logic et a découvert quelles instructions n’y sont pas permises (référence).

Pour un énorme script :

Restructurez par étapes. Choisissez un bloc logique (ouverture/fermeture du préhenseur, prise au poste A, dépose au poste B). Déplacez-le dans un sous-programme nommé avec un nom court et clair (les noms de programmes TP sont limités à 36 caractères, prévoyez-le). Remplacez le code en ligne par un CALL. Testez un bloc à la fois. Recommencez. Après trois à cinq passes, le programme principal se lit comme une séquence d’opérations nommées et les bogues au milieu disparaissent.

Pour des macros qui commandent des séquences de mouvement :

Les macros devraient lancer un CALL vers un programme TP et revenir immédiatement. Elles ne devraient pas contenir le mouvement elles-mêmes. La macro reste ainsi rapide (elle s’exécute dans le fil de l’interface) et le mouvement se trouve là où il doit être (un programme TP ordinaire qui détient le contrôle du mouvement).

Pour un CRX avec la vue de programmation par blocs de la tablette :

L’interface par blocs est compilée en TP en arrière-plan. Les mêmes règles de structure s’appliquent. Vous pouvez passer à la vue de pendant classique (legacy) par les paramètres (Settings) pour lire et modifier le TP sous-jacent si un bloc a besoin d’une intervention que la vue tablette ne permet pas (fil Reddit sur le pendant tablette du CRX).

Quand faire appel à un spécialiste

Deux situations justifient un appel de service :

Vous avez un programme TP qui a grossi au-delà de ce qu’une seule personne peut garder en tête, et chaque modification cause des régressions. Un audit de programmation avec un arbre d’appels documenté et un programme principal restructuré représente une intervention d’une journée qui se rentabilise sur toute la durée de vie de la cellule.

Vous devez ajouter un comportement réellement parallèle (déclenchements de vision pendant le mouvement, suivi de convoyeur avec commande simultanée du préhenseur), et vous ne savez pas si le BG Logic, le Condition Monitor ou un utilitaire KAREL est le bon outil. Ce choix a des conséquences sur la performance et la sécurité, et le faire correctement du premier coup évite la chaîne PROG-040 / INTP-105.

Contactez-nous pour une revue de programmation, ou mettez en place un contrat de maintenance préventive afin que l’architecture TP soit vérifiée en même temps que l’entretien mécanique.

Erreurs connexes à vérifier

• PROG-040 Already locked by other task (déjà verrouillé par une autre tâche) : deux programmes de mouvement se disputent le même groupe. La conséquence la plus fréquente d’une mauvaise conception parallèle.
• INTP-105 Run request failed (échec de la demande d’exécution) : alarme externe. Toujours la lire avec le code de cause à la ligne suivante.
• SRVO-050 Collision Detect (détection de collision) : pas directement causée par la structure du programme, mais un programme mal décomposé qui réenseigne des points sans revérifier la charge utile peut la déclencher. Le fil Reddit « Srvo-050 » documente exactement ce scénario (référence).
• SYST-212 Need to apply to DCS param (paramètres DCS à appliquer) : apparaît après des modifications du mastering ou d’une sauvegarde. Pas structurel, mais fait souvent partie d’un effort de restructuration plus large.
• INTP-254 Parameter not found (paramètre introuvable) : indique qu’un paramètre auquel le code TP fait référence n’existe pas. Souvent un reste de copier-coller lors d’une restructuration.

Probot Systèmes est un intégrateur FANUC établi à Lévis (Québec) qui dessert le Canada et les États-Unis. La restructuration de programmes TP, la conception de BG Logic et l’intégration KAREL font partie de chaque cellule que nous livrons. Si le programme TP dont vous avez hérité vous résiste chaque fois que vous y touchez, cela vaut la peine de nous joindre.