Forum automatisme

Tout d'abord, bonjour à la communauté !

En faisant mes recherches, je suis tombé sur votre forum qui pourra peut-être m'aider dans mon problème.

Alors pour commencer, la ligne de production est équipé de 4 automates TSX Premium P57 5634M, relier entre eux via le modbus-TCP.

Depuis quelques temps, un de ces automates se met en HALT de façon totalement aléatoire, que la lige soit en production ou à l'arrêt... Pour cause de débordement du chien de garde.

N'ayant (pour ma part du moins) pas fait de modification soft sur cet automates, je suis parti sur un problème matériel. A donc été changé (dans le désordre), les piles de sauvegardes, la CPU, la carte mémoire, le bloc alimentation, une carte de sortie TOR et la suppression d'une carte CANopen qui ne servait plus...
N'ayant pas de succès, j'ai modifié le temps du chien de garde. Sur cet automate et uniquement sur celui-ci, la période programmée était en périodique. Je l'ai donc modifié pour le mettre comme pour les autres en cyclic à 150ms d'abord puis progressivement à 250 ms. En fonctionnement normal la durée courante de dépasse pas 8 ms.

Malgré cela, le problème revient toujours.
En poussant un peu plus l'analyse à l'aide des bits d'erreur et via la visualisation de diagnotic les nits %S11 et %S19 sont à 1, et la cause du dernier arrêt remonté est : arrêt sur un défaut logiciel (débordement de la tâche ou débordement SFC).
Les mots systèmes m'indique : %SW124 : 16#EC0E, %SW125 : 16#DEB0, %SW126 : 4 et %SW127 : 250 .

Le problème semble donc venir de la tâche MAST (?), le problème est que le programme est très lourd et sans indications plus précise, difficile de savoir où regarder, autre problème quand celui-ci passe en HALT, il est impossible de se connecter sans avoir coupé l'alimentation de l'automate.

Je cherche donc une aide, si il y a une moyen de savoir quel élément provoque la mise ne HALT de l'automate. Mes connaissances étant plutôt limité en Schneider, je sèche...

Merci

slts,
par défaut le chien de garde c'est 250 ms
Analyser le programme voir si on entre pas dans une boucle infernale

Je sais que certaines fonctions comme les tri de données peuvent allonger si l'on travaille sur de grandes plages de données. La division par zéro aussi est fatale.

si aucune modif programme n'a été faite récemment, ni aucune modif sur des données échangées (formats , quantités)... il y a peu de chances que le problème vienne du programme (selon moi)
il y a peu un client a eu ce genre de soucis, il a changé quasi tout le matériel sans succès, le code d'erreur faisait penser à un soucis programme et en fait c'était un retour de tension sur la terre qui le plantait. Ils ont séparé la terre de l'armoire autom de celle de puissance et ça refonctionne.

Salut, as-tu une carte TSX ETY sur ton rack?

Bonjour,

dpo a écrit : ↑16 févr. 2023, 10:51 Ils ont séparé la terre de l'armoire autom de celle de puissance et ça refonctionne.

C'est une piste en effet : contrôler la tension entre Neutre et terre.
J'ai eu cela dans une installation traitement de surface, la terre était mauvaise.
Problème constaté également en peinture : Haute tension mauvaise masse.

Sinon, la surcharge de communication peut elle aussi provoquer un plantage CPU avec le voyants CPU/MEM/IO allumés.
Cordialement.

Salut,

j'ai eu récemment des API Premium qui plantaient.
Dans mon cas, la tâche MAST était paramétrée en périodique ; on a ajouté de nouveaux équipements qui dialoguent avec les API (migration de supervision), ce qui ajoutait de la communication (pas des masses : 4 connexion TCP supplémentaires, au lieu de 8 normalement).
Le fait d'avoir passé la tâche MAST de périodique (qui ne se justifiait pas) à cyclique a fixé le problème.

Une analyse du réseau pourrait peut-être aider à s'orienter sur le problème ?
Une capture avec Wireshark, et les statistiques des conversations montreraient combien de connexions sont faites sur l'API.

Après, à chaque plantage, les variables systèmes sont-elles toujours aux mêmes valeurs ?

Bon courage.

Salut à tous et merci pour votre aide.
Désolé de ne répondre que maintenant, mais j'étais en formation.

Alors, je n'ai pour ma part aucunes modifications d'un point de vue programmation depuis que ce problème est apparu, par contre je ne suis pas le seul à me connecter à l'automate, d'autres ont pu le faire sans le dire... De temps à autres certains s'y connecte pour modifier un point (valeur d'un axe) par exemple écrit "en dur" dans la programmation...

@itasoft
C'est une des pistes explorées. Mais pas simple à trouver, j'ai essayé de mettre un "mouchard" dans chaque G7, mais ça ne fonctionne pas.

@dpo @durando
Merci, je vais y regarder c'est t'on jamais. C'est une chose que je n'avais pas pensé.

@lamejer65
Oui, il y a sur le rack une carte ETY5103 mais qui ne sert pas, celle-ci avait été installé pour un capteur d'effort qui n'a jamais était mis en place mécaniquement...

@laurent
Je vais essayer ça aussi et je ferrai un retour. Voir aussi pour faire une analyse réseau. Ont à eu il y a 2/3 ans un problème de communication, cela provenait d'un des hubs. Du coup, on avait remplacer tout les hubs et changer tout les câbles éthernet en catégorie supérieure, car beaucoup de perturbations magnétique dans l'atelier (soudures électriques HT, aimanteur HT...)
Sinon oui, les variables systèmes ont toujours la même valeur.

PS : sans le vouloir j'ai cliqué sur "résolu" en voulant citer un message, mais hélas ce n'est pas encore le cas. Si un modo pouvait corrigé, merci.

Nous avons eu un problème similaire récemment sur le site d'un client.
Le problème a été résolu lorsqu'il a repris le raccordement de la terre et des communs, conformément aux préconisations de Schneider. Il est en régime IT.

Nous avons conclu qu'un problème de communs/terre perturbait le fonctionnement du bus X du Premium, et entrainait des erreurs de Chien de Garde de l'automate.

lamjer65 a écrit : ↑16 févr. 2023, 19:10 Salut, as-tu une carte TSX ETY sur ton rack?

Bonjour à tous,

Juste une remonté de topic pour signaler la résolution du problème.

Si ça peut aider d'autres personnes dans le même problème, comme le proposé judicieusement lamjer65, c'est bien la carte d'extension TSX ETY5103 qui mettait l'automate en rideau. Carte remplacé, le problème à disparu.

Merci encore pour l'entraide, à bientôt.