FANUC ROBOGUIDE vs robot réel : pourquoi la simulation roule sans faute et la cellule, non

La simulation ROBOGUIDE exécute le cycle complet sans le moindre accroc. Vous transférez les programmes par FTP au robot réel, vous déplacez le robot jusqu’à la première position enseignée, et le poignet est décalé de 35 mm et de 8 degrés par rapport à sa position attendue. Ou encore, le programme se charge, mais le contrôleur affiche PROG-040 dès qu’il démarre. ROBOGUIDE est un bon outil, mais seulement lorsque la cellule virtuelle est le reflet fidèle de la cellule réelle. Chez Probot Systèmes, nous l’utilisons tous les jours pour la programmation hors ligne de palettiseurs, et presque tous les problèmes que nous dépannons dans les cellules de nos clients se ramènent à un seul écart entre la simulation et l’atelier.

Cet article s’adresse aux techniciens et intégrateurs qui utilisent ROBOGUIDE pour programmer des robots FANUC hors ligne (R-30iB, R-30iB Plus, avec des bras M-10iD, R-2000iA ou similaires dans la cellule). Les mêmes règles s’appliquent si vous simulez sur un contrôleur virtuel et déployez sur un CRX ; les particularités propres au CRX sont notées à la fin.

Ce que cette erreur signifie vraiment

Il n’existe aucune alarme FANUC unique qui dit « votre cellule ROBOGUIDE ne correspond pas à la cellule réelle ». Vous obtenez plutôt une chaîne de symptômes en aval : des décalages de position au chargement des programmes, PROG-040 lorsqu’une sauvegarde est importée avec des groupes de mouvement en conflit, SYST-212 Need to apply to DCS param (paramètres DCS à appliquer) lorsque les paramètres DCS de la sauvegarde ne correspondent pas au contrôleur en service, et de la confusion visuelle dans la simulation lorsque l’orientation de montage diffère de la réalité.

Selon le manuel des codes d’erreur FANUC au sujet de PROG-040 : « 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. » Lorsque cette alarme survient immédiatement après un déploiement depuis ROBOGUIDE, le programme importé fait référence à une configuration de groupes de mouvement qui ne correspond pas à la cellule réelle.

En termes d’atelier : ROBOGUIDE simule fidèlement la mécanique du robot, mais la simulation n’est valide que si le contrôleur virtuel a la même version logicielle, le même fichier d’options, les mêmes définitions UFRAME/UTOOL et la même orientation de montage que le robot réel. Si un seul de ces quatre éléments manque, la simulation vous montre un robot différent de celui qui est sur votre plancher.

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

1. Fichier d’options (order file) non synchronisé. Le contrôleur virtuel dans ROBOGUIDE a été créé à partir d’un gabarit, alors que le contrôleur réel possède un fichier d’options précis avec sa propre combinaison d’options. Des programmes qui fonctionnent en simulation font appel à des options que le robot réel n’a pas. Le fil Reddit « new install » sur les techniciens ASI FANUC qui utilisent ROBOGUIDE signale que c’est la première chose à vérifier (référence).
2. Écart d’UFRAME ou d’UTOOL. La disposition de la cellule dans ROBOGUIDE définit un UFRAME 1, alors que le robot réel a un UFRAME 1 différent, ou n’en a aucun. Les programmes font référence à l’UFRAME 1 dans leurs en-têtes de mouvement, et les positions obtenues aboutissent au mauvais endroit.
3. Orientation de montage différente ($WORLD_FRAME). Le robot virtuel est monté au sol, alors que le robot réel est monté au mur ou à l’envers. Les mouvements cartésiens pivotent selon la référence de gravité, et vous obtenez une dérive de l’orientation du poignet.
4. Sauvegarde chargée à partir d’un autre modèle. L’utilisateur a copié le SYSVARS.SV d’un robot semblable, mais pas identique, et l’extension cinématique est absente sur le nouveau robot. ROBOGUIDE peut afficher la simulation correctement, alors que le contrôleur réel affiche SYST-212 ou SYST-218.
5. Se fier au Virtual TP pour valider le temps de cycle. Le Virtual TP de ROBOGUIDE convient au débogage de la logique, pas à la validation des vitesses de production. Le fil Reddit « PALLETTOOL HATRED » est d’une franchise brutale au sujet de RoboGuide comme outil de chronométrage purement par simulation (référence).

Comment diagnostiquer en moins de 10 minutes

Étape 1. Récupérez le fichier d’options du robot réel. MENU > STATUS > Version ID > F1 [ORDER FILE], puis F4 BACKUP vers une clé USB. Vous obtenez ainsi un fichier .dat contenant l’ensemble exact des options.

Étape 2. Dans ROBOGUIDE, ouvrez les propriétés du contrôleur virtuel de la cellule. Comparez la version logicielle (V9.40, V9.50, etc.) et les options chargées avec le fichier d’options. Elles doivent correspondre au niveau majeur.mineur et au nombre d’options.

Étape 3. Comparez les UFRAME et UTOOL. Sur le robot réel, MENU > SETUP > Frames énumère chaque repère défini avec ses valeurs X, Y, Z, W, P, R. Dans ROBOGUIDE, ouvrez les propriétés des repères de la cellule. Le repère 1 doit être égal au repère 1 du robot réel, valeur par valeur.

Étape 4. Vérifiez l’orientation de montage. Sur le robot réel, consultez $WORLD_FRAME sous SYSVARS ou sous MENU > SETUP > General. L’angle de montage détermine la façon dont la gravité est appliquée. Le robot virtuel dans ROBOGUIDE doit avoir le même montage.

Étape 5. Si vous obtenez des erreurs RGCUserFrame à l’ouverture de la cellule, il s’agit d’un problème d’importation du côté de ROBOGUIDE, et non d’un problème du robot réel. Un fil de la communauté DIY Robotics documente exactement ce cas, où SynchronizeWithController échoue lorsque les repères ne sont pas cohérents (référence).

Comment corriger le problème

Pour un écart de fichier d’options :

Exportez le fichier d’options du robot réel et importez-le dans ROBOGUIDE lorsque vous créez le contrôleur virtuel. Ne partez pas d’un gabarit si vous avez une cellule réelle à reproduire. La fonction « Create Workcell from Backup » de ROBOGUIDE prend une sauvegarde complète du contrôleur (fichier .IMG) et reproduit automatiquement l’ensemble des options, les variables système et même les repères enregistrés.

Pour un écart d’UFRAME / UTOOL :

Saisissez manuellement chaque valeur de repère des deux côtés jusqu’à ce qu’elles correspondent, ou exportez USERFRAME.VR / USERTOOL.VR du robot réel et importez-les dans la cellule ROBOGUIDE. La méthode des points de correspondance décrite dans le fil DIY Robotics sur l’étalonnage est la façon systématique de procéder (référence).

Pour un robot monté au mur ou au plafond :

Dans ROBOGUIDE : sélectionnez le robot dans l’arborescence de la cellule, ouvrez Properties, allez à General > Mount Orientation et choisissez le montage qui correspond à votre installation. Sur le robot réel : confirmez $WORLD_FRAME et l’angle de montage dans la configuration. La simulation et le robot réel concorderont alors sur les mouvements cartésiens.

Pour une sauvegarde chargée à partir d’un autre modèle :

Ne déployez pas cette sauvegarde. N’utilisez la sauvegarde du robot source que sur un modèle identique. Si vous devez réellement migrer de la logique d’un robot à un autre, copiez les fichiers .TP un par un après avoir vérifié les repères, les charges utiles et les groupes de mouvement sur le robot de destination. La restauration en bloc est un piège.

Pour une installation de ROBOGUIDE qui affiche des codes d’exception au démarrage :

Il s’agit d’un problème d’installation Windows + .NET + RoboGuide, et non d’un problème de cellule. Le fil de la communauté DIY Robotics sur les codes d’exception de Roboguide V9 Rev N documente les méthodes de réparation propres à chaque version (référence). Un deuxième fil semblable traite plus largement des codes d’exception à l’installation (référence).

Pour la validation en production :

Même avec une cellule parfaitement reproduite, exécutez toujours le premier cycle sur le robot réel avec une surcharge de vitesse (override) de 10 à 25 pour cent. Les temps du Virtual TP sont approximatifs. Les profils d’accélération et de décélération, les limites de vitesse articulaire à surcharge élevée et le comportement aux singularités doivent tous être vérifiés sur le bras réel.

Pour le CRX en particulier :

ROBOGUIDE prend en charge le CRX, mais ce n’est pas l’interface de programmation par blocs de la tablette que vous simulez. Vous écrivez du code TP dans ROBOGUIDE et le CRX l’accepte par la vue de pendant classique (legacy). Un utilisateur Reddit a indiqué qu’il programme dans le pendant classique dans ROBOGUIDE et passe à la tablette sur le robot réel (référence).

Quand faire appel à un spécialiste

Deux situations justifient un appel de service :

Vous déployez une cellule complète hors ligne (palettiseur, prise et dépose multistation, guidage par vision) et vous avez besoin que ROBOGUIDE corresponde à la cellule réelle à l’intérieur de la tolérance de position attendue par le client. L’étalonnage entre la simulation et la réalité exige une méthode rigoureuse, avec des transferts de repères documentés, une vérification du mastering et des cycles d’essai sur le robot à surcharge de vitesse croissante.

Vous voyez SYST-212 ou SYST-218 après le déploiement d’une sauvegarde issue de ROBOGUIDE sur un CRX ou un robot équipé de DCS. Les paramètres DCS de la sauvegarde ne correspondent pas au CPU de sécurité en service, et vous devez savoir s’il faut faire APPLY (la modification est voulue) ou revenir en arrière (la sauvegarde ne convient pas à ce robot).

Contactez-nous pour de la programmation hors ligne, ou planifiez une visite de maintenance préventive afin que la cellule ROBOGUIDE reste synchronisée avec le robot réel au fil des mises à niveau du micrologiciel.

Erreurs connexes à vérifier

• PROG-040 Already locked by other task (déjà verrouillé par une autre tâche) : le programme importé fait référence à un groupe de mouvement qui entre en conflit avec la configuration du robot réel.
• SYST-212 Need to apply to DCS param : modification du mastering ou de paramètres provenant d’une sauvegarde, que le DCS considère comme non appliquée. Fréquent après le déploiement d’une sauvegarde ROBOGUIDE sur un robot équipé de DCS.
• SYST-218 DCS Unavailable robot model (modèle de robot non disponible) : la sauvegarde provient d’un autre modèle. Arrêtez-vous, n’appuyez pas sur APPLY.
• INTP-105 Run request failed (échec de la demande d’exécution) : le code de cause à la ligne suivante vous indique le vrai problème. Il renvoie souvent à un écart de repère ou d’option.

Probot Systèmes est un intégrateur FANUC établi à Lévis (Québec) qui dessert le Canada et les États-Unis. Nous utilisons ROBOGUIDE tous les jours pour la programmation de palettiseurs et la mise à niveau de cellules de clients, et la méthode décrite ci-dessus est celle que nous appliquons à chaque nouvelle cellule. Si votre simulation et votre robot réel ne concordent pas, cela vaut la peine de nous joindre avant le premier lot de production.