Discussion :

[scharbo]

Bonjour,

Je suis actuellement en stage et je dois réaliser, sous window, une interface de supervision pour communiquer avec les éléments de l'installation.
Pas de soucis pour communiquer avec l'automate S7-300, j'utiliserai le serveur OPC inclus dans PCVue que je compte utiliser.

Par contre, je vais aussi devoir communiquer avec une cabine de poudrage qui est déja connectée à l'ordi via un cable ethernet et qui a son propre programme de supervision.

Il n'y a rien de prévu par le constructeur pour transmettre les données directement vers PCVue, ou vers n'importe quel autre programme que celui qu'ils proposent et qui ne nous satisfait plus.

En sniffant les paquets échangées, je suis capable de réecrire le protocole de communication utilisé par la cabine.
Je pense ensuite utiliser WinPcap pour récupérer les données des trames ethernets dans un programme (jusque là je vois à peu près comment faire, même si j'ai pas tant de connaissance en programmation que ça je vais apprendre...) et j'aimerai ensuite faire en sorte que le serveur OPC de PCVue puisse se connecter à mon programme comme il le ferait à n'importe quel serveur OPC pour récupérer les données (et c'est là que je suis perdu).

Bref, en résumé, j'aimerai créer un serveur OPC rudimentaire capable de mettre à disposition de tout serveur OPC plus développé les informations contenues dans une trame ethernet pour une IP donnée.

Ca a fait quand même un petit pavé à lire, désolé ^^'
J'espère ne pas demander un truc insurmontable

[Arnard]

Pour écrire un serveur OPC, il te faut un sdk compliant OPC foundation. N'as-tu pas moyen d'écrire des plugins à intégrer au serveur OPC ? Ou de passer via un protocole plus simple comme modbus ?

[scharbo]

Je ne peux pas modifier le protocole utilisé par la cabine de poudrage.
Donc je suis bloqué avec mes paquets dont je dois déchiffrer la signification, enfin, c'est du TCP, donc je vais pourvoir récupèrer "facilement" les données utiles des trames, données utiles qui se présentent sous forme de code de 2 à une centaine d'octets, qui correspondent aux changements de parametres de la cabine.

Par contre, s'il y a moyen d'écrire un plugin pour le serveur OPC pour qu'il puisse lire ce qui m'intéresse (ou juste récupérer les données utiles de la trame que je traiterai ensuite au niveau du client), ça me conviendrait tout à fait, mais je ne sais pas du tout comment faire.

[Arnard]

je ne parle pas de changer le protocole à la source, mais introduire un "automate" tiers logiciel.
ta cabine cause avec son propre protocole, l'automate logiciel récupère les trames, les analyse et les publie en Modbus, et avec ton superviseur tu viens lire le modbus.

Pour ça, il faut que ta cabine envoie des données booléennes et numériques uniquement !

[scharbo]

Je ne sais pas si ta méthode aurait marché Arnard, les logiciels de simulations d'automate que j'ai trouvé ne m'ont pas été d'un grand secours mais il est vrai que je n'en ai pas cherché énormément vu que je me suis attaqué à mon idée précédente ( vu le format des données échangées, je doute qu'un logiciel tel quel aurait réussi à s'adapter facilement, à moins qu'il y ait les codes sources avec).

Donc, pour le moment, en sniffant le réseau j'ai pu avoir des chaines de données représentant les commandes échangées.

J'ai écrit un serveur TCP en C# qui me sert à simuler ma cabine, ainsi en connectant le programme du fournisseur à mon serveur TCP j'ai été capable en réenvoyant les données sniffés de récupérer les informations et j'ai commencé à réécrire le protocole d'échange (ça promet d'être un travail de longue haleine mais ça avance bien).

J'ai aussi écrit un client TCP en C# capable de se connecter sur la cabine à la place du programme constructeur et de récupérer les info échangées (même si pour le moment, je n'ai pas la totalité des correspondances pour les voir en totalité en langage compréhensible).

Là je cherche à connecter mon client TCP sur une base de donnée (j'ai encore des petits soucis à ce niveau là mais y a suffisament de doc sur internet pour que je m'en sorte) en espérant pouvoir ensuite récupérer les informations directement de la base de données vers soit le serveur OPC, soit directement vers le programme de supervision (j'ai pas encore eu le temps de me plonger dans PCVue pour savoir les possibilités à ce niveau là).

Il me suffira de finir la décortication du protocol d'échange et mon probleme devrait être résolu.

J'ai pas du tout l'impression de me compliquer la vie...

Merci en tout cas Arnard d'avoir pris le temps de me répondre.

[Nono40]

Tu n'as pas d'exemple de serveur OPC en C# sur le net ?

Je l'ai déjà fait en Delphi si tu as une bibliothèque correcte c'est facile à faire. Dans mon cas les composants OPC n'étaient pas gratuits mais par cher (100livres UK)

[scharbo]

J'ai trouvé pas mal d'exemple de client OPC en C# mais pas de serveur.

Le seul moyen que j'ai trouvé pour obtenir des codes de serveur serait de s'inscrire à OPCFundation ce qui couterait tout de même $1,500 ce qui n'est certe pas énorme dans le budget d'une entreprise mais est disproportionné par rapport à mes besoins.

Cependant, si tu as une autre source de serveur OPC à 100 livres UK cela pourrait valoir le cout, si jamais je ne m'en sors pas avec la méthode que je développe (ce que je saurais d'ici une ou deux semaines le temps que je finalise tout ça).

[Nono40]

Celui que j'utilise c'est http://www.production.robots.btinternet.co.uk/propc.htm
Je ne vois pas le prix et c'est pour Delphi.

Tu devrais fouiller ici http://www.opcconnect.com/ beaucoup de kit y sont référencés, y compris des kits gratuits.

[Arnard]

Client Toolkit 1250 USD
Server Toolkit
('rapid' development model, incomplete source) 1250 USD
Server Toolkit
(fully featured, with source) 4500 USD

Un sdk opc free, j'en ai jamais entendu parler, mais si ça existe, je suis intéressé pour sûr !

[Nono40]

Je suis sûr que l'on a payé 100£ il y a quelques années.

Mais de toute façon j'ai abandonné OPC depuis belle lurette, trop limitatif. On a développé notre propre couche client.

[Arnard]

Ca garantit au moins de maitriser la chaine

OPC Xi avec la couche WCF s'annonce une bonne chose, mais OPC n'est pas designé pour tout en effet.