FANUC MOTN-074 (G:1) : vitesse hors plage, échecs de calibration iRVision et repères incompatibles

Vous lancez une calibration iRVision 2D sur un LR Mate 200iD monté sur un Education Cert Cart, la caméra parcourt la grille, et le programme tombe avec MOTN-074 (G:1). Ou encore vous exécutez un programme hors ligne fraîchement chargé depuis RoboGuide et la même alarme surgit sur un mouvement linéaire qui passait sans problème en simulation. Cellules différentes, programmes différents, même code. MOTN-074, c’est le contrôleur qui vous dit qu’une valeur de vitesse est hors limites, mais la façon dont l’alarme se manifeste dépend entièrement de la valeur de vitesse que le programme a tenté d’imposer. Chez Probot Systèmes, nous la voyons surtout sur des installations iRVision et sur des programmes hors ligne chargés sur une variante de cellule différente de celle pour laquelle ils ont été écrits.

Cet article s’adresse aux techniciens et aux intégrateurs aux prises avec MOTN-074 sur des armoires R-30iB Plus utilisant iRVision 2D, des programmes de palettisation importés de RoboGuide, ou tout programme TP utilisant les instructions SPEED, SPEEDLIM ou ROTSPEED.

Ce que signifie réellement cette erreur

MOTN-074 est l’alarme de plage de vitesse. Le manuel des codes d’erreur FANUC, à la page 873, est précis : « MOTN-074 Error in speed (G:%d^2) Cause : La vitesse n’est pas comprise entre 0 et $speedlim. Solution : Régler la vitesse entre 0 et $speedlim. » Les deux entrées suivantes de la même page (MOTN-075 pour rotspeed et MOTN-076 pour contaxisvel) complètent la famille. Chacune vise une variable différente, mais la règle est la même : le programme a demandé une valeur de vitesse que le contrôleur refuse de lui accorder.

Concrètement, le contrôleur possède une variable $SPEEDLIM qui plafonne la vitesse linéaire qu’un programme peut demander. Les routines de calibration iRVision et les programmes générés hors ligne écrivent parfois des valeurs de vitesse directement. Si ces valeurs dépassent $SPEEDLIM, MOTN-074 se déclenche avant que le mouvement commence. Les techniciens sur le terrain interprètent souvent l’alarme à tort comme un problème de portée de l’espace de travail (parce que « G:1 » a l’air géométrique), mais la cause réelle se trouve dans la valeur de vitesse, pas dans la géométrie. Cette distinction compte, parce que chaque quart d’heure passé sur les repères et les limites d’articulation est un quart d’heure de moins passé sur la ligne qui a écrit la mauvaise vitesse.

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

Par ordre de fréquence selon nos interventions :

1. La vitesse de calibration de la caméra iRVision dépasse $SPEEDLIM. Le mouvement de calibration par défaut écrit des valeurs de vitesse correctes sur une cellule fraîchement mise en service, mais sur une cellule où $SPEEDLIM a été resserré (souvent pour des applications collaboratives ou de peinture), la calibration déclenche MOTN-074. Le fil DIY Robotics sur cet échec précis le signale sur un Education Cert Cart utilisant iRVision 2D (fil de référence). Le fil Robot-Forum sur le même échec pointe la même ligne (fil robot-forum).
2. Programme hors ligne avec une vitesse codée en dur supérieure à $SPEEDLIM. Les cellules RoboGuide fonctionnent souvent avec des valeurs de $SPEEDLIM permissives. Lorsque le fichier TP est chargé sur une cellule réelle dont la limite est plus serrée, la première instruction de vitesse déclenche MOTN-074. C’est la surprise hors ligne-vers-réel la plus fréquente que nous voyons lors de mises en service.
3. Incompatibilité d’UFRAME ou d’UTOOL qui rend un mouvement linéaire apparemment inatteignable. Moins directement lié au texte sur la vitesse, mais les opérateurs voient souvent MOTN-074 juste après qu’une incompatibilité de repère a corrompu la trajectoire. À revérifier lorsque l’alarme coïncide avec un changement de repère.
4. Registre de vitesse réglé par programme hors de la plage. Les programmes qui calculent la vitesse à l’exécution (R[n] = QUELQUE_CHOSE) peuvent écrire des valeurs hors de la plage 0 à $SPEEDLIM si le calcul tourne mal. MOTN-074 se déclenche la prochaine fois que le contrôleur tente d’utiliser cette valeur.
5. Corruption de variable système après un Controlled Start. Rare, mais réel. Un Controlled Start bâclé peut laisser $SPEEDLIM à zéro, et n’importe quelle vitesse déclenchera alors MOTN-074. À vérifier si l’alarme apparaît dans plusieurs programmes sans lien entre eux au cours de la même journée.

Comment diagnostiquer en moins de 10 minutes

Étape 1. Notez le groupe : MOTN-074 (G:1). Allez ensuite directement à la ligne de programme qui a déclenché l’alarme. L’historique des alarmes nomme la ligne si vous le consultez immédiatement.

Étape 2. Lisez la valeur de vitesse sur cette ligne. S’il s’agit d’une constante (p. ex. 250 mm/s), vérifiez $SPEEDLIM. S’il s’agit d’un registre (R[n]), affichez le registre et vérifiez sa valeur actuelle.

Étape 3. Ouvrez MENU > SYSTEM > Variables, trouvez $SPEEDLIM et lisez sa valeur actuelle. Comparez-la à la vitesse que le programme tente d’imposer.

Étape 4. Dans le cas d’une calibration iRVision : le programme de calibration règle lui-même la vitesse. Si $SPEEDLIM est plus serré que la valeur par défaut d’iRVision, la calibration échouera à chaque fois. Le fil DIY Robotics documente ce piège sur l’Education Cert Cart (référence du forum).

Étape 5. Dans le cas d’un programme chargé hors ligne : confirmez que le $SPEEDLIM de la cellule en production correspond à celui de la cellule RoboGuide. Un $SPEEDLIM différent entre RoboGuide et le contrôleur réel est la cause dominante lors des mises en service.

Étape 6. Si $SPEEDLIM affiche zéro ou une valeur absurde : un Controlled Start a mal tourné quelque part. Restaurez une sauvegarde reconnue bonne avant de continuer.

Comment corriger le problème

Le correctif dépend du chemin par lequel vous êtes arrivé.

Si la calibration iRVision échoue : ouvrez temporairement $SPEEDLIM, lancez la calibration, puis remettez $SPEEDLIM à sa valeur de production. Ou encore, modifiez le mouvement de calibration iRVision pour utiliser une vitesse comprise dans le $SPEEDLIM de la cellule. Le fil Robot-Forum sur l’échec de calibration de l’Education Cert Cart aboutit à la même approche (fil robot-forum).

Si un programme hors ligne demande une vitesse trop élevée : abaissez la vitesse dans le fichier TP pour qu’elle respecte $SPEEDLIM. N’augmentez pas $SPEEDLIM sur une cellule de production sans revue d’ingénierie. La limite existe pour des raisons de sécurité et pour des raisons propres à l’application (limites de vitesse collaborative, vitesse d’application de peinture, synchronisation avec un convoyeur).

Si un registre de vitesse calculé par programme sort de la plage : bornez la valeur dans le code avec une vérification MIN avant de l’affecter à une instruction SPEED. R[n] = (R[m] > $SPEEDLIM) ? $SPEEDLIM : R[m] en langage TP.

Si $SPEEDLIM est corrompu : restaurez une sauvegarde. Ne modifiez pas $SPEEDLIM à la main sans avoir confirmé la valeur de production. Le fil DIY Robotics sur cette alarme amorce justement la discussion autour des valeurs de vitesse pour cette raison (référence du forum).

Une remarque qui piège les techniciens : MOTN-074 est parfois décrite de façon informelle sur les forums comme une alarme « position non atteignable ». Le manuel officiel, à la page 873, est clair : il s’agit d’une alarme de plage de vitesse. Si vous la traitez comme un problème de repère ou d’espace de travail, vous perdrez un après-midi sur le mauvais diagnostic. Lisez d’abord les valeurs de vitesse du programme.

Quand faire appel à un spécialiste

Appelez-nous lorsque $SPEEDLIM semble correct, que les valeurs de vitesse du programme sont dans la plage, que la calibration iRVision est configurée selon la procédure FANUC et que MOTN-074 se déclenche quand même. À ce stade, il faut examiner l’intégrité des variables système, l’état de l’image du contrôleur ou un problème plus profond de configuration iRVision, autant de questions plus faciles à régler avec un plan de sauvegarde et de restauration en place.

Même chose lorsque vous mettez en service une cellule avec un programme hors ligne d’un intégrateur précédent et que les limites de vitesse ne concordent pas. Nous faisons l’audit, documentons le $SPEEDLIM de production et mettons à jour la source hors ligne pour que la prochaine régénération sorte propre.

Contactez-nous pour une mise en service ou un appel de service, ou mettez en place un contrat d’entretien préventif afin que $SPEEDLIM et les configurations iRVision soient documentés avant la livraison d’un nouveau programme.

Erreurs connexes à vérifier

• MOTN-075 Error in rotspeed : même famille, pour la vitesse de rotation. Se déclenche sur les programmes qui règlent la vitesse de rotation du poignet au-dessus de $ROTSPEEDLIM.
• MOTN-076 Error in contaxisvel : vitesse d’axe continu hors plage. Même famille, variable différente.
• MOTN-017 Limit error : la véritable alarme de limite de l’espace de travail. Si un fil de forum laisse entendre que MOTN-074 est un problème de position, c’est probablement MOTN-017 qu’on voulait dire.

Probot Systèmes est un intégrateur FANUC établi à Lévis (Québec). Nous mettons en service et entretenons des palettiseurs, des robots de soudage et des cellules de vision partout au Canada et aux États-Unis, et nous savons quels pièges MOTN-074 attrapent les nouveaux utilisateurs d’iRVision et lesquels attrapent les techniciens expérimentés qui chargent des programmes hors ligne. Si votre calibration iRVision déclenche sans cesse MOTN-074, c’est le moment de nous joindre.