Forum automatisme

didi2211 a écrit :Je comprend bien qu'il faudrait lire énormément de doc et prendre en main plusieurs programmes pour bien cerner toute la question malheureusement je suis limité en temps (la communication avec le Wago n'est qu'une partie de mon projet) et c'est pour cela que je me suis lancé dans mon programme C++.

Par exemple si je veux allumer la balise orange, je dois écrire à 1 le bit à l'adresse %QX0.2 (je ne vois pas comment traduire cette adresse dans ma trame).

Ya pas forcément des millier de doc a parcourir, faut commencer par le commencement , tu as un automate disposant pouvant dialoguer en Modbus, Comment traduire l'adresse QX0.2 ?

Qui peut te documenter Y a que le fabriquant qui a la réponse. Si tu prends un automate d'une autre marque l'adresse sera différente.
Les doc wago sont plutot bien foutu et accessible facilement ce qui n'est pas le cas de tous les constructeurs.

Tu cherches le manuel de ton automate en tapant 750-881 sur leur site et la tu auras le manuel de celui-ci. Le manuel fait 400 pages, tu nas pas besoin de lire les 400 pages puisque tu n'as pas a concevoir ou dimensionner un système. Tu as un chapitre dédié au modbus avec une 40aine de page a tout cassé.

tu trouveras même des généralité sur la trame peu être suffisante pour ton développement.


Pour moi il te faut potasser 2 doc : Celle de ton automate et une doc sur le protocole

si tu tapes Modbus TCP sur google tu vas tomber en 1er page sur un pdf : MODBUS Messaging on TCP/IP Implementation Guide V1 par exemple. apres tu peux aprofondir avec d'autres doc, mais celle-ci est a mon avi un point de départ essentiel.

filou59 a écrit :
Dans ton programme tu as par exemple l'info BpMonter qui est rangé en %IX258.0.
Tu y accèdes comment avec un soft que ce soit en Lecture ou en Ecriture ?


Bonjour,

Je suis pas sûr de bien comprendre la question mais dans mon cas je dois y accéder via Modbus TCP.

J'ai compris que tu veux y acceder en modbus, mais le modbus c'est caractérisé par quoi ?

En utilisant un soft comme simplymodbus modscan ou autre cela t'oblige a un moment donné a te posé des questions :
quel protocole : Modbus TCP ou RTU ?
Un Esclave : Ton automate : Adresse IP + Port
Dans ton automate tu peux lire / ecrire des bits ou des mots.
Lire ou Ecrire : Ca correspond a quoi ? a une fonction ?
Des Bit ou Des Mots : idem ....
Comment tu traduits IX258.0 en adresse mémoire ?
C'est la que la doc de ton automate rentre en jeu.

Faut que tu comprennes un minimum sur le modbus pour pouvoir faire du développement autour. Faut pas mettre la charrue avant les bœuf comme on dit.


PS : Attention dans tes recherches tu peux trouver des info sur du modbus RTU, c'est un peu différent du modbus TCP, le 1er est établi sur une liaison de type RS485 en général ,alors que le 2nd est sur un reseau IP.
La reférence que tu as cité chez simplymodbus c'est pour du modbus rtu car en modbus tcp il n'y a pas de crc ni de notion d'esclave (Slave)

Me revoilà après mes recherches

Pour répondre à vos questions et vous mettre au courant de mon avancement je vais faire un petit résumé :

- Mon objectif principal est de contrôler une barrière munie d'un Wago via un programme C++ développé avec QT.

- Le protocole utilisé pour la communication est Modbus TCP (j'ai appris son utilisation en cours donc pas de soucis là dessus).

- Mon automate a une IP dans le même sous réseau que mon PC et j'ai activé le port 502 pour utilisé le Modbus TCP.

- Mon objectif pour le moment est d'activer le feu de signalement, pour ça je dispose de son adresse et de son type : booléen, je dois donc accéder à son adresse afin d’écrire le bit à 1.

- Pour écrire le bit à 1 via Modbus je dois utiliser la fonction 5.

- L'adresse de la variable BaliseOrange communiquée par Wago (et que je modifie avec succès avec Codesys) est %QX0.2, grâce à la doc j'ai traduit cette adresse en hexa ce qui me donne 0202.

- J'ai tenté de modifier cette variable via mon programme sans succès, j'ai donc essayé de lire (fonction 1).

- J'ai réussi avec succès à lire l'adresse correspondant à l'action d'un bouton (retour de 1 lors de l'appuie et 0 si relâché).

- J'ai tenté la même chose avec le feu à savoir : Actionnement du feu via Codesys et lecture à l'adresse 0202 = bit à 1 / Si feu éteint = bit à 0.

- L'analyse de transfert des trames via Wireshark ne me montre aucune erreur : ma trame est bien envoyée et ma trame réponse ne contient aucune erreur.

Là je suis vraiment dans une impasse et je ne vois pas quoi faire Avec Codesys je peux bien frapper les variables directement en créant un programme simple mais en Modbus impossible, j'espère qu'il n'y a pas de sécurité permettant seulement à Codesys de pouvoir changer la valeur des variables... Je vais contacter Wago pour leur demander si c'est le cas.

L'adressage hexadécimal Modbus TCP semble correct pour ta sortie.
Maintenant question bête :

didi2211 a écrit :- Pour écrire le bit à 1 via Modbus je dois utiliser la fonction 5.

- L'adresse de la variable BaliseOrange communiquée par Wago (et que je modifie avec succès avec Codesys) est %QX0.2, grâce à la doc j'ai traduit cette adresse en hexa ce qui me donne 0202.

- J'ai tenté de modifier cette variable via mon programme sans succès, j'ai donc essayé de lire (fonction 1).

Est-ce qu'il n'y aurait pas encore un programme Codesys implanté dans l'automate qui force l'état de la sortie %QX0.2 pendant que tu exécutes ton programme ?

Là je suis vraiment dans une impasse et je ne vois pas quoi faire Avec Codesys je peux bien frapper les variables directement en créant un programme simple mais en Modbus impossible, j'espère qu'il n'y a pas de sécurité permettant seulement à Codesys de pouvoir changer la valeur des variables... Je vais contacter Wago pour leur demander si c'est le cas.

Salut

Dans un automate tu ne peux pas piloter une sorties depuis plusieurs endroit. (Cest une question de bon sens)

Chez wago tu peux choisir qui commande les Sorties, dans la configuration des cartes E/S tu trouveras un onglet PI Allocation qui permet de sélectionner l'organe qui pilotera la carte : PLC, Modbus ou Ethernet IP.

Dans 99% des cas on va choisir le PLC. Ce qui est normal. Puisque si tu as un prg c'est lui (le PLC) qui doit être le maitre, en cas de coupure de comm etc... il ne faudrait pas que le cycle soit interrompu...
Dans ton cas tu ne peux pas commander une sortie Physique directement, (ou meme une sortie interne qui serrait commandé dans le PLC)
1: Tu as un programme qui tourne deriere , c'est lui qui est prioritaire
2: Une commande comme tu veux le faire reviendrais un faire un forcage, chose qu'il faut manier avec précaution quand on en fait, c'est donc mieux de pas pouvoir le faire.

Après je n'ai pas le programme mais au vu du nom des variables, les 2 variables Bpmonter et Bpdescendre doive te permettre d'agir a distance de maniere "soft"' afin de commander ta barriere.

C'est les seuls actuellement qui a mon avi peuvent etre piloté a distance.
si tu veux commander ton feu, il faut je probablement modifié le programme et ajouter un bit interne afin d'effectuer la commande en parallèle du fonctionnement déjà prévu.

Salut,

D'ailleurs en regardant bien certaines adresses de tes variables sont adressées au delà de 255, zone d'adresse qui correspond aux variables réseau Modbus...

Bonjour,

Me voilà de retour de week-end

J'ai fais comme a dit filou j'ai mis le PI Assignment sur Modbus et j'arrive enfin à communiquer avec la barrière via mon programme !

Maintenant il me reste à étoffer ce dernier pour lui ajouter toutes les fonctionnalités demandés...

Merci à tous pour votre aide je vous tiens au courant de la suite

Salut didi

Petite question tu as bien un programme dans ton automate ?
C'est bien lui qui pilote les Sorties ?

Dans ce cas si tu lis bien ma réponse j'ai bien précisé qu'il ne fallait pas utiliser cette méthode. Car si tu fais ca ton programme ne va plus piloter les sorties. Elles le seront uniquement en modbus.

Il faut utiliser des bits internes : certains sont présent dans ton programme d'apres la liste, ensuite si tu veux agir sur d'autres sortie, il faut en créer d'autres et les affecter dans ton programme

A+

J'ai un programme vierge dans mon automate, j'ai seulement fait la déclaration des variables.

Je pilote tout via mon programme C++ maintenant je ne dois plus utiliser Codesys donc la méthode est bonne non ?

Oui si tu n'as pas de programme.

Après c'est loin d'être optimal comme mode de fonctionnement.
1: Si tu utilises un automate sans y mettre le moindre programme, on peut de dire pourquoi ne pas choisir un simple coupleur. (C'est comme un automate sauf qu'il n'y a pas de programme mais tu y accede en modbus comme un automate)
Niveau prix un coupleur cest 100€, un automate 400€ (C'est pas les prix exacte, c'est juste pour donner un ordre d'idée)

2: Etre tributaire d'un soft et d'un PC/Serveur, c'est pas tip/top, ca veut dire que ta bariere n'est plus controlé en cas de plantage ou d'arret.
Exemple niveau sécurité :
Tu donne l'ordre de refermer la bariere, ton prg plante, la liaison est intérompu, un cable reseau defectueux, voir débranché par le nouvel interimaire, un switch defectueux ou qui est rebooté par l'admin réseau etc ... , bref il se passe qq chose de pas normal, mais au meme moment qq passe devant une cellule. Logiquement tu donnes l'ordre a ta bariere de se rouvrir (a moins que d'avoir une dent contre la personne qui passe )
Resultat une bariere sur la tronche

Une bonne solution (pour ba dire la bonne solution), c'est de mettre un programme dans ton automate qui va gérer le fonctionnement de ta bariere pour un fonctionnement autonome et sur.
Apres tu peux donner des ordres depuis l'exterieur (via ton soft) et récupérer des infos pour une supervision par exemple , mais rien qui ne puissent entraver la sécurité.

Tu comprends ce que je veux dire ?

A priori c'est un exercice scolaire, je ne pense pas ce soit une "vraie" application car en effet indépendamment de l’aspect douteux au niveau sécurité quel serait l’intérêt de mettre un automate pour ne pas l'utiliser ?

JC