Com ethernet automate Siemens/Supervision

Fermé
Loïc PROVENT - 29 avril 2004 à 14:27
 demouss - 16 juil. 2009 à 16:56
Bonjour. Je suis stagiaire a PLACOPLATRE à Chambéry et mon sujet de stage et de résoudre un problème de communication par Ethernet.
L'usine est équipée de plusieurs automates Siemens (principalement S7-400 et un automate S7-300) ainsi que d'un logiciel de supervision FactoryLink.
La supervision permet de visualiser toute l'usine et d'intervenir en cas de besoin.
La communication entre la supervision et les automates se fait par industrial Ethernet. Le problème se situe avec le com Ethernet avec l'automate S7-300.
Il arrive (environ 3/4 fois par ans) que la communication entre la supervision et l'automate tombe. En général on peut relancer la communication depuis la supervision, mais parfois, c'est impossible. Dans ce cas la, la seule solution est de recharger le programme complet dans l'automate.
A ce moment la on peut relancer la communication.
Ce problème n'arrive que pour la communication avec l'automate S7-300 (jamais avec les S7-400 ni même les S5). Lorsque la communication est coupée, il s'affiche "ERR22" sur la supervision, et il est alors impossible de relancer la communication par n'importe quel moyen (acquittement des défauts, arrêt de la supervision, coupure de la liaison...). La seule solution est alors de recharger le programme dans l'automate.
La difficulté qu'il y a est de cerner le problème. En effet il est très difficile de savoir pourquoi la communication tombe.
Le problème peut venir soit des versions des blocs (FC send et receive de la communication Ethernet), soit d’incompatibilité entre la version de la supervision et de l’automate, etc…
Je demande donc de l’aide, si quelqu’un a une idée de ce qui pourrait engendrer ce problème je lui serait très reconnaissant de me faire part de ses idées. Merci d'avance.
Bonne continuation a tous.

5 réponses

ca va mes amis
je veus un logicial supervisin complet et gratuis
4
As tu pensé à qqch comme Nagios ? 100% gratuit ^^
0
tres cher loic je remarque que tout le monde est dans la meme merde pour son stage !!
0
Bonjour

On peut utiliser tous les OB de diagnostic. On programme tous les OB de diagnostic en arrêtant la CPU, l'ors du plantage on regarde quel OB de diagnostic a été déclenché cela donne des pistes de recherche.

J’ai déjà utilisé cette méthode pour des plantages de cpu a priori sans raison.

En espérant avoir apporté une aide
0
Déjà il ne faut pas utiliser les blocs send receive pour la communication entre S7 et supervision. Il faut utiliser des cartes APPLICOM ou autre pour communiquer via un serveur OPC. Tout ce fait de manière transparente via ce type de serveur, pas besoin de programmation spécifique coté automate.
0
Bonjour;
j'ai une aidé c'est de chérché le référence de cette automate S7-300 puis vérifier l'ampérage,le volt,bref tout les parametr nessécaire pour cela
peut etre l'erreur est matérielle puis il cause la coupure de la communication
Mois aussi j'ai un sujet PFE . concerne les Micro coupure
je cherche des solution pour protégé le matériel sensible
Merci pour aide
0
autom > hector
19 mai 2009 à 10:38
protection des micro coupures ............. un onduleur est le bon produit
0
slt RORO, juste te dire merci pour l'aide apporte a l'autre. Mais j'aimerais que tu m'aide vraiment sur mon thme de stage qui est la mise en place d'une supervision /automates je crois que vous me serriez d'une aide capitale merci d'avance je comptes sur vous
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
slt
a mon avie si je comprend bien votre prob se que la comminication est mieux et efficase sur le S400 que sur S300 alors la c'est acause de la memoir ram interne de l'automate el la vitesse de trnsmission de donne comme on dit exeple 9600baude ce que j epense a ce moment si vous ete iteresse je peut vous edéé encore et vous pouver m'appeler sur SKYPE sur mon pseudo Med ali et mon paye c'est tunisie OK /
-1