Communication entre deux S7-315-2DP / CP343-1 et un S7-1516-3PN... Quelqu'un a déjà fait ?
-
le 24/11/2017 à 00:13 Citer ce message
Bonjour.
j'ai besoin de faire une migration d'un S7-315-2DP avec un S7-1516-3PN.
Le S7-1516 (Fw 2.0) sera en communication avec deux S7-315 (Fw 2.0) équipes de CP 343-1 (Fw 2.0).
D'origine, tout les S7-300 communiquent en liaison TCP avec des blocs AG_SEND_LF / AG_RECV_LF et sur le réseau IE il y a:
- 6 PLC S7-315-2DP (2 CP343-1 Lean et 4 CP343-1).
- 2 PLC S7-313C (CP343-1 Lean)
- 16 HMI Proface.
les soft : TiaPortal V14 SP1 UP3 pour le S7-1500 et Step 7 V5.5 SP2 pour les S7-300
L’installation a 12 ans et il y a quelques problèmes de paquet qui n'arrive pas à destination (1 erreur par mois).
J'ai révisé les documents Siemens, les firmware des CP et des CPU (300) sont trop vieux et incompatibles pour communiquer avec un S7-1516.
J'ai donc réalisé différents testes de connexion grandeur nature avec le S7-1516 (sur le réseau actuel avec tout les équipements).
#1
Le S7-1516 avec des blocs T_Send_C et T_Recv_C (le 1516 n'est pas compatible avec les blocs AG)
Le S7-315 sans aucune modification
*Résultat: Çà ne marche pas.
- Il n'y à pas de connexion (NetPro) des liaisons.
- les DB ne sont pas actualisées,
- les paquets de la CP reste à 0.
- La CP a fait plusieurs tentatives de connexion sans résultat.
#2
J'ai configuré une liaison S7 dans le 1516 et dans le 315 pour utiliser des blocs PUT/GET ... Pour info: c'est une configuration que j'ai fait l'année dernière avec un PLC S7-1511-C , 1 ET200 CPU et un S7-317/CP343-1 Lean. La mise en service des PUT/GET c'est très bien passé et il n'y aucun de comm depuis 1 ans.
j'ai chargé la config matériel dans le 315 (nouvelle liaison S7) ... il n'a pas réussi a passer en RUN pour un défaut de la CP.
*Résultat: Ça ne marche pas.
#3
Je suis revenue sur une liaison TCP dans les deux PLC
Le S7-1516 avec des blocs TSEND / TRECV
Le S7-315 avec les bloques d'origine AG
*Résultat:
- La liaison NetPro à établi la connexion.
- les DB ne sont pas actualisées.
- Les paquets de la CP transitent en envoi et réception.
- La CP a perdu la comm a plusieurs reprise (pas plus de 20 min de marche entre reconnexion).
#4
J'ai révisé les différents paramètres de config de la CP car il y a eu des échanges de paquet entre les deux PLC, plusieurs paquets sont arrivé dans la CP mais dans la CPU (du même rack).
J'ai un doute sur la longueur des trames. les 8 PLC sont paramétrés avec des trames de 240 Bytes avec les DB sont cohérentes avec 240 Bytes. Dans les documents Siemens, pour une CP343-1, la valeur des trames ne doit pas dépasser 160 Bytes... (ça fait 12 ans que la config tourne avec des valeurs bizarres).
Donc, j'ai fait des testes avec des longueur de trame sur 160 Bytes.
*Résultat:
- La liaison NetPro à établi la connexion.
- les DB sont actualisées mais il y a plein variation du temps d'actualisation (jusqu’à 4s pour rafraîchir la DB).
- Les paquets de la CP transitent en envoi et réception.
- La CP ne perd pas la comm et il n'y pas eu d'erreur de connexion au passage en RUN.
#5
J'ai réduit la longueur des trames à 80 Bytes (50 bytes utilisé en réel).
*Résultat:
- les DB sont actualisées et le rafraîchissement semble correct.
- Les paquets de la CP transitent en envoi et réception.
- La CP a un statut en communication.
- La liaison du S7-315 NetPro n'arrive pas à établir la connexion (en rouge).
- La liaison du S7-1516 a un statut en communication (en vert).
- La CP du S7-1516 me renvoie un message d'erreur de connexion du PLC distant.
Je suis pas pro en communication S7-1500 (pareil en S7-300 mais un peu moins) j'ai déjà vue des trucs bizarre sur des TSX avec plusieurs changement de protocole... mais jamais avec Siemens (sauf les vieux ET200 en MS-DOS).
J'ai terminé les testes avec des données "correctement" échangés entre deux PLC mais avec des voyants rouge partout.
J'ai gros doute sur la fiabilité et la configuration actuelle des PLC... Si quelqu'un a une idée (sans changer les CP) des paramètres ou autres type de comm pour des CP343-1 en Fw 2.0 avec un S7-1516.
Merci d'avance.
Répondre à ce message
