Wago e!Cockpit (Slave) - PCVue (Master) Modbus TCP/IP

[ÉtudiantEnHerbe]

Je me permet de UP le sujet

[philou77]

Salut !

petit up oui et ?
tu réponds pas à la question posée par DPO :
soit utiliser le configurateur ecockpit, avec certaines limitations liées au fait que c'est du "tout prêt"
ou utiliser le bloc serveur pour publier tes variables

pour l'adressage:
La Norme modbus est en Base 1 : le premier élément est à l'adresse 1

Pc vue doit être en Base 1, comme la majorité des applications clientes.
Le Wago doit est en Base 0 : Le premier élément est à l'adresse 0
D'ou ce décalage.

Pour les autres réponses, je laisse DPO te répondre, il est plus calé que moi sur Wago.

Et si tu communiques, ça doit pas être compliqué de déclarer une variable que tu peux modifier dans un champs sur une vue Pcvue.


Pour rappel :
adresse 1...10000* => Coils (outputs)
adresse 10001...20000* => Discrete Inputs
adresse 30001...40000* =>Input Registers
adresse 40001...50000* => Holding Registers

[dpo]

les limitations sont celles d'un truc "tout prêt", y aura toujours un moment où tu risques de ne pas rentrer dans les bonnes cases .
quantité d'infos ? format ? zone mémoire utilisée....
Attention, c'est un choix et avis perso, ça peut très bien fonctionner suivant ton besoin
perso je préfère localiser mes variables et utiliser le serveur :
quand je déclare une variable, je la localise dans la zone déclarée par le serveur et c'est fini : elle est accessible en com
sinon, il faut la déclarer puis aller dans l'outil pour la faire remonter en com

sur pcvue,de mémoire tu as modbus ou jbus. il me semble qu'un commence à 0 et l'autre à 1

si tu localises une variable, par exemple en %MW100 modbus TCP
tu pourras y accéder depuis un IHM ou depuis Pcvue
l'écriture est événementielle, donc les deux doivent pouvoir écrire, c'est le dernier qui parle qui a raison (sur pcvue ne pas oublier de déclarer la variables en consigne). Par contre si tu bricoles un truc (comme un programme cyclique) qui écrit en permanence dans la variable, forcément ça ne fonctionnera pas.

et pour finir, tout ça devrait t'occuper un moment.
je viens de découvrir que les variables localisées ne sont pas sauvegardées à la coupure (ou alors j'ai raté un truc), même si déclarées en RETAIN.
Du coup , j'ai bêtement déclarer un tableau RETAIN de la même taille que la zone modbus.
à chaque tour de cycle je recopie le tableau modbus dans le tableau RETAIN
sauf au premier tour de cycle où je recopie le tableau RETAIN dans le modbus
(ça fonctionne aussi si tu remplaces ton tableau RETAIN dans les var "persistent", tu gardes alors les valeurs en cas de reset à froid)

tout ça à prendre avec des pincettes, ce sont des découvertes récentes pour moi.

[ÉtudiantEnHerbe]

Merci pour toutes ces précisions. Je pense que OUI cela va me prendre du temps.

Je mettrais à jour le sujet avec mes avancées.

Merci de votre patience

[ÉtudiantEnHerbe]

tu pourras y accéder depuis un IHM ou depuis Pcvue
l'écriture est événementielle, donc les deux doivent pouvoir écrire, c'est le dernier qui parle qui a raison (sur pcvue ne pas oublier de déclarer la variables en consigne). Par contre si tu bricoles un truc (comme un programme cyclique) qui écrit en permanence dans la variable, forcément ça ne fonctionnera pas.

Je n'ai pas encore eu le temps de tester les autres points. Mais je n'ai pas réussi à modifier la même variable depuis PcVue et l'automate. J'ai l'impression que PcVue re écris à l'infinie sans lire la variable. Exemple : j'écris une valeur depuis PCVue, l'automate reçois bien la valeur. Je modifier la valeur depuis PLC_Visu, ma valeur est écrasé par celle de PcVue. J'ai l'impression d'avoir loupé quelque chose . La variable est bien en écriture/lecture dans PcVue, pourtant...

EDIT: à moins que cela est dû aux limitations des solutions "toute faite", car dans e!cockpit la variable ne peut avoir la "Direction" Entrée et sortie simultanément...

[ÉtudiantEnHerbe]

les limitations sont celles d'un truc "tout prêt", y aura toujours un moment où tu risques de ne pas rentrer dans les bonnes cases .
quantité d'infos ? format ? zone mémoire utilisée....
Attention, c'est un choix et avis perso, ça peut très bien fonctionner suivant ton besoin
perso je préfère localiser mes variables et utiliser le serveur :
quand je déclare une variable, je la localise dans la zone déclarée par le serveur et c'est fini : elle est accessible en com
sinon, il faut la déclarer puis aller dans l'outil pour la faire remonter en com

sur pcvue,de mémoire tu as modbus ou jbus. il me semble qu'un commence à 0 et l'autre à 1

si tu localises une variable, par exemple en %MW100 modbus TCP
tu pourras y accéder depuis un IHM ou depuis Pcvue
l'écriture est événementielle, donc les deux doivent pouvoir écrire, c'est le dernier qui parle qui a raison (sur pcvue ne pas oublier de déclarer la variables en consigne). Par contre si tu bricoles un truc (comme un programme cyclique) qui écrit en permanence dans la variable, forcément ça ne fonctionnera pas.

et pour finir, tout ça devrait t'occuper un moment.
je viens de découvrir que les variables localisées ne sont pas sauvegardées à la coupure (ou alors j'ai raté un truc), même si déclarées en RETAIN.
Du coup , j'ai bêtement déclarer un tableau RETAIN de la même taille que la zone modbus.
à chaque tour de cycle je recopie le tableau modbus dans le tableau RETAIN
sauf au premier tour de cycle où je recopie le tableau RETAIN dans le modbus
(ça fonctionne aussi si tu remplaces ton tableau RETAIN dans les var "persistent", tu gardes alors les valeurs en cas de reset à froid)

tout ça à prendre avec des pincettes, ce sont des découvertes récentes pour moi.

Bonjour,

J'ai essayé toute les options possible sur e!cockpit, je n'arrives pas à avoir une variable bidirectionnelle.

Vous auriez un exemple simple ? Svp

Bien cordialement

[dpo]

En utilisant le serveur modbus TCP (sans passer par l'outil du configurateur)

1/
tu dois avoir une table
GVL_MODBUS_TCP_IP_SERVEUR
dans laquelle tu as une variable
awHoldinfRegisters AT %MW1 : ARRAY[1..1999] of word;

par défaut elle n'est pas localisée, c'est à toi de mettre AT %MW1 par exemple, qui va coller avec la case 1 de ton tableau
tu peux partir à 0
dans l'exemple ci-dessous les variables localisées dans le wago à partir de %MW1 vont être publiées dans le modbus à partir de 1

2/
les variables que tu utilises dans le programme et que tu veux accéder en modbus doivent être localisées

exemple dans une GVL
MOTTEST AT %MW50 : INT;


3/ Tu fais un premier essai avec modbus doctor pour lire %MW50, tu peux y écrire si le programme n'écrit pas déjà en permanence

4/ si ok tu passes à pcvue : tu déclares une com modbus TCP, puis l'automate avec son IP, puis une trame de 1 à 100 par exemple
et enfin une variable qui tape à l'adresse %MW50 dans la trame

5/ tes variables localisées ne sont pas maintenues à la coupure
dans le wago tu déclares dans VAR_GLOBAL RETAIN : un tableau "SAVEmodbus" de mêmes tailles et format que awHoldinfRegisters sans le localiser

au premier tour de cycle tu recopies SAVEmodbus vers awHoldinfRegisters
puis tout le reste du temps tu recopies awHoldinfRegisters vers SAVEmodbus

[ÉtudiantEnHerbe]

Je crois avoir compris les étapes, mais que veux dire cette phrase:

En utilisant le serveur modbus TCP

C'est un FB? Ou il suffit juste de déclarer des variables GVL localisées ?

À quel étape j'indique que telle variable est en mod input et output simultanément? À moins que je fais appel à la même variable pour le bloc qui lit les variable modbus et celui qui écrit ?

[dpo]

Pas le courage de démarrer la VM un dimanche !
mais oui c'est bien en passant par un FB modbus TCP de codesys
le sujet a été évoqué dans ton post :
solution 1 : via la configurateur
solution 2 : via de la programmation avec blocs fonctionnels

tu n'auras pas à dire que la variable est en input ou output

Dans l'appel du FB tu localises le tableau modbus des holding register
Dans une GVL tu déclares tes variables en les localisant, et ça marche dans les deux sens.