Forum automatisme

Bonjour à tous,

J'ai un souci qui me turlupine...

J’intègre dans une ligne de production une CPU 1515F.
Sur mon réseau X1 (machine), j'ai mes équipements profinet (dont un ET200 et un robot en profisafe) et un Proface du client qui vient lire et écrire dans un de mes DB.

Sur le réseau X2 (ligne), je suis sur un réseau qui dialogue avec les autres automates de la ligne via un switch CISCO manageable. J'ai aussi mes 2 afficheurs (1 maitre, et l'autre en Smart Server).


Les semaines passées, il m'est arrivé 3 fois en 1 semaine, puis 1 fois celle d'apres, que mon automate passe en STOP.
Voici ce que me remontait le diagnostique de la CPU: Note importante: Le profisafe de mon robot démarre en E400.0 et A400.0!

Lorsque je me renseigne sur le net, ceux qui ont cette erreur ont soit:

• Ils chevauchent une variable non safety sur une variable safety (ex: ils utilisent %AW399 dans l'automate, alors qu'il y a du safety en E400...). Mais cela n'est pas mon cas.
• Après ça parle de variables non safety qui seraient utilisées dans du programme safety et qui foutrait la merde car changerait d'état au moment où le safety serait scruté. Je ne peux pas l'affirmer, mais cela ne semble pas etre mon cas.

Cette semaine j'ai fait un maximum d’essais avec tous les cas de figures possibles et imaginables, la CPU ne s'est jamais arrêtée...

Alors il faut savoir qu'a l'époque, ils avaient pas mal de problèmes sur le réseau de ligne, notamment des adresses en doublons...

Ce qui m’inquiète un peu, c'est que d’après certains post, cette erreur peut être vachement aléatoire et apparaitre furtivement des mois plus tard!

Quelqu'un a déjà eu ce genre de souci?

Merci!

Bonjour,

j'ai déjà eu le cas sur une consigne de seuil déclaré dans un F_DB, lorsque la consigne a été modifié de la valeur défini et que le défaut devait apparaitre, la CPU Passait en Stop...

il y a un sujet a ce propos : https://support.industry.siemens.com/cs ... 0&lc=en-AZ

lors de l'utilisation des variables venant du DB standard, bien la transférer dans une variable temp ou stat du F_FB F_FC.

A+

Pierro a écrit : ↑23 juil. 2021, 15:51 j'ai déjà eu le cas sur une consigne de seuil déclaré dans un F_DB, lorsque la consigne a été modifié de la valeur défini et que le défaut devait apparaitre, la CPU Passait en Stop...

Merci pour ton retour Pierro,

De mémoire l'adresse du message était claire chez toi? Par exemple ca me parle des adresses F-I/O400 offset 0, donc a partir du 1er bit de mon échange profisafe avec le robot. Toi le diagnostique t'envoyait directement sur ta consigne?
Parce que j'ai épluché plusieurs fois mon prgramme et je ne vois rien par rapport a cette plage d'adresse...

Merci,

Merci pour ton retour Pierro,

De mémoire l'adresse du message était claire chez toi? Par exemple ca me parle des adresses F-I/O400 offset 0, donc a partir du 1er bit de mon échange profisafe avec le robot. Toi le diagnostique t'envoyait directement sur ta consigne?
Parce que j'ai épluché plusieurs fois mon prgramme et je ne vois rien par rapport a cette plage d'adresse...

Merci,

Salut,

Non le message était le même que celui afficher dans la console de diagnostique, du coup j'ai perdu une journée a tourner autour ...

Par contre, les valeurs de F_DB ne doivent en aucun cas être modifier en dehors de la tache F (accès direct depuis IHM (c'était mon cas)ou table d'échange), la données n'est plus considéré comme "fiable" et la CPU se met en sécurité lorsqu'une équation est vrai avec la donnée.