FANUC PRIO-620 PNIO(C) station deactivated : diagnostiquer un esclave PROFINET perdu sans démonter l’armoire

L’automate de la ligne cesse d’envoyer la commande d’ouverture de la pince, le robot reste immobile à sa position d’origine, et la seule chose qui apparaît dans l’historique des alarmes est PRIO-620 PNIO(C) station 202 deactivated (station PNIO(C) 202 désactivée). Le voyant du bus de terrain sur l’armoire est vert fixe. Tout semble normal, jusqu’à ce que vous réalisiez qu’un nœud esclave s’est éteint et que le contrôleur PNIO a cessé de l’interroger. Nous voyons ce cas sur les armoires R-30iB et R-30iB Plus chaque fois qu’un client ajoute un nouveau bloc d’E/S à un segment PROFINET existant sans refaire proprement la configuration du réseau.

Cet article s’adresse aux techniciens qui intègrent des robots FANUC en PROFINET IO. L’erreur s’applique chaque fois que le robot est le PNIO Controller (le maître), ce qui est la configuration par défaut pour les cellules qui apportent leurs propres E/S déportées.

Ce que cette erreur signifie vraiment

PRIO-620 est générée par la pile PROFINET du contrôleur FANUC lorsqu’un appareil esclave qui communiquait jusque-là devient muet. Selon le manuel des codes d’erreur FANUC : « PRIO-620 PNIO(C) station %d deactivated. Cause : l’appareil dont le réglage Show error when deactivated est à ON est désactivé. Solution : vérifier la station correspondant au numéro de station indiqué et l’activer. »

Le %d est le numéro de la station que FANUC tente de joindre. Sur le plancher, ça se traduit ainsi : le contrôleur a interrogé la station 202 (ou le numéro qu’affiche l’alarme), n’a reçu aucune réponse dans le délai du watchdog et a affiché PRIO-620. Le bus lui-même fonctionne toujours ; un seul esclave a décroché. C’est le réglage « Show error when deactivated » qui rend la chose visible. Dans une configuration minimale, l’esclave deviendrait simplement muet sans déclencher d’alarme.

PRIO-620 fait partie d’une famille qui comprend PRIO-621 I/O Device is not running (l’I/O Device ne fonctionne pas), PRIO-622 I/O Controller is not running (l’I/O Controller ne fonctionne pas) et PRIO-623 I/O Controller not in OPERATION mode (l’I/O Controller n’est pas en mode OPERATION). Elles se ressemblent dans l’historique, mais elles touchent des couches différentes de la pile. PRIO-620 est la plus fréquente parce qu’elle correspond à la perte d’un seul esclave, ce qui arrive quand un câble est arraché ou qu’un bloc déporté perd son alimentation.

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

1. Perte d’alimentation du bloc d’E/S déporté. L’esclave est hors tension, pas inaccessible. Vérifiez le voyant d’alimentation 24 V du bloc d’E/S avant toute chose.
2. Câble de raccordement endommagé entre deux esclaves. Le PROFINET est câblé en guirlande (daisy-chain). Un mauvais câble entre l’esclave N et l’esclave N+1 met hors service N+1 et tout ce qui suit, et vous obtenez PRIO-620 avec le numéro de station du premier appareil qui s’est éteint.
3. Adresse IP de l’esclave incorrecte après un remplacement. Un bloc d’E/S a été remplacé, mais personne ne lui a attribué la même adresse IP et le même nom d’appareil. Le nouveau bloc démarre en DCP et ne s’associe jamais au contrôleur PNIO FANUC.
4. Dépassement du watchdog sur un bus chargé. Rare, mais possible. Un segment très chargé avec un câble limite peut dépasser le délai par intermittence, et l’historique montre la même station qui se désactive et se réactive.
5. Dérive de configuration. Quelqu’un a ajouté ou retiré un esclave dans TIA Portal ou dans la configuration FANUC, et la configuration active du contrôleur ne correspond plus à ce qui se trouve sur le bus (discussion de référence sur la capture de PRIO-620).

Comment diagnostiquer en moins de 10 minutes

Étape 1. Lisez le numéro de station dans le texte de l’alarme : PRIO-620 PNIO(C) station 202 deactivated. C’est l’appareil que FANUC cherche. Comparez-le à votre plan d’E/S.

Étape 2. Allez voir l’esclave. Regardez le voyant d’alimentation, le voyant BF (bus fault, défaut de bus) et le voyant SF (system fault, défaut système). Un appareil complètement hors tension n’affiche aucun voyant. Un appareil alimenté, mais sans communication sur le bus, affiche un SF fixe et un BF qui clignote.

Étape 3. Vérifiez le câble en amont. Le câblage PROFINET est en guirlande : le câble qui alimente l’esclave désactivé est donc le segment entre l’appareil précédent et celui-ci. Les serre-câbles RJ45 endommagés sont, de loin, le défaut physique le plus fréquent.

Étape 4. Ouvrez MENU > I/O > PROFINET sur le pendant d’apprentissage FANUC. Les esclaves devraient y être listés avec leur numéro de station et un indicateur actif/inactif. Repérez ceux qui sont en rouge.

Étape 5. Si vous devez capter PRIO-620 dans un programme TP pour la logique d’échange avec l’automate, l’err_num à surveiller dépend de la version du contrôleur. Une discussion de robot-forum portant exactement sur cette question documente la syntaxe de Condition Monitor à utiliser (err_num for PRIO-620). Une autre discussion traite de la même alarme, spécifiquement pour les cas « PNIO station 202 deactivated » (how to capture error PRIO-620 PNIO station 202 deactivated).

Comment corriger le problème

Pour un esclave qui a perdu son alimentation :

Rétablissez l’alimentation et attendez que l’appareil démarre. L’alarme devrait s’effacer d’elle-même une fois que le contrôleur PNIO a rétabli la connexion cyclique. Si elle n’est pas effacée après 30 secondes, appuyez sur RESET sur le pendant d’apprentissage.

Pour un câble défectueux :

Remplacez-le. Sertir un nouveau connecteur RJ45 sur place convient pour un essai, mais la solution permanente est un câble de raccordement avec serre-câble, homologué pour le PROFINET. Si le câble passe dans une chaîne porte-câbles, utilisez un câble PROFINET industriel conçu pour les flexions répétées (habituellement avec des connecteurs M12 à codage D). Les câbles de raccordement CAT5e de bureau ne conviennent pas.

Pour un esclave remplacé avec la mauvaise adresse IP ou le mauvais nom d’appareil :

Utilisez PRONETA ou un balayage des appareils accessibles dans TIA Portal pour trouver l’esclave, puis attribuez-lui le nom d’appareil et l’adresse IP qu’attend la configuration FANUC. Le contrôleur FANUC n’acceptera pas un esclave portant un autre nom, même si l’adresse IP est la bonne : le nom d’appareil est l’identité PROFINET.

Pour une dérive de configuration :

Exportez la configuration active à partir du pendant d’apprentissage FANUC, comparez-la ligne par ligne avec la configuration prévue dans l’outil d’ingénierie, et réconciliez les deux. Si la configuration prévue est bonne et que la configuration active est erronée, rechargez-la à partir de l’outil d’ingénierie. Si la configuration active est bonne et que la configuration prévue est erronée, corrigez d’abord l’outil d’ingénierie pour que le prochain téléchargement ne brise pas la cellule en production.

Si vous voulez que PRIO-620 active un indicateur d’alarme dans l’automate plutôt que de rester dans l’historique FANUC, configurez un Condition Monitor ou un programme BG Logic qui surveille le numéro d’erreur et pilote une sortie UO. Les discussions de forum ci-dessus montrent la syntaxe exacte. Câblez cette UO vers l’automate et vous pourrez acheminer l’alarme jusqu’à l’IHM de la ligne.

Quand faire appel à un spécialiste

Deux situations justifient un appel :

PRIO-620 revient toutes les quelques heures avec le même numéro de station, mais l’esclave est physiquement en bon état et le câble passe les tests. C’est habituellement une terminaison de câble limite ou un problème de pile du contrôleur PNIO qui demande un examen au niveau du firmware. Nous l’avons vu sur des armoires R-30iB dotées d’anciennes révisions du firmware PROFINET, où une mise à jour vers une révision Plus a réglé le problème.

Vous construisez une nouvelle cellule et vous voulez que l’automate réagisse quand le contrôleur FANUC perd un esclave (refuser d’envoyer le prochain départ de cycle, passer en mode dégradé, etc.). Câbler correctement cet échange demande la technique de l’err_num décrite plus haut ainsi qu’une séquence documentée dans l’automate, et ça vaut la peine de bien le faire du premier coup.

Contactez-nous pour une intégration PROFINET, ou planifiez une visite de maintenance préventive afin que l’état du bus soit vérifié en même temps que l’entretien mécanique.

Erreurs connexes à vérifier

• PRIO-621 PNIO(D) device is not running (l’appareil PNIO(D) ne fonctionne pas) : le robot configuré comme esclave (I/O Device) n’a pas démarré. Rôle différent, solution différente. Solution du manuel : désactiver l’I/O Device s’il n’est pas utilisé, ou vérifier l’I/O Controller (l’automate).
• PRIO-622 PNIO(C) controller is not running (le contrôleur PNIO(C) ne fonctionne pas) : le PNIO Controller lui-même n’a jamais démarré. Cela signifie que la partie FANUC de la pile a échoué au démarrage ; ce n’est pas un problème d’esclave.
• PRIO-623 PNIO(C) not in OPERATION mode (PNIO(C) pas en mode OPERATION) : le contrôleur a démarré, mais il n’est pas en mode OPERATION. Changez le mode de démarrage dans MENU > I/O > PROFINET > Setup et redémarrez.
• PRIO-624 PNIO(C) module number mismatch (numéro de module PNIO(C) non concordant) : le nombre d’emplacements configurés ne correspond pas au bloc d’E/S physique. Apparaît habituellement après le remplacement d’un bloc à 4 canaux par un bloc à 8 canaux sans mise à jour de la configuration.

Probot Systèmes est un intégrateur FANUC établi à Lévis (Québec) qui dessert le Canada et les États-Unis. L’intégration PROFINET avec Siemens, Allen-Bradley ou tout autre automate qui communique avec un robot FANUC fait partie de chaque cellule que nous mettons en service. Si votre historique d’alarmes est rempli d’entrées PRIO-620 sans cause claire, parlons-en : contactez-nous.