Forum automatisme

Bonjour,

Sur une connection en put/get entre deux PLC s7 1500, la PLC qui est passive reçoit les infos dans les mêmes numéros de DB que celle qui est active.
Mais comment voir dans le projet de la CPU passive qu'il y a une connection avec l'automate actif ?

(Dans le cas où les deux Cpu ne sont pas dans le même projet)

Merci

Slts,
ya pas d'automate actif ou passif, c'est soit Client / Serveur ou Maître / Esclave
Sinon le moyen le plus sur pour savoir si ça communique c’est le « mot de vie »

si tu as la main sur le programme tu peux ajouter un mot de vie qui change sans arrêt pour vérifier si l'automate distant écrit bien.
encore plus basique, si l'automate distant met un bit toujours à 1.
tu mets ce même bit à zero et tu lances une tempo qui le teste à 0
si la com fonctionne , l'automate distant finira par y mettre 1 et la tempo n'arrivera jamais au bout
si la com ne fonctionne pas, ta tempo arrivera au bout et tu auras un défaut com

Merci pour vos retours !

Je suis d'accord avec vous pour le bit de vie afin de relever un défaut de com.

Malheureusement, je n'ai pas la main sur la CPU active afin de rajouter ce bit. ( itasoft, en com S7 get/put, la doc siemens parle bien de CPU active pour celle qui continent les instructions get/put et l'autre est passive ; voir photo en PJ)

De plus, je trouve étonnant qu'aucune information de liaison doit être renseigné dans la CPU passive ; si un second automaticien récupére le programme, comment va t'il deviner que les DB dans la CPU passive sont en liaison get/put.

( itasoft, en com S7 get/put, la doc siemens parle bien de CPU active pour celle qui continent les instructions get/put et l'autre est passive )
-----------
excuses, mais j'entrave que couic en "teutons"

tkt ça revient au même que maître/ esclave

c'est sauvage mais en effet en ayant le programme du "passif" rien ne dit qu'un autre automate ne vient lire/écrire dedans.
C'est pareil en modbus, si un autre automate lit ou écrit à distance dans tes registres, tu ne le sais pas forcément.
Il faut être très prudent quand tu as une architecture avec plusieurs automates qui échangent des infos via la com
A voir si dans le DB que tu reçois il n'y a pas une info qui change régulièrement comme une température en réel ? pour s'en servir de mot de vie ?

En modbus TCP, il me semble qu'il faut un bloc fonction côté client et un autre côté serveur.

Pour revenir au get/put, non j'ai pas de valeurs qui doivent bouger tel une température.

Le seul défaut que je pourrai créer sera un défaut de retour de marche sur une requête.

Dommage !

Merci à la communauté

Slts,
Si la communication est permanente ou périodique, Il y aurait une autre combine,
Exemple :
Sur un des mots que le maître vient écrire, après en avoir fait l’acquisition je lui met la valeur H,5555 ou une valeur négative si on censé recevoir que une valeur positive. si cette valeur reste et n’est pas écrasée par le maître alors Défaut
A VOIR

Auto10 a écrit : ↑12 mars 2023, 23:12 En modbus TCP, il me semble qu'il faut un bloc fonction côté client et un autre côté serveur.

Non, c’est pas nécessaire côté serveur. C’est transparent pour l’utilisateur