FANUC PROG-040 Already locked by other task : pourquoi deux programmes ne peuvent pas posséder le même groupe de mouvement

Le cycle fonctionnait bien. Vous avez ajouté un petit sous-programme pour gérer le préhenseur, appuyé sur RUN, et le contrôleur affiche INTP-105 suivi de PROG-040 Already locked by other task (déjà verrouillé par une autre tâche). Rien ne bouge. Le correctif tient en une ligne de code TP, mais seulement si vous comprenez qui détient actuellement le contrôle du mouvement et pourquoi le contrôleur refuse de le confier à deux tâches à la fois. Chez Probot Systèmes, nous voyons ce cas chaque fois qu’un client tente d’ajouter un programme parallèle sans utiliser la Background Logic.

Cet article s’adresse aux techniciens et aux intégrateurs qui écrivent des programmes TP sur des contrôleurs R-30iB, R-30iB Plus et R-30iA Mate. La même alarme apparaît sur les cellules LR Mate avec la configuration de mouvement standard. Si vous avez plusieurs groupes de mouvement, les règles sont encore plus strictes ; cet article couvre le cas à un seul groupe, de loin le plus courant.

Ce que signifie réellement cette erreur

Chaque programme TP qui veut déplacer le robot doit réserver le contrôle du mouvement pour le groupe de mouvement qu’il utilise. Selon le manuel des codes d’erreur FANUC : « PROG-040 Already locked by other task. Cause : Le contrôle du mouvement pour le groupe spécifié a déjà été réservé par un autre programme. Solution : Vérifier les autres programmes en cours d’exécution pour déterminer lequel détient le contrôle du mouvement. »

L’alarme compagne INTP-105 est documentée juste à côté : « Run request failed. Cause : Le programme ne peut pas être démarré. Solution : Consulter le code de cause de l’erreur. » INTP-105 est l’alarme externe (la demande d’exécution a été refusée), PROG-040 est le code de cause (refusée parce que le groupe était déjà verrouillé).

En clair : deux programmes ne peuvent pas déplacer le robot en même temps. Si le programme A exécute du mouvement et que le programme B tente de démarrer avec un accès au mouvement, le programme B est bloqué avec PROG-040 jusqu’à ce que A libère le groupe ou se termine. C’est le contrôleur qui vous protège contre deux morceaux de code qui se disputent les mêmes articulations, exactement ce que doit faire un processeur de mouvement unique.

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

1. Deux programmes de mouvement appelés en parallèle. Le cas le plus fréquent. L’opérateur sélectionne MAIN, MAIN appelle SUB qui contient des instructions de mouvement, et quelque part SUB est aussi appelé depuis une macro ou un bouton d’interface. Le second appel échoue avec PROG-040 (fil de référence sur la même combinaison INTP-105 / PROG-040).
2. Sous-programme de préhenseur encore associé à un groupe de mouvement. Un programme qui ne fait que changer une sortie numérique devrait être configuré sans groupe de mouvement (masque de groupe *,*,*,*,* ou équivalent). Laissez-le sur le groupe 1 et le contrôleur le traite comme une tâche de mouvement qui veut le même groupe que le programme principal.
3. Éditeur TP ou WinTPE qui retient le programme. Un programme ouvert en édition dans WinTPE conserve un verrou logiciel. Les demandes d’exécution du même programme échouent jusqu’à la fin de la session d’édition.
4. Background Logic mal configurée comme tâche de mouvement. Les débutants tentent parfois de faire exécuter des lignes de mouvement par un programme BG Logic. BG Logic ne détient pas le contrôle du mouvement ; quand la ligne tente de s’exécuter, elle échoue de la même façon.
5. FCTN > END EDIT non effectué après l’enseignement. Un pendant laissé en cours d’édition retient le programme. L’opérateur appuie sur RUN depuis un terminal distant et le contrôleur refuse.

Comment diagnostiquer en moins de 10 minutes

Étape 1. Lisez les deux alarmes dans le journal. INTP-105 devrait se trouver au-dessus de PROG-040. Cet ordre vous indique qu’il s’agit d’une demande d’exécution qui a échoué, et non d’un mouvement déjà en cours.

Étape 2. Ouvrez la liste des tâches en cours sous MENU > SELECT > F1 [TYPE] > Status. Cherchez tout programme à l’état PAUSED ou RUNNING. Celui qui détient le contrôle du mouvement est celui qui a un groupe de mouvement dans son en-tête et un statut non terminé.

Étape 3. Appuyez sur FCTN > 4 ABORT (ALL) pour tout arrêter proprement. Si PROG-040 disparaît ensuite, c’est qu’une tâche en pause traînait et retenait le groupe.

Étape 4. Vérifiez le masque de groupe du programme fautif. MENU > SELECT, sélectionnez le programme, appuyez sur DETAIL et regardez la ligne Group Mask. Si un programme qui ne gère que le préhenseur affiche 1,*,*,*,* au lieu de *,*,*,*,*, voilà votre problème (fil de la communauté DIY Robotics documentant le correctif du préhenseur sans groupe de mouvement).

Étape 5. Confirmez qu’aucune session WinTPE ou ROBOGUIDE n’est connectée. Ouvrez le menu d’état du réseau, ou fermez simplement tout outil PC qui communique avec l’armoire.

Comment corriger le problème

Pour le cas le plus courant (sous-programme de préhenseur ou d’E/S défini comme tâche de mouvement) :

1. MENU > SELECT, naviguez jusqu’au programme fautif.
2. Appuyez sur DETAIL.
3. Changez le Group Mask de 1,*,*,*,* à *,*,*,*,* (aucun groupe de mouvement requis).
4. Enregistrez et relancez.

Le programme devient ainsi une tâche purement logique, et le contrôleur le laissera s’exécuter en parallèle avec le programme de mouvement sans contester le groupe.

Pour deux programmes de mouvement qui doivent réellement tous deux déplacer le robot :

Vous devez les sérialiser. Utilisez un seul programme principal qui appelle chaque sous-routine de mouvement dans l’ordre, au lieu de tenter de les lancer par deux demandes d’exécution. Le langage TP prend en charge les chaînes de CALL précisément pour cela. Si vous avez besoin d’un comportement parallèle avec des E/S, utilisez la Background Logic. Si vous avez besoin de mouvement parallèle (impossible sur un seul groupe de mouvement), il vous faut une configuration à deux bras ou un deuxième robot.

Pour un verrou WinTPE / ROBOGUIDE bloqué :

Déconnectez l’outil PC. Si le verrou persiste, faites un Controlled Start (démarrage en maintenant PREV+NEXT). Cela efface l’état en mémoire sans perdre les programmes. Un Cold Start est excessif dans ce scénario et comporte plus de risques qu’il ne règle de problèmes.

Pour un problème d’UNLOCK_GROUP en KAREL ou en TP avancé :

PROG-040 a des cousines (PROG-041 à PROG-043) qui se déclenchent lorsque la machine à états du groupe est mal utilisée. Si un programme KAREL appelle LOCK_GROUP puis se termine sans UNLOCK_GROUP, le groupe reste verrouillé jusqu’au prochain cycle d’alimentation. C’est rare en code TP pur, mais fréquent lorsque du KAREL est ajouté par la suite. Les fils robot-forum et DIY Robotics mentionnés plus haut présentent la bonne façon de faire.

Quand faire appel à un spécialiste

Deux situations justifient un appel :

L’alarme apparaît de façon intermittente et vous n’arrivez pas à déterminer quel programme détient le verrou. Cela signifie habituellement qu’une macro ou une tâche d’arrière-plan appelle quelque chose au mauvais moment, et la retracer exige de lire ensemble l’arbre d’appels, la configuration BG Logic et la table des macros. Nous le faisons couramment dans le cadre d’un audit de programmation.

Vous mettez en service une cellule avec plusieurs groupes de mouvement (robot plus positionneur servo, robot plus rail), et le mouvement est demandé par des séquences pilotées par l’automate d’une façon qui produit des PROG-040 intermittents. Le contrôle du mouvement multigroupe exige un modèle de propriété clair, documenté dès le départ, et la plupart des cellules que nous visitons n’en ont pas.

Contactez-nous pour une revue de programmation, ou mettez en place un contrat d’entretien préventif afin que les masques de groupe et la configuration BG Logic soient vérifiés en même temps que l’entretien mécanique.

Erreurs connexes à vérifier

• INTP-105 Run request failed : l’alarme externe. Lisez-la toujours avec le code de cause qui suit.
• PROG-039 Could not get mctl : la demande a été faite, mais le contrôle du mouvement n’était pas disponible. Même famille, formulation légèrement différente.
• PROG-041 mctl denied because released : le contrôle du mouvement est détenu par le teach pendant. Désactivez l’activation du TP et réessayez.
• PROG-042 Already released : tentative de libérer un contrôle du mouvement qui n’a jamais été détenu. Habituellement un bogue de programmation.
• PROG-043 Already released by you : le programme a déjà libéré le groupe plus tôt et le libère de nouveau. Erreur de logique.

Probot Systèmes est un intégrateur FANUC établi à Lévis (Québec) qui dessert le Canada et les États-Unis. L’architecture TP multiprogramme, la BG Logic et l’intégration KAREL font partie de chaque cellule que nous livrons. Si PROG-040 revient sans cesse sur votre ligne et que vous n’arrivez pas à retracer quelle tâche verrouille le groupe, c’est le moment de nous joindre.