[Dépannage OpenArm] La vérification de l'effecteur Z échoue après le déplacement de la table (intermédiaire)

Les vérifications Z échouent juste après le remontage de la table ? Distinguez le changement de géométrie de la cellule de travail de la dérive d'étalonnage du robot grâce à des tests axés sur les fixations.

Forum / Index des messages / Bras ouvert

Poste

Un problème pratique avec la cellule de travail OpenArm apparaît après le déplacement de la table, du dispositif ou de la plate-forme sous le robot. Le bras peut toujours rentrer correctement, mais une simple vérification de la hauteur Z échoue soudainement parce que la géométrie environnante a changé alors que vos hypothèses ne l'ont pas fait.

Comment diagnostiquez-vous les cas OpenArm où la vérification de la hauteur Z de l'effecteur final échoue après un déplacement de la table ?

Veuillez expliquer comment vous distinguez un environnement modifié d'un problème d'étalonnage côté robot, à quels appareils ou références vous faites le plus confiance et quand vous choisissez une mise à jour rapide de la cellule de travail plutôt qu'un recalibrage complet.

Si vous répondez, incluez un symptôme exact de vérification Z et une vérification exacte de l'espace de travail ou du luminaire qui a révélé le quart de travail.

Chemin de dépannage associé : Décalage du support de base et référence d'étalonnage obsolète · Le jogging fonctionne mais la hauteur de sélection est désactivée

Module : OpenArm · Public : constructeurs-intégrateurs · Type : question

Mots clés : bras ouvert, hauteur z, déplacement de table, cellule de travail

Commentaire 1

Contexte intermédiaire : Notre symptôme était cohérent : le home est passé, mais le touch-off Z sur le même luminaire est arrivé en bas de 1,4 mm après le déplacement de la table. XY semblait toujours raisonnable, ce qui permettait de le rater facilement au début.

Commentaire 2

Contexte intermédiaire : Ce qui l'a rapidement exposé, c'est un balayage d'un indicateur à cadran sur les coins de la plaque du luminaire. Nous avons mesuré une nette inclinaison introduite lors du remontage. Le problème était donc la géométrie de l'espace de travail et non la dérive de l'encodeur.

Commentaire 3

Contexte intermédiaire : Nous autorisons une récupération partielle uniquement si un ajustement plan en 4 points laisse moins de 0,25 mm de résidu et que le contrôle Z passe trois appareils. Sinon on refait le calibrage complet et les dégagements de collision avant de relâcher la cellule.

Commentaire 4

Suivi du contexte intermédiaire : Question complémentaire : après le remontage de la table, quelle était l'inclinaison de votre plan mesurée et votre seuil résiduel Z final accepté avant de lancer la production ?

Sélecteur rapide de symptômes

Choisissez votre symptôme le plus proche pour suivre le bon chemin de dépannage.

Pas encore sélectionné.

FAQ rapide

Comment séparer l'inclinaison de la table de la dérive d'étalonnage du robot ?

Utilisez un plan de fixation adapté aux coins et au centre ; une erreur de plan cohérente indique généralement un décalage de l’espace de travail.

python tools/fixture_plane_fit.py --fixture table_ref --points c1,c2,c3,center
python tools/z_touch_check.py --fixture all --trials 3
Quelle devrait être ma porte de déverrouillage ?

Utilisez les seuils de réussite résiduels + multi-appareils et confirmez à nouveau à chaud avant la libération.

Puis-je copier ces commandes telles quelles ?

Utilisez-les d’abord comme modèle de liste de contrôle. Confirmez les noms d’interface, les identifiants d’appareils et les conditions de sécurité dans votre propre cellule avant l’exécution.